XSF Discussion - 2020-07-07


  1. Daniel

    is there anything in XMPP-IM that requires me to use full jids? or could i just send one presence coming from the bare jid of my account?

  2. jonas’

    Daniel, talking from a server perspective?

  3. jonas’

    because as a client, you don’t have control over @from.

  4. jonas’

    also, yes, RFC 6121 e.g. §4.3.2 requires the server to send presence from all currently available resources

  5. Daniel

    yes talking about s2s interop. and interop with other clients. what I have in mind is a scenario where we replace most of c2s and have the server expose just one account to the outside world

  6. Daniel

    instead of multiple clients

  7. jonas’

    uh https://tools.ietf.org/html/rfc6121#section-4.2.2 this is also very strict wording

  8. Daniel

    so the server would just send out one bare jid presence instead of multiple full jids

  9. jonas’

    you’d be in direct violation of that

  10. jonas’

    which is a MUST

  11. Zash

    You probably could get away with it tho

  12. Daniel

    thinking this further you'd also receive PEP updates on the bare jid

  13. Daniel

    and so on

  14. Daniel

    and join mucs with your bare jid instead of full jids

  15. jonas’

    Daniel, and then receive @type="groupchat" to the bare JID?

  16. Daniel

    yes

  17. jonas’

    this sounds like IM-NG / MIX territory

  18. jonas’

    bare JID-ing the presence could be part of IM-NG

  19. Daniel

    it is sort of an idea to circumvent problems we are facing with upgrading to im-ng

  20. Daniel

    obviously my server / the way we are currently doing c2s would require a big overhaul

  21. jonas’

    if bare-JID-ing presence helps with that by tricking legacy deployments, it should be part of IM-NG

  22. Zash

    I made a thing for that, for MUC. Sorta worked

  23. Daniel

    but the goal is that everything s2s remains fully compatible

  24. jonas’

    hm, I’m not convinced that we should put the complexity in overhauling c2s

  25. Daniel

    yeah it's just some ideas that i've been carrying around with me for a while and i'm probably not doing a good job at describing it right now

  26. Zash

    I suspect this will complicate servers.

  27. Daniel

    obviously

  28. Daniel

    but it could be a way to not do mix and mix-pam

  29. Zash

    The thing I made was basically a bouncer.

  30. Daniel

    yes i guess what i have in mind can be described as a bouncer

  31. Daniel

    but not just for muc

  32. Daniel

    but also PEP and everything

  33. Daniel

    anything <message>

  34. jonas’

    Daniel, how would you know where to send IQs when you don’t get full-JID presence?

  35. Daniel

    jonas’, we are getting into the details here. but IQs would be the only thing that is still allowed to go to full jids. and I imagine that you have to do jingle message init

  36. Daniel

    and then the receiving clients tells you the full jids for that particular session

  37. Daniel

    or something like that

  38. jonas’

    Daniel, sure, but how would you learn the full JID?

  39. jonas’

    uh

  40. jonas’

    so an extra protocol for clients to get a set of full JIDs?

  41. jonas’

    that sounds awful

  42. Daniel

    well we already have jingle message init

  43. jonas’

    I’m not convinced that we can or should map all IQ flows to <message/>

  44. jonas’

    and having an extra round-trip before initiating an IQ sounds meh

  45. Zash

    Brining back resource locking...?

  46. Daniel

    or at least we already have the desire of sending p2p sessions to the account and then have the receiver choose one what device they want to accept the p2p session

  47. jonas’

    Daniel, that’s true

  48. Daniel

    i mean it's obviously not a fully formed idea

  49. jonas’

    sure

  50. Zash

    Shifting PEP away from full JID subscriptions would be nice tho

  51. jonas’

    I’m asking critical questions to bring it closer

  52. Daniel

    and it will certainly create new problems

  53. jonas’

    abolishing a push-way for clients to learn about full JIDs would at least break things for my "IoT" use-cases

  54. jonas’

    while IM-NG by itself as it is currently would not

  55. jonas’

    (because I don’t use <message/> at all, just <presence/> and <iq/>)

  56. Daniel

    well if we call that XMPP-C2S-2.0 that nothing in there requires your iot devices to use that

  57. Zash

    Maybe we need that IM-NG discussion

  58. Daniel

    they can still use c2s-1.0

  59. jonas’

    Daniel, but can they interop with c2s-2.0 devices?

  60. jonas’

    if those only send bare JID?

  61. jonas’

    if those only send bare JID presence?

  62. Daniel

    i guess c2s-2.0 can still *receive* full presences

  63. Daniel

    which if i'm understanding your iot problem correctly would be fine, no?

  64. jonas’

    Daniel, it requires both, sending and receiving full presences.

  65. jonas’

    because the peers learn their IQ partners from presence

  66. jonas’

    because I heard that hardcoding resources is not good ;)

  67. Daniel

    so you have human interaction with iot devices?

  68. Daniel

    because if it's just iot talking to iot they can all use c2s1

  69. jonas’

    I at least have IoT-ish things which need to talk to both worlds

  70. jonas’

    MUC bots which talk to the devices for a text human interface

  71. jonas’

    those would have to learn the full-JID presence of the devices. the devices may not have to learn the full-JID presence of the bot though ....

  72. jonas’

    but it feels like an ugly restriction

  73. Daniel

    right. i mean the general goal is ovbisouly that anything that is exposed over s2s should remain fully compatible with the outside world. however within c2s2 i’d be fully ok with dropping some (niche) use cases in order to have nice things

  74. Daniel

    the combination of my idea not being fully formed and not understanding your use case makes it impossible to say if your use case would be one of those niche cases that i'd be dropping

  75. jonas’

    the use case is rather simple: the devices have a roster of peers (and they know the bare JID of peers with specific functions, i.e. IQ interfaces). They use presence to learn the full JID to send the IQs to and to learn when they go offline etc.

  76. Andrzej

    Daniel, do you really thing that reworking basic assumptions in c2s and presence to "fix broken MUC" just to get what MIX, MIX-PAM would allow you to do is ok?

  77. Daniel

    it's not just muc but also all kind of message routing. PEP; errors

  78. pep.

    Andrzej, I'm not sure what's the matter if it's a new protocol

  79. Daniel

    but yes. at least that's a random idea that i've been thinking about

  80. Andrzej

    pep, sure start with bumpimg XMPP version to 2.0

  81. Daniel

    not saying it's a good idea

  82. pep.

    Andrzej, there's a thing called XEPs I've heard :p

  83. Daniel

    the question is also how many 'basic assumptions' we'd be violating if we use the bare jid to send presence or join mucs

  84. Andrzej

    pep, I know, but I just disagree with changing so basic assumptions and drop a way to discover other devices full jids (presences) by forcing presence to use bare jid

  85. Daniel

    i mean XMPP (not IM) certainly allows you to send presence from the bare jid

  86. Daniel

    and 45 also doesn’t mandete you use full jids, no?

  87. Andrzej

    XMPP allows you to send presence with no resource, but C2S forces server to overwrite from attribute so you end up with full jid

  88. Daniel

    right. but as a client i think you should also be prepared to *receive* presences from a bare jid

  89. jonas’

    Daniel, but only type="error"

  90. jonas’

    (as well as type="{un,}subscribe{,d}")

  91. Andrzej

    I've encountered already presence from bare jid with type = unavailable :/

  92. Andrzej

    Daniel, XEP0045 section 7.2.2.: > If the service is able to add the user to the room, it MUST send presence from all the existing participants' occupant JIDs to the new occupant's full JID

  93. flow

    Andrzej, I think you have to relax you view on xep45 if you remove full JIDs from the game, but it could be that the places where xep45 talks about full JID are not so plentiful that it couldn't work

  94. Andrzej

    XEP-0045 just almost everywhere mentions sending message stanza to full jid of the occupant, so at least we "should" (?) update XEP-0045 to use "send to occupant JID"

  95. flow

    Andrzej, I think we'd have to relax your view on xep45 if you remove full JIDs from the game, but it could be that the places where xep45 talks about full JID are not so crucial that it couldn't work

  96. Andrzej

    pepo, sure, but some XMPP RFC AFAIR forces server not to deliver messages of type groupchat to bare jid

  97. Andrzej

    pep, sure, but some XMPP RFC AFAIR forces server not to deliver messages of type groupchat to bare jid

  98. Daniel

    that's true. but a server supporting xmpp-c2s2 could lift that rule

  99. Daniel

    i mean that's totally up to the user’s server. as long as it doesn’t break other servers

  100. flow

    doesn't mix already send type='groupchat' messages to the bare JID, and we assume it's ok because it was negotiated?

  101. Andrzej

    true, but how about MUC with bare jid and "history sync" without MAM?

  102. Andrzej

    flow, yes we do

  103. Daniel

    c2s2 would just mandate 'something like MAM'

  104. Andrzej

    as I said, so many changes that it asks for XMPP 2.0

  105. Daniel

    yes. but only for c2s

  106. Daniel

    or at least that'd be the goal

  107. Daniel

    keep s2s and interop with the outside world

  108. Daniel

    and redo vast parts of c2s

  109. Daniel

    if you want to call that xmpp 2.0 or something else is probably for the marketing department to decide

  110. Andrzej

    well, it is something that marks significant change

  111. Andrzej

    will that work if you have 2 c2s connections? 1 old and 1 new?

  112. Daniel

    the idea is not fully developed yet to say. but i'd be fine with the answer being no

  113. Daniel

    if that gives us beneftis

  114. Andrzej

    I do not have anything against c2s2 but I would prefer not to break RFCs in many places and at least for me now, idea of MIX is far better than fixing MUC (too many issues)

  115. Andrzej

    also idea of having MAM of MIX channel in user MAM archive works far better than querying each MUC room MAM archive on join (or reconnect)

  116. Daniel

    the goal would obviously be to still able to chat with 'pidgin' on the other and still join any kind of muc. so the RFC should only be violated to a degree where it doesn’t cause any real harm

  117. Daniel

    however much we may or may not not to stretch the exact wording of the RFCs to achieve that

  118. Andrzej

    Daniel, for c2s2 and bare jid in presence, would it mean that presence would be sent not so often? (if so, that could lead to desynchronization between MUC room occupants list and state of your client on your own server)

  119. Daniel

    probably maybe never

  120. Daniel

    if you think of xmpp-c2s2 as a bouncer

  121. Daniel

    or your server acting as a bouncer and c2s2 being the protocol that you use to connect to said bouncer

  122. Daniel

    note that i'm not (just) speaking from a perspective of 'fixing muc' or 'avoiding mix' - but also about the the whole carbons mess

  123. Daniel

    i don’t hate MIX

  124. Andrzej

    I forgot about carbons, all software which I use sends message to bare JID and with MIX that works like a charm without carbons

  125. Andrzej

    and with MUC I do appreciate a way in which I can be in some rooms on my desktop and not join on the mobile using the same account

  126. Daniel

    Well even if you send messages to the bare jid. For outgoing messages as well as error bounces you still have to deal with carbons

  127. Daniel

    From an end user perspective carbons or broadly receiving messages on all devices is 90% solved

  128. Daniel

    But the other 10% are an absolute nightmare

  129. Andrzej

    true, but it somehow I feel that the server should bounce back sent message anyway (ie. to delivery stable-id for it)

  130. Andrzej

    but that is a larger topic to discuss

  131. Andrzej

    to sum up my position: I like the idea to improve message routing and deal with carbons, but I do not think that presence with bare jid is a good idea

  132. emus

    Hello everyone, the monthly XMPP Newsletter has been published! 📨☕ https://xmpp.org/2020/07/newsletter-01-july/

  133. moparisthebest

    nice work!

  134. flow

    emus, thanks!

  135. emus

    Thank you! That counts for all the contributors as well!