XSF Discussion - 2021-06-30

  1. Ge0rG

    MattJ: nice Moved 2 XEP! I'd love to have it published as new 0283, but that's not a hill to die on. However, if the server performs the move dance, clients will end up not knowing that it's the same account as the old JID, and chat history won't get merged / migrated.

  2. MattJ

    Yes, suggestions welcome for how to notify the clients

  3. MattJ

    Unfortunately it seems all they get right now is a roster push, and I was hesitant to open that can of worms (roster annotations)

  4. Ge0rG

    I'd like to have some sort of marker in the chat history at that place, maybe a normal message from the old JID with the moved element?

  5. MattJ

    But that might be the only way

  6. Ge0rG

    And another one from the new JID?

  7. jonas’


  8. Ge0rG

    A dumb client could just display a link to the respective other JID in the chat, a smart one would merge histories.

  9. jonas’

    I think I’d prefer if the server generates that, and in a way which cannot be spoofed by remote JIDs

  10. jonas’

    but I think those requirements don’t go together d(

  11. jonas’

    but I think those requirements don’t go together :(

  12. jonas’

    because what you describe requires from=oldjid and from=newjid, and then we enter spoof territory, unless the server does deep message inspection

  13. jonas’

    (which it has to anyway, mind, for stuff like Delayed Delivery, but it makes things harder in the "server has no support scenario")

  14. jonas’

    (which it has to anyway, mind, for stuff like Delayed Delivery and Stanza IDs, but it makes things harder in the "server has no support scenario")

  15. Ge0rG

    jonas’: well, there is no point for spoofing from oldjid, so that part is safe.

  16. Ge0rG

    And the newjid message needs to be verified in some way, e.g. by checking the existence of a respective message from oldjid. My server could easily inject both, not that's not a requirement.

  17. Ge0rG

    And the newjid message needs to be verified in some way, e.g. by checking the existence of a respective message from oldjid. My server could easily inject both, but that's not a requirement.

  18. jonas’

    Ge0rG, is there not? if you can trigger a history merge, I am sure you can do some odd things there

  19. Ge0rG

    Look folks, I hereby migrate into jonas@xmpp.org!

  20. Ge0rG

    (nothing bad has happened)

  21. jonas’

    or how about into xsf@muc.xmpp.org?

  22. Ge0rG

    Now this is fun!

  23. Ge0rG

    Moved doesn't prevent you from that.

  24. jonas’

    moved 2 does, because you cannot get xsf@muc.xmpp.org to emit the <moved/> presence… or can you

  25. MattJ

    The current proposal does, because you have to be able to send a subscription request + custom payload from the new JID

  26. jonas’

    MattJ, security_considerations:add("<moved/> in presence emitted from non-bare (i.e. full JIDs) MUST be ignored")

  27. jonas’

    or are subscription requests from full JIDs?

  28. jonas’

    they probably are, aren’t they?

  29. Ge0rG

    I just wondered what happens if you send a subscription request as a room presence.

  30. jonas’

    Ge0rG, ^ :)

  31. jonas’

    but you can’t, because the room won’t forward type="subscribe". you just shoot your self in the foot by having the room added to your roster

  32. Ge0rG

    I'm sure nobody anticipated that and weird things will happen

  33. Ge0rG

    jonas’: you sure?

  34. jonas’

    oh yes, I think conversations will start to treat it as 1:1

  35. jonas’

    I think people do that often enough by accident

  36. Ge0rG

    Gajim used to add rooms to the roster, with all sorts of weird effects, including GC1.0

  37. Kev

    I was deliberately putting MUCs in my roster back in 2001 or so.

  38. jonas’

    everyone loves gc1.0

  39. jonas’

    Kev, now that explains MIX ;D

  40. jonas’

    also, random note: that was twenty years ago

  41. Kev

    *shrug* Some of us have been around for a while.

  42. Ge0rG

    Kev: but that would confuse any sane client, right?

  43. Ge0rG

    Suddenly you get room traffic without explicitly having joined it.

  44. Kev

    Actually, it wouldn’t have been 2001, it would have been 2002+, because I did it in Psi.

  45. Kev

    Ge0rG: They were bookmarked too.

  46. Ge0rG

    Kev: race conditions?!

  47. Kev

    Is there? I don’t remember, the account I used back then is lost to the mists of time, and I’ve not done it in a while.

  48. Kev

    Actually, it would have been GC1 back then, rather than MUC, too.

  49. Kev

    So yes, probably race conditions.

  50. Kev

    Ah, no, because there’s no sub.

  51. Ge0rG

    Kev: yes, but even with that, all clients I know can't process room join responses without having sent a join presence first. And I'm sure they'll start with initial presence and only then query bookmarks

  52. Ge0rG


  53. Kev

    Yes, but the initial presence doesn’t go to the room.

  54. Ge0rG

    Yes. It's ugly, but not broken.

  55. jonas’

    so XEP-0313 is hanging in limbo because some want the archiving rules written down clearly, but nobody is there to take up the work.

  56. MattJ

    Does anyone know what the archiving rules are? Is there consensus that they *can* be encoded into a Draft document?

  57. MattJ

    It seems to me they have been evolving over the past years

  58. Zash

    And they are likely to continue evolving

  59. MattJ

    (which is why I worked on Hints, but that apparently did not suffice)

  60. jonas’

    I think the consensus is that the rules should evolve in a document, not in hints attached to messages

  61. jonas’

    it could very well be Informational for instance to have it changed more easily

  62. jonas’

    if a server dev wrote down the rules *they* use, put that up for discussion and other server devs compared with their implementation, that’d be very productive I think

  63. MattJ

    That sounds wrong (it is not merely "informative" if it's a core part of how the protocol works)

  64. Zash

    I may have promised to do that, and may even have a draft translation of the Prosody code somewhere

  65. MattJ

    It also seems wrong if it's not versioned

  66. jonas’

    MattJ, right, standards track + namespace versioning + feature announcement?

  67. jonas’

    afk now though

  68. Holger

    XEP-0060 says: > A node may have a large number of items associated with it, in which case it may be problematic to return all of the items in response to an items request. In this case, the service SHOULD return some of the items and note that the list of items has been truncated by including a Result Set Management (XEP-0059) notation. So PubSub clients _must_ support RSM, at least if they ever query >1 items, right? (While PubSub servers may omit RSM support.)

  69. flow

    fwiw, I think xep313 archiving rules can be suggestions and best practices, and hence could probably go in an extra informal XEP. In any case services could signal that they follow the rules with an extra namespace

  70. Zash

    carbons and csi too

  71. MattJ

    I still prefer the hints model, where we encode everything needed directly into the protocol (and then minimal rules into 313)

  72. Ge0rG

    MattJ: IM-NG?

  73. MattJ

    That would certainly be a big improvement, yes

  74. Ge0rG

    And for that, we need compatibility routing and storage rules.

  75. Holger

    goffi, posted my XEP-0413 questions on the list now.

  76. goffi

    Holger: thanks, I'll check that tomorrow

  77. Holger


  78. flow

    MattJ, yeah, I'd also like to continue exploring the hints approach

  79. Sam

    Hi editors, I never heard back about my request. Going to make it again, please issue a LC for https://xmpp.org/extensions/xep-0292.html. Thanks!

  80. Sam

    Also while we're at it, https://xmpp.org/extensions/xep-0359.html. It's deferred but also widely used and should probably either be worked on, deprecated, or moved on.

  81. Zash

    I take it it's expired because 2020-11-03 is over a year ago in pandemic time?

  82. Sam

    huh, that's odd, I didn't notice that

  83. Zash

    And https://xmpp.org/extensions/xep-0292.html#revision-history-v0.11 was merged recently, but the date is the date when the edit was made

  84. Zash

    Time is wibbly wobbly as usual.

  85. Sam