XSF Discussion - 2019-10-05

  1. pep.

    Ge0rG: ah ok, I didn't remember the outcome but I remembered there was something about it

  2. lovetox_

    lately i ran into following problem with the MUC protocol

  3. lovetox_

    send a presence to a MUC

  4. lovetox_

    Muc does not answer for 20 seconds

  5. lovetox_

    i give the user a option to abort this join (close the window or whatever)

  6. lovetox_

    only this does not reflect the truth, i have not really a possibility to abort the join

  7. lovetox_

    so user presses abort, and naturally tries again to join the room

  8. lovetox_

    another presence is sent out, now suddenly server responds to the first presence, sends stuff, then does the same for the second presence

  9. lovetox_

    i have no possibility to know what happend because of first presence, and what happens because of last presence

  10. lovetox_

    now i could send a presence unavailable on first abort

  11. 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

  12. lovetox_

    all in all nothing i want to really deal with

  13. lovetox_

    maybe i should remove the abort button

  14. lovetox_

    there is no aborting a muc join

  15. Ge0rG

    lovetox_: modern MUCs will treat a join presence (with an x element) as a request for a full sync.

  16. Ge0rG

    And yes, there is no way to abort anything in xmpp land.

  17. Ge0rG

    Which is why it's silly to have things end in a hard timeout.

  18. lovetox_

    then this muc join is in limbo and if a user complains i just tell him server should answer eventually

  19. Ge0rG

    OTOH some network conditions may well lead to a request getting black holed.

  20. Ge0rG

    So that the MUC doesn't even know that you tried joining.

  21. Ge0rG

    This can be solved with s2s 0198, which nobody has ever tested.

  22. Ge0rG

    Because you know, TCP is a reliable protocol

  23. jonas’

    lovetox_, the second presence with <x/> should not screw up anything in the scenario you described

  24. jonas’

    in fact, I think it should be safe to re-send join presences with exponential back off similar to how TCP sends SYNs

  25. jonas’

    Kev, pinging you again regarding the hub.docker.com stuff. You seem to be the only one active who has the permissions.

  26. Ge0rG

    jonas’: but one needs to know where the old join ends and the new one starts.

  27. Ge0rG

    Maybe we need a unique ID on the join stanza, and the server ignoring duplicates?

  28. flow

    > Ge0rG> jonas’: but one needs to know where the old join ends and the new one starts. do you?

  29. jonas’

    Ge0rG, that’d be great

  30. 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

  31. jonas’

    there’s quite a bit of redundancy, but the state should be correct and complete

  32. jonas’

    although, it will be confusing if you requested MUC history

  33. 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

  34. Ge0rG

    If only somebody thought that through for MIX

  35. jonas’

    mix is at least a step forward in that regard

  36. jonas’

    that we don’t have a proper solution for s2s failures yet is a problem, indeed

  37. jonas’

    but that’s not a problem unique to mix or muc actually

  38. 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

  39. Zash

    Can you really fix that with protocol design?

  40. jonas’

    "WhatsApp works"

  41. Ge0rG

    Zash: yes

  42. 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.

  43. Ge0rG

    BTW, what are the rules for delivering subscription requests to clients that don't send presence?

  44. jonas’


  45. Ge0rG

    Oh, and the above thing doesn't include MUC. We don't have a solution for that yet

  46. 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.

  47. jonas’

    RFC 6121

  48. jonas’

    RFC 6121, 3.1.3. https://tools.ietf.org/html/rfc6121#section-3.1.3

  49. 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.

  50. Zash

    It's XMPP, not XMP

  51. jonas’

    Ge0rG, MIX would help in that regard, because it’s the user’s server which fully manages the joins

  52. jonas’

    and those will be in a PEP node in the future so that you’re kept up-to-date to some extent.

  53. 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?

  54. Ge0rG

    jonas’: yes, it's an improvement indeed. But will you get differential updates on the member list?

  55. Zash

    PEP without presence doesn't work either

  56. jonas’

    Ge0rG, member list is a PEP node

  57. jonas’

    Ge0rG, member list is a PubSub node

  58. Ge0rG

    jonas’: that's not an answer

  59. jonas’

    and supposedly there’s a way to MAM-query PubSub nodes, although I never understood how

  60. jonas’

    supposedly the MAM archive of a PubSub node would be the history of messages it sent

  61. jonas’

    supposedly the MAM archive of a PubSub node would be the history of notification messages it sent

  62. jonas’

    in which case, yes.

  63. Ge0rG

    Is it a one item node like old bookmarks?

  64. jonas’

    I don’t think so

  65. jonas’

    > Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node.

  66. Ge0rG

    Zash: I'm sure we can figure out a way

  67. flow

    rion, appears so

  68. Ge0rG

    I don't think it makes much sense, though

  69. flow

    rion, although that appears to be not in line with xep234

  70. flow

    or, at least, I would expect that SIMS would require at least media-type, size and name (not description)

  71. rion


  72. Ge0rG

    In JFT, the <description> is the required container element, and the description text is in the optional <desc> element

  73. Ge0rG

    So what are we talking about?

  74. rion


  75. flow

    which we may should rename to something like <description-text/>

  76. lovetox_

    jonas, the problem is the UI with my scenario

  77. lovetox_

    of course a library in itself would have the correct state after 2 joins

  78. lovetox_

    but having the UI display the correct state is the challenge

  79. 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

  80. lovetox_

    i dont see a problem with subject and messages, you got to have message deduplication anyway

  81. lovetox_

    hm presences should also not be a problem, i could just update the ones i have already in my roster

  82. lovetox_

    the real problem for me is that i dont know when the MUC join is finished

  83. lovetox_

    normally i display a "joining.." label

  84. jonas’

    lovetox_, you know it’s finished when you get the <subject/>

  85. 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

  86. lovetox_

    but then the second join starts

  87. jonas’

    the second join is fully deduplicated, isn’t it?

  88. lovetox_

    yes .. still my plan was to *not* show the groupchat UI *while* joining

  89. lovetox_

    so the first join signals my UI join completed, i show the UI with probably half of the users

  90. lovetox_

    then second join starts

  91. lovetox_

    but yeah think these are edge cases

  92. lovetox_

    still a simple IQ flow would be much better

  93. lovetox_

    where i get at the end a IQ join=complete

  94. lovetox_

    like with mam

  95. Zash

    How is that different from subject?

  96. lovetox_

    because the subject only tells you *a* join completed

  97. lovetox_

    not which one

  98. lovetox_

    of the 3 you send, while the server didnt answer

  99. Zash


  100. Zash

    It should still be idempotent tho?

  101. lovetox_


  102. Zash

    If you get a second join result it should just set everything to the existing values

  103. Zash

    But wouldn't you be able to identify which join is which by looking at your own presence?

  104. lovetox_

    would i?

  105. lovetox_

    does the self presence has the same id as the join presence?

  106. lovetox_

    as we determined before, state should be correct even on 2 joins

  107. lovetox_

    the problem that i have is the first join signals my UI im finished, when i reality the second is still in progress

  108. lovetox_

    i think this is only solveable if we would have some identifier in the join presence, which is at some point returned

  109. lovetox_

    i think how muc join was made is a anti-pattern, much better to make things clear with IQs

  110. Zash

    I tend to agree

  111. Ge0rG

    It's significantly improved over GC1.0 still

  112. Zash


  113. jonas’

    ITYM Xabber Group Chat

  114. Zash

    Does anything use the 'continue' error type?

  115. Zash looks at https://xmpp.org/extensions/xep-0310.html#mucoccupant

  116. Zash

    Might be nice to send some "keep calm and wait while we establish s2s"

  117. larma

    Anyone had a chance to check my last weeks mail https://mail.jabber.org/pipermail/standards/2019-September/036495.html ?

  118. lovetox_

    yeah also thought this would get at least one response :/

  119. Zash

    Multi-session-nick is fairly underspecified

  120. Zash

    larma, vcards have been public, so I'd say "no" to that part

  121. lovetox_

    Zash i think it would be nice if prosody adds a "Dont route IQs to other participants" room config option

  122. lovetox_

    ejabberd has this

  123. Zash

    File an issue. I also want to be able to disable PMs.

  124. lovetox_


  125. Zash

    Would that be full JID routing or also break all vcards?

  126. lovetox_

    of course it would break vcard, and thats actually exactly the use case

  127. lovetox_


  128. lovetox_

    1. routing just is doesnt work good or is underspecified for the multi session nick thing

  129. lovetox_

    2. its a privacy issue

  130. lovetox_

    even more so now that prosody even routes it to the pubsub component

  131. jonas’

    prosody just routes (some IQs) to the bare JID

  132. lovetox_

    or rather the pubsub component answers for the user

  133. jonas’

    you mean PEP?

  134. lovetox_


  135. Zash

    No, it routes to the bare JID

  136. jonas’

    I wouldn’t call that "pubsub component" to avoid confusion

  137. Zash

    It was ejabberd that answers vCard requests to full JIDs

  138. Zash


  139. Zash


  140. lovetox_

    which is correct if you go by the XEP isnt it?

  141. Zash


  142. lovetox_

    the vcard xep says server should answer it for the user

  143. Zash


  144. lovetox_

    otherwise how would you request a vcard of an offline user?

  145. jonas’

    lovetox_, ask the bare JID?

  146. Zash


  147. 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

  148. lovetox_

    or we dont want it in a muc (anon maybe), then the muc should not even start to route IQs

  149. 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.

  150. lovetox_

    no it says to respond to bare jid

  151. lovetox_

    and how is this ever going to work in MUC?

  152. lovetox_

    how can i address your bare jid in a anon room?

  153. Zash

    You can't.

  154. Zash

    Server can forward the request to your bare JID, like Prosody does

  155. lovetox_

    and you do this now for any IQ request

  156. Zash

    No, only for a small set of known namespaces, namely vcard-temp, pubsub and vcard4.

  157. lovetox_

    yeah and you dont see this as a problem?

  158. Zash


  159. lovetox_

    this is nowhere specificed, its a hack

  160. lovetox_

    and one that is a privacy issue on top

  161. Zash

    As was the vcard-temp routing thing.

  162. Zash

    However that's considered public data

  163. lovetox_

    i consider it public data to people who know my adress

  164. Zash

    Don't put it in your globally public vcard then

  165. Zash

    What is the point of the JABBERID field?

  166. 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

  167. lovetox_

    im not saying we should prevent routing IQs, it just should be revisited for public anon rooms

  168. lovetox_

    and for non-anon rooms you dont have to route IQs at all

  169. lovetox_

    clients should just request the real bare jid

  170. lovetox_

    so who needs these public anon rooms that compromise the privacy of their participants? What use case do they fullfill exactly

  171. 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

  172. lovetox_

    this idea, i make my room anon, but still keep all features of non-anon rooms, is a bad solution

  173. lovetox_

    and i would argue its to the disadvantage of all users that join

  174. Zash

    I think you exaggerate the privacy impact somewhat.

  175. Zash

    I also never said I was against having this as a setting.

  176. pep.

    I don't think saying "public vcard is a privacy issue" is an eggageration :x

  177. Zash

    Don't put stuff there if you don't want it public for everyone everywhere, which is how vcard-temp works.

  178. jonas’

    to be fair, I was also surprised that my avatar is exposed in anon MUCs

  179. 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.

  180. Zash

    So, people have varying expectations.

  181. pep.

    Ah that reminds me I need to open an issue about that

  182. lovetox_

    yes Zash, thats because we did water down anon rooms, so people dont even know anymore what they are there for

  183. Zash

    Now Prosody makes those public by default, but still respects it if you change their settings.

  184. pep.

    Prosody still broadcasts my avatar hash in the presence even though I have access_model of vcard4 set to presence

  185. pep.

    in MUCs*

  186. Zash

    avatar and vcard4s are separate nodes tho

  187. pep.


  188. Zash

    And you can have separate permissions. I do, in fact.

  189. pep.

    I also do have that node set to presence I think

  190. Zash

    If you query my vcard through here you only get the avatrarwavatar

  191. 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

  192. lovetox_

    so even if the discussion started with me, asking you for these settings, its more of a general discussion

  193. Zash

    Some of the problem is that there are two separate issues

  194. lovetox_

    in my opinion we should make the consequences clear what anon means, and follow through with it

  195. Zash

    Or more?

  196. lovetox_

    not try and find ways how we can water down anon

  197. lovetox_

    how we can bring features to anon that can not work with anon

  198. Zash

    You mean semi-anon? True anon rooms is dead afaik.

  199. lovetox_

    yeah of course

  200. lovetox_

    i would not go that route arguing true anon is not possible so also fuck semi-anon

  201. Zash

    I feel like this is a topic for a summit, rather than late saturday. :)

  202. lovetox_

    there is a good usecase for semi-anon

  203. 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?

  204. pep.

    lovetox_, what larma quoted in his mail no?

  205. Zash

    https://xmpp.org/extensions/xep-0045.html#bizrules-iq ?

  206. pep.

    That doesn't specify bare or full though

  207. lovetox_

    ah its not specified

  208. lovetox_


  209. lovetox_

    yeah thats a real fail here

  210. Zash

    Nor which one if there's MSN involved.

  211. Zash

    I believe prosody picks one (probably the first) as the "primary" session and sends to that.

  212. lovetox_

    i mean it would be fine if you route to full jid

  213. lovetox_

    then the client can decide itself if he wants to reveal his data or not

  214. jonas’

    although larma argued that even that isn’t good enough from a privacy perspective.

  215. Zash

    That lets yo do timeing things.

  216. 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.

  217. jonas’

    (see also https://lab.louiz.org/poezio/poezio/issues/3419 )

  218. lovetox_

    jonas its already ddosed with disco info requests :D

  219. jonas’

    avatars are an order of magnitude worse though

  220. jonas’

    or a few orders actually

  221. Zash

    disco#info could be cached

  222. 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

  223. lovetox_

    Zash avatars are also cached

  224. jonas’

    lovetox_, guess what, that exists already

  225. jonas’

    that’s why vcard is handled by the bare JID ;)

  226. lovetox_

    i mean a user configurable setting

  227. lovetox_

    not a server admin setting

  228. jonas’

    that exists, it’s the visibility of the avatar pubsub node nowadays

  229. jonas’

    at least for some implementations, and that’s even specified

  230. jonas’


  231. lovetox_

    hm yes this could work

  232. Zash

    As I mentioned, you can fiddle with access control on the avatar and vcard4 nodes to do nice things.

  233. lovetox_

    so if i set it to presence, then my avatar is hidden

  234. pep.

    Maybe we need to add something like "also adjust presence broadcast if a user decides to use something else than open

  235. jonas’

    I always forget whether directed presence counts for `presence` or not

  236. Zash

    jonas’: not

  237. jonas’


  238. lovetox_

    yeah fine workaround, im of the opinion we should deactivate IQ routing in anon rooms by default

  239. jonas’

    lovetox_, I tend to agree with that

  240. Zash

    "presence" is an awkward name for it since it's based on roster (presence) subscriptions

  241. 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

  242. larma

    (I would probably opt for the first, if not every client would now by default make OMEMO pep nodes public)

  243. lovetox_

    Zash, whats the motiviation behind not allowing PMs?

  244. Zash

    lovetox_, ever had people join your support room and then PM you support questions?

  245. Zash

    IIRC it's also been requested by others. Don't remember their motivation. I'm sure there's use for it.

  246. jonas’

    I would like to turn off PMs as a user right now.

  247. 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

  248. jonas’

    larma, I agree on the first part, but I’m not sure on the second part

  249. jonas’

    although if we had to pin it down one way, I’d say "route to bare JID"

  250. 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...

  251. jonas’

    similar to how we version carbon rules at the moment, indeed

  252. lovetox_

    larma, server should add a config options to muc, default to not route IQs, and advertise the setting in disco info

  253. lovetox_

    then the client can warn its users before joining such a anon but still routing IQs MUC

  254. chronosx88

    Hey, guys. Does MAM support for chat room state changes? (E.g. chat room name or subject)

  255. larma

    lovetox_, yes that would work

  256. jonas’

    chronosx88, subject yes, name not

  257. Zash

    Does it?

  258. chronosx88

    And how offline user will know, that room name is changed?

  259. lovetox_

    jonas, i dont think subject changes are in MAM

  260. jonas’

    lovetox_, oh

  261. jonas’

    chronosx88, I guess you’d query that when you rejoin the room

  262. chronosx88


  263. lovetox_

    chronosx88, you do a disco info to the muc before you join

  264. lovetox_

    and if the room name changes, the muc has to issue a status code for changed configuration

  265. lovetox_

    which should trigger your client to do again a disco info to get the new name

  266. chronosx88

    I just comparing XMPP and Matrix by technical abilities and simplicity

  267. lovetox_

    MAM is a message archive, it does not hold any configuration infos of MUCs

  268. lovetox_

    all configuration info is available via disco info to the muc jid

  269. lovetox_

    and all changes to the configuration are announced via message to joined and even not joined participants

  270. lovetox_

    (if they are in the member list of a muc=)

  271. chronosx88

    And... How it can synchronized when user didn't open client?

  272. lovetox_

    and you should disco info a muc before you join if you certain configuration fields like muc name are important to you

  273. chronosx88

    > And... How it can synchronized when user didn't open client? Or really is offline.

  274. lovetox_

    im not sure what you mean, if you are offline per definition nothing can be synced

  275. lovetox_

    because you are offline

  276. chronosx88


  277. lovetox_

    if you start your client, and join the rooms the user was in last time

  278. lovetox_

    before you join, the client sends a disco info to the muc, to get the current configuration

  279. lovetox_

    you could call that the "sync"

  280. chronosx88


  281. lovetox_

    from that point on if you are joined, and configuration changes while you are online and joined

  282. lovetox_

    the muc informs you about it

  283. chronosx88

    Another question: how I can sync unread messages count between clients?

  284. lovetox_

    your best bet is XEP-0333 chat markers

  285. chronosx88

    And point in chat room, when I last time stopped reading

  286. chronosx88

    > your best bet is XEP-0333 chat markers Hm... Ok, will read it

  287. lovetox_

    where you stopped reading is a client UX problem, with chat markers, you can mark the messages you read on a client

  288. lovetox_

    and sync this info to your other clients, which can act accordingly

  289. Zash

    Did anyone have plans to make a PEP based unread message tracking thing?

  290. larma

    Zash, why?

  291. Zash

    IIRC there was talk about something like that, or at least changing 333.

  292. pep.

    Zash, on, I'd like that

  293. pep.

    To sync reading state between clients

  294. larma

    but you can already do that using MAM, no?

  295. pep.

    Can you?

  296. Zash


  297. larma

    well if a 333 marker is send as a message, MAM should store it

  298. 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

  299. pep.

    Sending only 333 to myself then?

  300. Zash

    Never seen that before.

  301. pep.

    I don't especially want others to know

  302. lovetox_

    pep., i think this would be possible

  303. lovetox_

    you could send chatmarkers to yourself

  304. lovetox_

    its very ugly because you get a hell of duplicated messages

  305. pep.


  306. lovetox_

    but i think this would work

  307. larma

    Ah right, If you don't want the other end to know, 333 is probably not best suited

  308. lovetox_

    BUT only if you use unique stanza ids in every conversation

  309. lovetox_

    otherwise you lose the context

  310. larma

    Yeah, makes sense, if you don't want to send to other end, PEP is better than MAM

  311. lovetox_

    you could do this analog to bookmarks 2

  312. lovetox_

    one node, with X items, and item-id = jid of contact

  313. lovetox_

    then add the current stanza id that you read