XSF Discussion - 2019-10-05

00:03:00 zach has left
00:03:05 zach has joined
00:08:16 pdurbin has joined
00:10:59 zach has left
00:11:02 zach has joined
00:17:07 goffi has left
00:17:55 andrey.g has left
00:20:11 pdurbin has left
00:26:14 Douglas Terabyte has left
00:28:02 zach has left
00:28:05 zach has joined
00:38:50 xalek has joined
00:39:12 Zash has left
00:40:06 Zash has joined
00:42:21 zach has left
00:42:25 zach has joined
00:44:20 andrey.g has joined
00:57:41 kokonoe has left
00:58:53 pdurbin has joined
01:00:47 kokonoe has joined
01:06:23 marc_ has left
01:10:52 pdurbin has left
01:23:25 lskdjf has left
01:30:26 zach has left
01:30:29 zach has joined
01:34:40 j.r has left
01:36:36 j.r has joined
01:38:19 j.r has left
01:38:58 j.r has joined
01:58:14 zach has left
01:58:18 zach has joined
02:03:52 waqas has left
02:04:06 waqas has joined
02:21:22 waqas has left
02:24:03 zach has left
02:24:07 zach has joined
02:47:54 j.r has left
02:48:29 j.r has joined
02:58:54 pdurbin has joined
03:04:44 Yagiza has joined
03:05:01 adiaholic has joined
03:21:54 pdurbin has left
03:33:05 mukt2 has joined
03:34:33 zach has left
03:34:37 zach has joined
03:41:06 mukt2 has left
03:42:13 DebXWoody has left
03:52:44 adiaholic has left
03:52:47 adiaholic has joined
04:02:15 zach has left
04:02:20 zach has joined
04:08:37 DebXWoody has joined
04:09:45 pdurbin has joined
04:15:57 pdurbin has left
04:19:22 karoshi has joined
04:28:25 mimi89999 has left
04:28:33 mimi89999 has joined
04:30:35 mukt2 has joined
04:33:41 xalek has left
04:45:21 mukt2 has left
04:47:09 zach has left
04:47:13 zach has joined
05:00:34 mukt2 has joined
05:04:33 waqas has joined
05:10:44 Nekit has joined
05:21:03 waqas has left
05:25:50 j.r has left
05:25:59 j.r has joined
05:31:20 adiaholic has left
05:34:46 chronosx88 has joined
05:35:40 adiaholic has joined
05:38:32 mukt2 has left
05:50:02 mukt2 has joined
05:52:54 Tobias has joined
06:09:39 zach has left
06:09:43 zach has joined
06:09:45 pdurbin has joined
06:33:35 pdurbin has left
06:34:52 j.r has left
06:36:18 zach has left
06:36:22 zach has joined
06:36:31 j.r has joined
06:36:38 pep. Ge0rG: ah ok, I didn't remember the outcome but I remembered there was something about it
06:40:46 winfried has left
06:40:46 winfried has joined
06:41:38 Alex has left
06:46:39 adiaholic has left
06:48:37 mukt2 has left
06:53:00 zach has left
06:53:03 zach has joined
07:07:08 Alex has joined
07:09:56 lovetox_ has joined
07:18:53 Nekit has left
07:24:05 zach has left
07:24:08 zach has joined
07:24:38 Mikaela has joined
07:30:13 chronosx88 has left
07:30:34 chronosx88 has joined
07:34:11 LNJ has left
07:43:12 aj has left
07:46:18 Seve has joined
07:47:08 Vaulor has joined
07:50:29 adiaholic has joined
07:53:14 wurstsalat has joined
07:56:12 adiaholic has left
07:56:16 adiaholic has joined
08:01:26 adiaholic has left
08:01:33 adiaholic has joined
08:11:48 j.r has left
08:17:19 zach has left
08:17:22 zach has joined
08:17:58 j.r has joined
08:23:51 lovetox_ lately i ran into following problem with the MUC protocol
08:24:02 lovetox_ send a presence to a MUC
08:24:08 lovetox_ Muc does not answer for 20 seconds
08:24:29 lovetox_ i give the user a option to abort this join (close the window or whatever)
08:24:45 lovetox_ only this does not reflect the truth, i have not really a possibility to abort the join
08:25:07 lovetox_ so user presses abort, and naturally tries again to join the room
08:25:38 lovetox_ another presence is sent out, now suddenly server responds to the first presence, sends stuff, then does the same for the second presence
08:26:02 lovetox_ i have no possibility to know what happend because of first presence, and what happens because of last presence
08:27:00 lovetox_ now i could send a presence unavailable on first abort
08:27:29 lovetox_ this brings me into even more trouble, now the server sends all presences, then disconnects me from the muc, then starts again to send stuff
08:27:49 lovetox_ all in all nothing i want to really deal with
08:27:55 lovetox_ maybe i should remove the abort button
08:28:02 lovetox_ there is no aborting a muc join
08:28:23 Ge0rG lovetox_: modern MUCs will treat a join presence (with an x element) as a request for a full sync.
08:28:53 Ge0rG And yes, there is no way to abort anything in xmpp land.
08:29:12 Ge0rG Which is why it's silly to have things end in a hard timeout.
08:29:40 goffi has joined
08:29:45 lovetox_ then this muc join is in limbo and if a user complains i just tell him server should answer eventually
08:29:45 Ge0rG OTOH some network conditions may well lead to a request getting black holed.
08:30:11 Ge0rG So that the MUC doesn't even know that you tried joining.
08:30:31 mukt2 has joined
08:30:32 Ge0rG This can be solved with s2s 0198, which nobody has ever tested.
08:30:42 larma has left
08:30:57 Ge0rG Because you know, TCP is a reliable protocol
08:32:54 jonas’ lovetox_, the second presence with <x/> should not screw up anything in the scenario you described
08:33:10 jonas’ in fact, I think it should be safe to re-send join presences with exponential back off similar to how TCP sends SYNs
08:36:05 larma has joined
08:38:58 mukt2 has left
08:44:54 j.r has left
08:47:26 zach has left
08:47:29 zach has joined
08:48:10 kokonoe has left
08:49:20 jonas’ Kev, pinging you again regarding the hub.docker.com stuff. You seem to be the only one active who has the permissions.
08:51:33 adiaholic has left
08:51:33 Ge0rG jonas’: but one needs to know where the old join ends and the new one starts.
08:51:36 adiaholic has joined
08:52:18 Ge0rG Maybe we need a unique ID on the join stanza, and the server ignoring duplicates?
08:57:05 j.r has joined
08:57:53 emus has joined
09:00:58 jubalh has joined
09:01:07 sonny has left
09:02:59 flow > Ge0rG> jonas’: but one needs to know where the old join ends and the new one starts. do you?
09:03:02 jonas’ Ge0rG, that’d be great
09:03:07 zach has left
09:03:10 zach has joined
09:03:45 jonas’ Ge0rG, flow, not in the scenario lovetox_ described, I think. You’d get (a) a full initial set of presence, (b) all presence hcanges between a and c, and (c) another full set of initial presence
09:03:53 jonas’ there’s quite a bit of redundancy, but the state should be correct and complete
09:04:03 jonas’ although, it will be confusing if you requested MUC history
09:04:47 Mikaela has left
09:05:03 Mikaela has joined
09:08:19 COM8 has joined
09:08:45 flow jonas’, i'd guessed and hoped that something like that happens, but of course this could be MUC service (and client) implementation dependent. But nevertheless joining and (potentially other MUC actions) could and should get improved, and we should consider those things in groupchat-ng protocols
09:09:52 jcbrand has joined
09:18:45 kokonoe has joined
09:21:49 Daniel has left
09:22:29 COM8 has left
09:24:39 lskdjf has joined
09:27:32 Daniel has joined
09:28:01 jubalh has left
09:28:56 pdurbin has joined
09:28:57 jcbrand has left
09:32:09 emus has left
09:37:14 jubalh has joined
09:37:28 Ge0rG If only somebody thought that through for MIX
09:38:37 Shell has left
09:40:03 zach has left
09:40:05 zach has joined
09:41:34 jonas’ mix is at least a step forward in that regard
09:41:43 jonas’ that we don’t have a proper solution for s2s failures yet is a problem, indeed
09:41:51 jonas’ but that’s not a problem unique to mix or muc actually
09:42:59 Daniel has left
09:43:42 Ge0rG We also need something for mobile clients that are killed after 10s in the background. A solution that doesn't involve persisting all runtime state, MUCs, and contact presence to disk
09:44:18 Daniel has joined
09:45:45 Zash Can you really fix that with protocol design?
09:46:45 jonas’ "WhatsApp works"
09:47:07 Ge0rG Zash: yes
09:47:32 andy has joined
09:50:09 Ge0rG With roster versioning, no presence broadcast and MAM we already have a moderately expensive solution. We now only need to replace presence with a PEP based status thing, as suggested by Kev.
09:53:57 Douglas Terabyte has joined
09:54:58 Ge0rG BTW, what are the rules for delivering subscription requests to clients that don't send presence?
09:55:43 jonas’ "don’t"?
09:56:06 Ge0rG Oh, and the above thing doesn't include MUC. We don't have a solution for that yet
09:56:10 jonas’ Instead, if a subscription request requires approval then the contact's server MUST deliver that request to the contact's available resource(s) for approval or denial by the contact.
09:56:13 jonas’ ~~RFC 6121~~ ✎
09:56:20 jonas’ RFC 6121, 3.1.3. https://tools.ietf.org/html/rfc6121#section-3.1.3 ✏
09:57:47 jonas’ 4. Otherwise, if the contact has no available resources when the subscription request is received by the contact's server, then the contact's server MUST keep a record of the complete presence stanza comprising the subscription request, including any extended content contained therein (see Section 8.4 of [XMPP-CORE]), and then deliver the request when the contact next has an available resource.
09:57:49 jubalh has left
09:59:51 eevvoor has joined
10:00:16 Zash It's XMPP, not XMP
10:01:10 jonas’ Ge0rG, MIX would help in that regard, because it’s the user’s server which fully manages the joins
10:01:24 jonas’ and those will be in a PEP node in the future so that you’re kept up-to-date to some extent.
10:01:42 rion SIMS xep says "The file element is the same as from Jingle File Transfer (XEP-0234) [2]. It MUST specify media-type, size, description, and one or multiple hash elements" Is "description" element really MUST?
10:03:25 Ge0rG jonas’: yes, it's an improvement indeed. But will you get differential updates on the member list?
10:03:25 Zash PEP without presence doesn't work either
10:03:32 zach has left
10:03:35 zach has joined
10:03:40 jonas’ ~~Ge0rG, member list is a PEP node~~ ✎
10:03:50 jonas’ Ge0rG, member list is a PubSub node ✏
10:03:56 Ge0rG jonas’: that's not an answer
10:04:04 jonas’ and supposedly there’s a way to MAM-query PubSub nodes, although I never understood how
10:04:14 jonas’ ~~supposedly the MAM archive of a PubSub node would be the history of messages it sent~~ ✎
10:04:18 jonas’ supposedly the MAM archive of a PubSub node would be the history of notification messages it sent ✏
10:04:20 jonas’ in which case, yes.
10:04:26 Ge0rG Is it a one item node like old bookmarks?
10:04:32 jonas’ I don’t think so
10:04:52 jonas’ > Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node.
10:05:02 Ge0rG Zash: I'm sure we can figure out a way
10:07:56 flow rion, appears so
10:08:14 mr.fister has left
10:08:16 Ge0rG I don't think it makes much sense, though
10:10:15 flow rion, although that appears to be not in line with xep234
10:11:35 flow or, at least, I would expect that SIMS would require at least media-type, size and name (not description)
10:12:46 rion Agreed
10:16:10 pdurbin has left
10:17:34 Ge0rG In JFT, the <description> is the required container element, and the description text is in the optional <desc> element
10:18:01 Ge0rG So what are we talking about?
10:18:25 rion <desc>
10:22:07 flow which we may should rename to something like <description-text/>
10:27:07 j.r has left
10:29:41 sonny has joined
10:29:42 sonny has left
10:29:44 sonny has joined
10:30:29 mukt2 has joined
10:34:40 zach has left
10:34:43 zach has joined
10:37:07 marc_ has joined
10:38:29 mukt2 has left
10:40:52 Yagiza has left
10:41:42 lovetox_ jonas, the problem is the UI with my scenario
10:41:55 lovetox_ of course a library in itself would have the correct state after 2 joins
10:42:16 COM8 has joined
10:42:29 j.r has joined
10:43:17 lovetox_ but having the UI display the correct state is the challenge
10:44:27 COM8 has left
10:45:24 lovetox_ and yes it would be very helpful if we could add a unique join id to the presence, which is replicated on while joining on all the presences
10:47:10 lovetox_ i dont see a problem with subject and messages, you got to have message deduplication anyway
10:48:11 goffi has left
10:50:40 goffi has joined
10:53:19 lovetox_ hm presences should also not be a problem, i could just update the ones i have already in my roster
10:53:35 lovetox_ the real problem for me is that i dont know when the MUC join is finished
10:53:48 lovetox_ normally i display a "joining.." label
10:54:37 jonas’ lovetox_, you know it’s finished when you get the <subject/>
10:54:43 lovetox_ now i abort my first join, open the window again in haft of the first join, now i have half of all presences, then this join completes, i show the UI
10:54:49 lovetox_ but then the second join starts
10:54:59 jonas’ the second join is fully deduplicated, isn’t it?
10:56:11 lovetox_ yes .. still my plan was to *not* show the groupchat UI *while* joining
10:56:19 adiaholic has left
10:56:21 adiaholic has joined
10:56:30 LNJ has joined
10:56:36 lovetox_ so the first join signals my UI join completed, i show the UI with probably half of the users
10:56:44 lovetox_ then second join starts
10:56:58 Daniel has left
10:57:01 lovetox_ but yeah think these are edge cases
10:57:15 lovetox_ still a simple IQ flow would be much better
10:57:30 lovetox_ where i get at the end a IQ join=complete
10:57:32 lovetox_ like with mam
10:57:47 Daniel has joined
10:57:52 Zash How is that different from subject?
10:58:12 lovetox_ because the subject only tells you *a* join completed
10:58:14 lovetox_ not which one
10:58:26 lovetox_ of the 3 you send, while the server didnt answer
10:58:38 Zash right
10:59:25 Zash It should still be idempotent tho?
10:59:49 lovetox_ idempotent?
11:00:18 Zash If you get a second join result it should just set everything to the existing values
11:01:33 emus has joined
11:02:20 Zash But wouldn't you be able to identify which join is which by looking at your own presence?
11:03:27 goffi has left
11:03:45 lovetox_ would i?
11:03:59 lovetox_ does the self presence has the same id as the join presence?
11:06:09 lovetox_ as we determined before, state should be correct even on 2 joins
11:06:32 lovetox_ the problem that i have is the first join signals my UI im finished, when i reality the second is still in progress
11:07:20 lovetox_ i think this is only solveable if we would have some identifier in the join presence, which is at some point returned
11:11:45 lovetox_ i think how muc join was made is a anti-pattern, much better to make things clear with IQs
11:13:26 Zash I tend to agree
11:14:54 goffi has joined
11:16:13 Ge0rG It's significantly improved over GC1.0 still
11:16:41 Zash Yes
11:16:49 zach has left
11:16:49 j.r has left
11:16:52 zach has joined
11:16:58 jonas’ ITYM Xabber Group Chat
11:29:53 debacle has joined
11:34:04 winfried has left
11:34:05 winfried has joined
11:34:36 j.r has joined
11:42:51 j.r has left
11:48:13 zach has left
11:48:16 zach has joined
11:51:01 winfried has left
11:51:02 winfried has joined
12:05:27 j.r has joined
12:06:11 adiaholic has left
12:06:41 gav has left
12:07:17 winfried has left
12:07:17 winfried has joined
12:08:00 winfried has left
12:08:00 winfried has joined
12:08:59 zach has left
12:09:02 zach has joined
12:09:57 pdurbin has joined
12:12:32 winfried has left
12:12:33 winfried has joined
12:14:18 gav has joined
12:14:58 adiaholic has joined
12:18:01 gav has left
12:20:14 pdurbin has left
12:24:47 sonny has left
12:24:53 sonny has joined
12:30:28 mukt2 has joined
12:34:47 kokonoe has left
12:37:11 kokonoe has joined
12:37:22 zach has left
12:37:25 zach has joined
12:38:46 mukt2 has left
12:42:03 Chobbes has joined
12:42:20 j.r has left
12:46:03 adiaholic has left
12:46:17 adiaholic has joined
12:46:31 zach has left
12:46:35 zach has joined
12:50:17 adiaholic has left
12:50:18 adiaholic has joined
12:57:11 j.r has joined
12:58:06 Chobbes has left
13:03:17 gav has joined
13:04:04 j.r has left
13:07:35 zach has left
13:07:37 zach has joined
13:08:05 Daniel has left
13:11:13 COM8 has joined
13:13:41 Daniel has joined
13:14:42 mimi89999 has left
13:18:46 j.r has joined
13:19:47 COM8 has left
13:22:14 COM8 has joined
13:22:14 winfried has left
13:22:43 COM8 has left
13:23:16 winfried has joined
13:26:29 karoshi has left
13:30:05 karoshi has joined
13:36:56 adiaholic has left
13:37:09 zach has left
13:37:11 zach has joined
13:40:14 adiaholic has joined
13:40:26 Mikaela has left
13:40:39 Mikaela has joined
13:41:53 Shell has joined
13:45:04 j.r has left
13:47:17 adiaholic has left
13:49:37 zach has left
13:49:40 zach has joined
13:53:26 kokonoe has left
13:56:23 jubalh has joined
13:57:32 Daniel has left
13:58:20 jubalh has left
13:59:01 Daniel has joined
14:00:32 j.r has joined
14:02:09 !XSF_Martin has left
14:02:27 adiaholic has joined
14:03:52 debacle has left
14:04:07 !XSF_Martin has joined
14:09:57 pdurbin has joined
14:10:15 adiaholic has left
14:10:53 zach has left
14:10:56 zach has joined
14:14:10 david has left
14:14:13 j.r has left
14:14:26 Nekit has joined
14:16:17 j.r has joined
14:16:26 Tobias has left
14:17:29 Tobias has joined
14:18:33 kokonoe has joined
14:21:07 adiaholic has joined
14:22:49 jmpman has joined
14:23:49 jubalh has joined
14:25:38 pdurbin has left
14:26:29 zach has left
14:26:33 zach has joined
14:27:17 Syndace has left
14:30:27 mukt2 has joined
14:32:53 Zash Does anything use the 'continue' error type?
14:35:34 Zash looks at https://xmpp.org/extensions/xep-0310.html#mucoccupant
14:36:11 adiaholic has left
14:38:17 Syndace has joined
14:38:34 Zash Might be nice to send some "keep calm and wait while we establish s2s"
14:39:59 jubalh has left
14:40:04 mukt2 has left
14:40:57 jubalh has joined
14:44:18 Tobias has left
14:44:21 Tobias has joined
14:46:06 adiaholic has joined
14:46:41 zach has left
14:46:44 zach has joined
14:50:52 kokonoe has left
14:55:08 adiaholic has left
15:00:11 Nekit has left
15:05:22 jubalh has left
15:07:47 mukt2 has joined
15:08:30 jubalh has joined
15:09:27 david has joined
15:10:37 zach has left
15:10:40 zach has joined
15:15:40 adiaholic has joined
15:26:15 xalek has joined
15:29:22 zach has left
15:29:25 zach has joined
15:29:34 jubalh has left
15:31:47 adiaholic has left
15:31:48 adiaholic has joined
15:32:41 chronosx88 has left
15:35:13 chronosx88 has joined
15:36:45 kokonoe has joined
15:39:44 waqas has joined
15:43:22 kokonoe has left
15:44:49 mimi89999 has joined
15:48:30 kokonoe has joined
15:53:00 zach has left
15:53:03 zach has joined
15:55:14 jubalh has joined
16:00:42 andy has left
16:01:54 mukt2 has left
16:03:10 kokonoe has left
16:07:46 mukt2 has joined
16:09:48 jubalh has left
16:10:54 rion has left
16:10:55 rion has joined
16:11:17 andy has joined
16:16:03 mukt2 has left
16:28:38 andy has left
16:29:45 zach has left
16:29:48 zach has joined
16:37:46 mukt2 has joined
16:39:00 andy has joined
16:40:51 kokonoe has joined
16:44:31 jmpman has left
16:51:40 adiaholic has left
16:55:38 adiaholic has joined
16:57:02 mukt2 has left
17:05:10 adiaholic has left
17:06:04 jubalh has joined
17:07:00 adiaholic has joined
17:07:46 mukt2 has joined
17:19:25 adiaholic has left
17:20:33 mukt2 has left
17:28:26 jubalh has left
17:29:26 adiaholic has joined
17:35:27 adiaholic has left
17:45:03 chronosx88 has left
17:45:32 adiaholic has joined
17:47:47 kokonoe has left
17:52:24 kokonoe has joined
17:57:04 larma Anyone had a chance to check my last weeks mail https://mail.jabber.org/pipermail/standards/2019-September/036495.html ?
17:59:22 !XSF_Martin has left
17:59:34 derdaniel has joined
18:02:24 chronosx88 has joined
18:02:34 adiaholic has left
18:03:32 kokonoe has left
18:05:25 !XSF_Martin has joined
18:08:52 adiaholic has joined
18:09:59 pdurbin has joined
18:14:01 mukt2 has joined
18:15:40 jubalh has joined
18:23:51 kokonoe has joined
18:24:54 pdurbin has left
18:32:02 lovetox_ yeah also thought this would get at least one response :/
18:32:58 Zash Multi-session-nick is fairly underspecified
18:40:54 Zash larma, vcards have been public, so I'd say "no" to that part
18:43:39 andrey.g has left
18:46:54 zach has left
18:46:57 zach has joined
18:48:34 mukt2 has left
18:48:35 jonas’ has left
18:49:00 jonas’ has joined
18:51:40 jubalh has left
18:53:00 lovetox_ Zash i think it would be nice if prosody adds a "Dont route IQs to other participants" room config option
18:53:04 lovetox_ ejabberd has this
18:53:53 Zash File an issue. I also want to be able to disable PMs.
18:54:11 lovetox_ yes
18:54:48 mukt2 has joined
18:54:56 Zash Would that be full JID routing or also break all vcards?
18:55:57 lovetox_ of course it would break vcard, and thats actually exactly the use case
18:55:58 lovetox_ :)
18:56:25 lovetox_ 1. routing just is doesnt work good or is underspecified for the multi session nick thing
18:56:28 lovetox_ 2. its a privacy issue
18:56:33 eevvoor has left
18:57:00 kokonoe has left
18:57:03 lovetox_ even more so now that prosody even routes it to the pubsub component
18:57:15 jonas’ prosody just routes (some IQs) to the bare JID
18:57:44 lovetox_ or rather the pubsub component answers for the user
18:57:56 jonas’ you mean PEP?
18:58:00 lovetox_ yes
18:58:03 Zash No, it routes to the bare JID
18:58:08 jonas’ I wouldn’t call that "pubsub component" to avoid confusion
18:58:21 Zash It was ejabberd that answers vCard requests to full JIDs
18:58:22 Zash iric
18:58:25 Zash iirc*
18:58:36 lovetox_ which is correct if you go by the XEP isnt it?
18:58:45 Zash wat
18:58:48 lovetox_ the vcard xep says server should answer it for the user
18:58:53 Zash wat
18:59:07 lovetox_ otherwise how would you request a vcard of an offline user?
18:59:51 jonas’ lovetox_, ask the bare JID?
18:59:52 Zash wat
19:01:54 lovetox_ look either we want vcard in muc to work nicely, than a server should answer any vcard request for the user bare or full jid
19:02:17 lovetox_ or we dont want it in a muc (anon maybe), then the muc should not even start to route IQs
19:03:26 Zash If the XEP says that the server should respond to requests to full JIDs then the XEP is wrong and diverges from how everything else in XMPP works.
19:03:37 lovetox_ no it says to respond to bare jid
19:03:57 lovetox_ and how is this ever going to work in MUC?
19:04:07 lovetox_ how can i address your bare jid in a anon room?
19:04:18 Zash You can't.
19:04:29 Zash Server can forward the request to your bare JID, like Prosody does
19:05:26 lovetox_ and you do this now for any IQ request
19:05:50 Zash No, only for a small set of known namespaces, namely vcard-temp, pubsub and vcard4.
19:06:06 lovetox_ yeah and you dont see this as a problem?
19:06:10 Zash No
19:06:17 lovetox_ this is nowhere specificed, its a hack
19:06:25 lovetox_ and one that is a privacy issue on top
19:06:39 Zash As was the vcard-temp routing thing.
19:06:59 Zash However that's considered public data
19:07:24 lovetox_ i consider it public data to people who know my adress
19:07:38 Zash Don't put it in your globally public vcard then
19:08:20 Zash What is the point of the JABBERID field?
19:08:47 mukt2 has left
19:09:44 lovetox_ As i said its fine for people who know my adress, if i join a anon room, the point of the room is exactly to prevent people getting my real adress, but now it seems they dont even need it, because the server is happily routing to the bare jid and giving me the answer
19:10:28 lovetox_ im not saying we should prevent routing IQs, it just should be revisited for public anon rooms
19:10:46 lovetox_ and for non-anon rooms you dont have to route IQs at all
19:10:57 lovetox_ clients should just request the real bare jid
19:12:19 lovetox_ so who needs these public anon rooms that compromise the privacy of their participants? What use case do they fullfill exactly
19:13:21 lovetox_ You want Avatars, public omemo keys, other *private* data, then make your room non-anon and every user that joins knows what he gets into
19:13:57 lovetox_ this idea, i make my room anon, but still keep all features of non-anon rooms, is a bad solution
19:14:30 lovetox_ and i would argue its to the disadvantage of all users that join
19:17:02 Zash I think you exaggerate the privacy impact somewhat.
19:17:23 Zash I also never said I was against having this as a setting.
19:18:15 pep. I don't think saying "public vcard is a privacy issue" is an eggageration :x
19:18:58 Zash Don't put stuff there if you don't want it public for everyone everywhere, which is how vcard-temp works.
19:19:32 kokonoe has joined
19:19:37 jonas’ to be fair, I was also surprised that my avatar is exposed in anon MUCs
19:21:26 Zash We got tons of complaints IIRC when we made vcards (via the PEP-conversion stuff) respect the privacy settings of the corresponding PEP nodes.
19:21:41 Zash So, people have varying expectations.
19:22:06 pep. Ah that reminds me I need to open an issue about that
19:22:10 lovetox_ yes Zash, thats because we did water down anon rooms, so people dont even know anymore what they are there for
19:22:11 Zash Now Prosody makes those public by default, but still respects it if you change their settings.
19:22:28 pep. Prosody still broadcasts my avatar hash in the presence even though I have access_model of vcard4 set to presence
19:22:33 pep. in MUCs*
19:22:52 Zash avatar and vcard4s are separate nodes tho
19:23:00 pep. k
19:23:03 Zash And you can have separate permissions. I do, in fact.
19:23:10 pep. I also do have that node set to presence I think
19:23:14 Zash If you query my vcard through here you only get the avatrarwavatar
19:23:19 lovetox_ And Zash, im not arguing against prosody here, this issue was raised by larma on the last sprint, and we discussed it, and now try to raise awareness in the community
19:23:41 lovetox_ so even if the discussion started with me, asking you for these settings, its more of a general discussion
19:24:02 Zash Some of the problem is that there are two separate issues
19:24:11 lovetox_ in my opinion we should make the consequences clear what anon means, and follow through with it
19:24:27 Zash Or more?
19:24:32 lovetox_ not try and find ways how we can water down anon
19:24:51 lovetox_ how we can bring features to anon that can not work with anon
19:25:12 mimi89999 has left
19:25:24 Zash You mean semi-anon? True anon rooms is dead afaik.
19:26:11 kokonoe has left
19:26:49 lovetox_ yeah of course
19:27:08 lovetox_ i would not go that route arguing true anon is not possible so also fuck semi-anon
19:27:09 Zash I feel like this is a topic for a summit, rather than late saturday. :)
19:27:15 lovetox_ there is a good usecase for semi-anon
19:27:47 lovetox_ but just to be clear, there is no XEP or RFC that tells a muc to route IQs to the bare jid is it?
19:28:29 mimi89999 has joined
19:28:38 pep. lovetox_, what larma quoted in his mail no?
19:28:44 Zash https://xmpp.org/extensions/xep-0045.html#bizrules-iq ?
19:29:07 pep. That doesn't specify bare or full though
19:29:13 lovetox_ ah its not specified
19:29:14 lovetox_ lol
19:29:23 lovetox_ yeah thats a real fail here
19:29:35 Zash Nor which one if there's MSN involved.
19:30:04 Zash I believe prosody picks one (probably the first) as the "primary" session and sends to that.
19:30:08 lovetox_ i mean it would be fine if you route to full jid
19:30:20 lovetox_ then the client can decide itself if he wants to reveal his data or not
19:30:36 jonas’ although larma argued that even that isn’t good enough from a privacy perspective.
19:30:39 Zash That lets yo do timeing things.
19:31:02 jonas’ and you wouldn’t want to DoS a client which joins a busy semi-anon MUC and then has to upload its avatar a gazillion times.
19:31:26 jonas’ (see also https://lab.louiz.org/poezio/poezio/issues/3419 )
19:32:13 lovetox_ jonas its already ddosed with disco info requests :D
19:32:24 jonas’ avatars are an order of magnitude worse though
19:32:28 jonas’ or a few orders actually
19:32:42 Zash disco#info could be cached
19:32:45 lovetox_ if you want to do it real good, you would have to activate on your server to answer vcard requests to full jids for you
19:32:57 lovetox_ Zash avatars are also cached
19:32:59 jonas’ lovetox_, guess what, that exists already
19:33:01 adiaholic has left
19:33:08 jonas’ that’s why vcard is handled by the bare JID ;)
19:33:22 lovetox_ i mean a user configurable setting
19:33:28 lovetox_ not a server admin setting
19:33:34 jonas’ that exists, it’s the visibility of the avatar pubsub node nowadays
19:33:46 jonas’ at least for some implementations, and that’s even specified
19:34:01 jonas’ https://xmpp.org/extensions/xep-0398.html#security
19:34:07 lovetox_ hm yes this could work
19:34:46 Zash As I mentioned, you can fiddle with access control on the avatar and vcard4 nodes to do nice things.
19:34:48 lovetox_ so if i set it to presence, then my avatar is hidden
19:35:06 pep. Maybe we need to add something like "also adjust presence broadcast if a user decides to use something else than open
19:35:07 jonas’ I always forget whether directed presence counts for `presence` or not
19:35:15 Zash jonas’: not
19:35:25 jonas’ k
19:35:40 lovetox_ yeah fine workaround, im of the opinion we should deactivate IQ routing in anon rooms by default
19:35:55 jonas’ lovetox_, I tend to agree with that
19:36:09 Zash "presence" is an awkward name for it since it's based on roster (presence) subscriptions
19:40:39 larma The whole privacy model of vcard and public pep is based on the idea that a person still needs to know your real jid to access them. With semi-anon MUCs that's not the case anymore. Especially in prosodys now also routing pubsub IQs such that they can actually be replied by the server means that I only have two options: Not use OMEMO with non-roster contacts *or* reveal my identity in every semi-anon MUC
19:42:20 larma (I would probably opt for the first, if not every client would now by default make OMEMO pep nodes public)
19:47:06 lovetox_ Zash, whats the motiviation behind not allowing PMs?
19:47:13 zach has left
19:47:16 zach has joined
19:47:55 Zash lovetox_, ever had people join your support room and then PM you support questions?
19:50:05 Zash IIRC it's also been requested by others. Don't remember their motivation. I'm sure there's use for it.
19:51:25 Daniel has left
19:51:28 Daniel has joined
19:53:28 jonas’ I would like to turn off PMs as a user right now.
19:54:06 larma My problem is that I can not rely in any way on IQ routing in semi-anon MUCs, because behavior is diverting between servers. That's why we should at least define the correct behavior. And IMO correct behavior is not to randomly send some IQs to bare and some to full JID
19:54:19 Daniel has left
19:54:21 wurstsalat has left
19:54:24 Daniel has joined
19:54:41 jonas’ larma, I agree on the first part, but I’m not sure on the second part
19:54:55 jonas’ although if we had to pin it down one way, I’d say "route to bare JID"
19:56:26 Daniel has left
19:56:31 Daniel has joined
19:57:15 wurstsalat has joined
19:57:43 larma Well, if we say some IQs are routed to bare and some to full, we would need servers to somehow indicate what they are doing, because it might update...
19:58:02 jonas’ similar to how we version carbon rules at the moment, indeed
19:59:35 lovetox_ larma, server should add a config options to muc, default to not route IQs, and advertise the setting in disco info
19:59:55 lovetox_ then the client can warn its users before joining such a anon but still routing IQs MUC
20:00:39 chronosx88 Hey, guys. Does MAM support for chat room state changes? (E.g. chat room name or subject)
20:00:42 larma lovetox_, yes that would work
20:01:00 jonas’ chronosx88, subject yes, name not
20:01:28 Zash Does it?
20:01:32 chronosx88 And how offline user will know, that room name is changed?
20:02:06 lovetox_ jonas, i dont think subject changes are in MAM
20:02:19 jonas’ lovetox_, oh
20:02:28 derdaniel has left
20:02:32 jonas’ chronosx88, I guess you’d query that when you rejoin the room
20:02:46 chronosx88 Ehm...
20:02:50 lovetox_ chronosx88, you do a disco info to the muc before you join
20:03:12 lovetox_ and if the room name changes, the muc has to issue a status code for changed configuration
20:03:27 lovetox_ which should trigger your client to do again a disco info to get the new name
20:04:46 chronosx88 I just comparing XMPP and Matrix by technical abilities and simplicity
20:05:16 debacle has joined
20:05:59 lovetox_ MAM is a message archive, it does not hold any configuration infos of MUCs
20:06:19 lovetox_ all configuration info is available via disco info to the muc jid
20:06:39 lovetox_ and all changes to the configuration are announced via message to joined and even not joined participants
20:06:47 lovetox_ (if they are in the member list of a muc=)
20:08:21 chronosx88 And... How it can synchronized when user didn't open client?
20:08:22 lovetox_ and you should disco info a muc before you join if you certain configuration fields like muc name are important to you
20:08:41 chronosx88 > And... How it can synchronized when user didn't open client? Or really is offline.
20:08:58 lovetox_ im not sure what you mean, if you are offline per definition nothing can be synced
20:09:02 lovetox_ because you are offline
20:09:12 chronosx88 Yeah
20:09:41 lovetox_ if you start your client, and join the rooms the user was in last time
20:09:57 lovetox_ before you join, the client sends a disco info to the muc, to get the current configuration
20:09:58 pdurbin has joined
20:10:02 lovetox_ you could call that the "sync"
20:10:08 chronosx88 Ok
20:10:20 lovetox_ from that point on if you are joined, and configuration changes while you are online and joined
20:10:23 lovetox_ the muc informs you about it
20:10:28 Nekit has joined
20:10:45 chronosx88 Another question: how I can sync unread messages count between clients?
20:11:23 lovetox_ your best bet is XEP-0333 chat markers
20:11:24 Daniel has left
20:11:25 chronosx88 And point in chat room, when I last time stopped reading
20:11:28 Daniel has joined
20:11:48 chronosx88 > your best bet is XEP-0333 chat markers Hm... Ok, will read it
20:12:06 lovetox_ where you stopped reading is a client UX problem, with chat markers, you can mark the messages you read on a client
20:12:16 lovetox_ and sync this info to your other clients, which can act accordingly
20:12:18 Zash Did anyone have plans to make a PEP based unread message tracking thing?
20:12:47 Daniel has left
20:12:53 Daniel has joined
20:13:15 larma Zash, why?
20:13:55 APach has left
20:14:59 Zash IIRC there was talk about something like that, or at least changing 333.
20:15:54 Daniel has left
20:15:58 Daniel has joined
20:16:41 pep. Zash, on, I'd like that
20:16:55 pep. To sync reading state between clients
20:17:11 larma but you can already do that using MAM, no?
20:17:19 pep. Can you?
20:17:20 Zash How?
20:18:03 larma well if a 333 marker is send as a message, MAM should store it
20:18:13 larma > Clients SHOULD use Message Archiving (XEP-0136) [7] or Message Archive Management (XEP-0313) [8] to support offline updating of Chat Markers. Chat Markers SHOULD be archived, so they can be fetched and set regardless of whether the other users in a chat are online. from 333
20:19:30 pep. Sending only 333 to myself then?
20:19:32 Zash Never seen that before.
20:19:47 pep. I don't especially want others to know
20:19:57 Daniel has left
20:20:01 Daniel has joined
20:20:10 lovetox_ pep., i think this would be possible
20:20:15 lovetox_ you could send chatmarkers to yourself
20:20:38 lovetox_ its very ugly because you get a hell of duplicated messages
20:20:48 pep. yeah
20:20:54 lovetox_ but i think this would work
20:20:58 larma Ah right, If you don't want the other end to know, 333 is probably not best suited
20:21:07 lovetox_ BUT only if you use unique stanza ids in every conversation
20:21:08 pdurbin has left
20:21:12 lovetox_ otherwise you lose the context
20:23:38 larma Yeah, makes sense, if you don't want to send to other end, PEP is better than MAM
20:25:57 Shell has left
20:25:58 Shell has joined
20:34:25 chronosx88 has left
20:34:42 Nekit has left
20:34:46 chronosx88 has joined
20:35:40 Mikaela has left
20:36:08 Mikaela has joined
20:36:24 lovetox_ you could do this analog to bookmarks 2
20:36:37 lovetox_ one node, with X items, and item-id = jid of contact
20:36:52 lovetox_ then add the current stanza id that you read
20:39:27 karoshi has left
20:39:32 chronosx88 has left
20:39:42 karoshi has joined
20:39:53 chronosx88 has joined
20:41:10 waqas has left
20:46:43 kokonoe has joined
20:52:51 andrey.g has joined
20:53:34 chronosx88 has left
21:00:16 mukt2 has joined
21:08:40 mukt2 has left
21:15:19 kokonoe has left
21:15:40 matkor has left
21:15:41 matkor has joined
21:32:32 Daniel has left
21:32:54 Daniel has joined
21:33:15 !XSF_Martin has left
21:33:58 !XSF_Martin has joined
21:36:46 mukt2 has joined
21:41:21 jason has joined
21:41:36 mukt2 has left
21:41:38 mukt2 has joined
21:41:40 zach has left
21:41:44 zach has joined
21:42:11 karoshi has left
21:51:13 mimi89999 has left
21:59:47 mimi89999 has joined
22:05:36 Daniel has left
22:09:59 pdurbin has joined
22:16:12 pdurbin has left
22:20:35 kokonoe has joined
22:21:19 lovetox_ has left
22:23:19 jason has left
22:27:14 kokonoe has left
22:32:06 goffi has left
22:32:40 Daniel has joined
22:35:16 APach has joined
22:55:54 mukt2 has left
23:07:50 Daniel has left
23:13:48 LNJ has left
23:13:54 Mikaela has left
23:14:30 Douglas Terabyte has left
23:14:31 Douglas Terabyte has joined
23:26:37 zach has left
23:26:40 zach has joined
23:27:32 Daniel has joined
23:30:52 LNJ has joined
23:48:35 kokonoe has joined
23:49:59 Daniel has left
23:55:53 zach has left
23:55:56 zach has joined
23:57:31 Daniel has joined