2016-01-19T02:39:50 *** treffer1 has joined #smack 2016-01-19T02:41:24 *** treffer has quit IRC 2016-01-19T08:35:19 *** treffer1 has quit IRC 2016-01-19T10:01:21 *** daniele_athome has joined #smack 2016-01-19T10:27:56 *** blues-man has joined #smack 2016-01-19T10:28:07 *** blues-man has joined #smack 2016-01-19T12:11:57 *** blues-man has quit IRC 2016-01-19T12:19:18 *** daniele_athome has quit IRC 2016-01-19T12:23:09 *** daniele_athome has joined #smack 2016-01-19T12:27:24 *** blues-man has joined #smack 2016-01-19T12:28:29 *** daniele_athome has quit IRC 2016-01-19T12:28:34 *** daniele_nothome has joined #smack 2016-01-19T12:28:46 *** daniele_nothome is now known as daniele_athome 2016-01-19T12:40:09 *** daniele_athome has quit IRC 2016-01-19T12:42:35 *** daniele_athome has joined #smack 2016-01-19T13:13:37 <_flow_> Ge0rG: did you had a look at the OX XEP? 2016-01-19T13:13:55 nope :( 2016-01-19T13:15:44 <_flow_> Ge0rG: just saw you're active in xsf@, still on vaction? 2016-01-19T13:16:04 _flow_: I've returned to my day-to-day schedule now 2016-01-19T13:18:16 <_flow_> Ge0rG: We plan to submit the XEP early feb, would be great to have your feedback by then 2016-01-19T13:18:54 <_flow_> but it wouldn't be the end of the world if you don't find the time :) 2016-01-19T13:18:59 <_flow_> just saying ;) 2016-01-19T13:25:38 _flow_: we are talking about "OpenPGP for XMPP"? 2016-01-19T13:26:39 <_flow_> yep 2016-01-19T13:26:42 <_flow_> Ge0rG: ^ 2016-01-19T14:23:19 -GitHub8- [Smack] andrey-starodubtsev opened pull request #20: merge latest changes from https://github.com/igniterealtime/Smack/tree/master (mam...mam) https://github.com/Flowdalic/Smack/pull/20 2016-01-19T14:44:05 -GitHub157- [Smack] Flowdalic closed pull request #20: merge latest changes from https://github.com/igniterealtime/Smack/tree/master (mam...mam) https://github.com/Flowdalic/Smack/pull/20 2016-01-19T14:52:15 *** daniele_athome has quit IRC 2016-01-19T14:53:48 *** daniele_athome has joined #smack 2016-01-19T15:06:15 _flow_: I have a MAXS user on yax.im misbehaving. MAXS is sending itself messages in an endless loop: 2016-01-19T15:06:18 Jan 19 15:05:02 c2s25937e0 debug RECV: Unknown command: unknownUnknown command: unknown
2016-01-19T15:06:32 it's at 13K messages now, according to the message id. 2016-01-19T15:09:21 killed the session now. will try to obtain a client version when/if it reconnects. 2016-01-19T15:42:14 _flow_, I promise I'll give feedback tonight. Sorry I know I should care more but I'm simply finding so hard to spare some time to my project 2016-01-19T16:05:42 <_flow_> daniele_athome: no need to hurry. I just wonder about the differences and similarities between kontalk's OpenPGP implementation and the one of the OX XEP 2016-01-19T16:06:13 <_flow_> daniele_athome: dominik, one of our OpenPGP experts, seems to be pretty impressed with kontalks and now I'm curious :) 2016-01-19T16:14:20 <_flow_> Ge0rG: thanks, that's an misconfiguration issue. I wonder what would be best to prevent it. Maybe I should tag the "unknown command" responses with an extension element 2016-01-19T16:15:10 <_flow_> or even better, tag all maxs responses 2016-01-19T16:23:07 -GitHub124- [Smack] Flowdalic closed pull request #56: Chat state manager issue (master...chatstate-bug-rebased) https://github.com/igniterealtime/Smack/pull/56 2016-01-19T16:23:07 -GitHub53- [Smack] Flowdalic reopened pull request #56: Chat state manager issue (master...chatstate-bug-rebased) https://github.com/igniterealtime/Smack/pull/56 2016-01-19T16:26:21 _flow_, I'm curious too :-) there is nothing special in my implementation, I use a mix of the old e2e rfc draft (I can't remember which one exactly, there are several out there) and the old jabber pgp usage :) 2016-01-19T16:26:28 I will reply with details tonight 2016-01-19T16:40:15 *** blues-man has quit IRC 2016-01-19T16:41:45 _flow_: I was going to suggest checking the sending resource, but that wouldn't prevent two instances of MAXS spamming each other 2016-01-19T16:42:38 Software: MAXS (Smack 4.1.0-beta2 (4.0.6-494-g4b21581 2015-02-02)) 2016-01-19T16:42:38 Version: 2016-01-19T16:42:38 Platform: Android 5.1.1 (API 22) 2016-01-19T16:43:39 _flow_: apparently MAXS has a higher resource priority (available/24) than the user's regular client. 2016-01-19T16:51:48 *** blues-man has joined #smack 2016-01-19T16:52:16 *** blues-man has quit IRC 2016-01-19T16:52:16 *** blues-man has joined #smack 2016-01-19T17:04:03 hey blues-man 2016-01-19T19:02:20 *** blues-man has quit IRC 2016-01-19T19:06:25 *** igam has quit IRC 2016-01-19T19:34:52 *** MAXS has joined #smack 2016-01-19T19:35:08 <_flow_> Ge0rG: also checking resource is not reliable, the server may assign a different one 2016-01-19T19:36:07 *** Ge0rG has quit IRC 2016-01-19T19:37:50 *** treffer has joined #smack 2016-01-19T19:42:21 *** Ge0rG has joined #smack 2016-01-19T19:45:05 *** treffer has quit IRC 2016-01-19T19:45:13 *** treffer has joined #smack 2016-01-19T19:46:52 <_flow_> Ge0rG: got a commit ready that should fix the issue 2016-01-19T19:47:13 <_flow_> needs testing of course 2016-01-19T20:20:27 <_flow_> Ge0rG: https://bitbucket.org/projectmaxs/maxs/commits/2fb0b3ccff8ec40c174017e79c6a5c144b61e600 2016-01-19T20:38:35 _flow_: I've contacted the culprit, but no response yet 2016-01-19T20:42:12 _flow_: that actually made me think... maybe there should be a dedicated XEP for bot-generated messages that should not be auto-responded to. 2016-01-19T20:42:38 on IRC there are messages vs. notices; XMPP message types have no equivalent 2016-01-19T20:43:04 okay, actually they do, with type=headline, but I imagine this is not widely supported by clients 2016-01-19T20:43:25 <_flow_> Ge0rG: to me, message types are routing attributes 2016-01-19T20:43:33 <_flow_> not attributes that define the semantic of a message 2016-01-19T20:43:48 _flow_: but they are both. 2016-01-19T20:43:49 <_flow_> the message 'type' values are just poorly choosen 2016-01-19T20:43:54 <_flow_> Ge0rG: no they are not 2016-01-19T20:44:18 <_flow_> headline messages could contain data for a human or for a machine, and/or could be send by a machine or a human 2016-01-19T20:44:32 <_flow_> the type just tells the server to route the stanza via a particular algorithm 2016-01-19T20:45:08 _flow_: type=error and chat. vs normal are both example of semantic use 2016-01-19T20:45:27 <_flow_> not in my book 2016-01-19T20:45:38 <_flow_> maybe we have to aggree on what semantic use means 2016-01-19T20:46:56 <_flow_> semantic adds a meaning to something, for example "This is a chat message send by a human for a human" 2016-01-19T20:47:09 <_flow_> but that is certainly not true for all messages having the type 'chat' 2016-01-19T20:48:03 <_flow_> I'd willing to agree that type 'error' has some semantic (and some routing behavior information) 2016-01-19T20:49:05 <_flow_> of course you could say that the message type bears some routing semantic 2016-01-19T20:49:17 <_flow_> but I assume that's not the sematic you had in mind and we are talking about 2016-01-19T21:01:08 -GitHub160- [Smack] Flowdalic created fix-proceedtlsreceived (+1 new commit): https://github.com/Flowdalic/Smack/commit/a9708efe3650 2016-01-19T21:01:08 -GitHub160- Smack/fix-proceedtlsreceived a9708ef Florian Schmaus: Fix XMPPTCPConnection.proceedTLSReceived()... 2016-01-19T21:05:37 _flow_: in the RFC, the message types are assigned according to what kind of content they should carry, which I consider semantics. How they should be routed is also defined there, derived from the content meaning. 2016-01-19T22:52:14 <_flow_> Ge0rG: where does the RFC "assign" content to the message type? 2016-01-19T22:52:35 <_flow_> I only remember that routing is defined there 2016-01-19T22:52:59 <_flow_> Possible that I overlooked it, or that I forgot about it 2016-01-19T22:53:24 <_flow_> But if it's there I would consider it a leftover from the times where XMPP was thought of as a chat protocol 2016-01-19T22:53:46 <_flow_> when it really is a protocol to get data from A to B nowadays 2016-01-19T23:02:51 _flow_: is it? 2016-01-19T23:03:30 _flow_: 5.2.2 defines the types