XSF Discussion - 2021-03-22

  1. MattJ

    Just got off a 2h debugging session, where the root cause turned out to be the client using origin-id where it should have been using stanza-id

  2. Ge0rG waves with the "told you so" stamp

  3. Zash

    And what is the point of @id == origin-id/@id for normal chat messages?

  4. mdosch admits to don't know (yet) what's the difference between those IDs.

  5. MattJ

    Just pretend origin-id doesn't exist, and join the campaign to have it removed from the XEP :)

  6. Sam

    ⤴️

  7. Zash

    Look at this and tell me, for each byte, why you really need it: ```xml <message type='chat' to='zash@recv.example' from='foo@sender.example/c' id='ceb792ed-e033-4e2d-8e00-c01dbc2e7673' xml:lang='en'> <body>Test</body> <request xmlns='urn:xmpp:receipts'/> <markable xmlns='urn:xmpp:chat-markers:0'/> <origin-id id='ceb792ed-e033-4e2d-8e00-c01dbc2e7673' xmlns='urn:xmpp:sid:0'/> <active xmlns='http://jabber.org/protocol/chatstates'/> <stanza-id id='BsxtFkWgYn1TCs5c' xmlns='urn:xmpp:sid:0' by='zash@recv.example'/> <delay xmlns='urn:xmpp:delay' stamp='2021-03-22T12:47:00Z' from='recv.example'/> </message> ```

  8. Link Mauve

    :|

  9. flow

    mdosch, those are not two IDs, there could be multiple <stanza-id/> elements, for example one from the user's archive and one from the MUCs archive

  10. flow

    and <origin-id/> is simply the ID the entity where the stanza originated from assigned

  11. mdosch

    🤔

  12. MattJ

    and 'id' is what?

  13. mdosch

    Ok, I think I go for 'pretend it doesn't exist' until I have time to thoroughly look at this.

  14. Zash

    mod_if_id_eq_origin_id_then_remove_it

  15. Kev

    I also don’t see why origin ID can’t be a stanza ID stamped by the originator :)

  16. flow

    Kev, to avoid leaking the JID

  17. flow

    consider a semi-anonymous MUC for example

  18. Kev

    Or a stanza-id with no originator, then :) But yes, I’d forgotten about that.

  19. flow

    Kev, allowing <stanza-id/> without by attribute would complicate the rules for <stanza-id/> validation

  20. Ge0rG

    Can we just get rid of origin-id and pretend it never existed?

  21. jonas’

    et ceterum censeo origin-id delendam esse?

  22. larma

    As someone asked what 'id' attribute is for, here is the RFC: > The 'id' attribute is used by the originating entity to track any response or error stanza that it might receive in relation to the generated stanza from another entity (such as an intermediate server or the intended recipient). > It is up to the originating entity whether the value of the 'id' attribute is unique only within its current stream or unique globally. > For <message/> and <presence/> stanzas, it is RECOMMENDED for the originating entity to include an 'id' attribute; for <iq/> stanzas, it is REQUIRED.

  23. Link Mauve

    For messages, 0045 adds the requirement that “The [MUC] service SHOULD reflect the message with the same 'id' that was generated by the client, to allow clients to track their outbound messages.”

  24. larma

    Which was only added later and may be in conflict with RFC ✎

  25. larma

    Which was only added "recently" and may be in conflict with RFC ✏

  26. Ge0rG

    larma: what's the "current stream" in an s2s context?

  27. larma

    Hard to say. But in RFC terms, the originator of a broadcasted MUC message clearly is the MUC service

  28. Ge0rG

    larma: and it could "open" a new "stream" for each message

  29. larma

    I'd be tempted to argue that a stream goes from sender ('from') to recipient ('to'), at least that would make sense in this context because every intermediary is allowed to send errors up to the recipient

  30. larma

    But how does it match error messages then?

  31. Ge0rG

    larma: when a stream goes between the respective JIDs, any implementation that eventually re-uses IDs is incompliant, because the stream exists as long as the JIDs exist

  32. larma

    Ge0rG, huh? I can just not reuse the id with a single recipient but reuse with another recipient

  33. larma

    i.e. sending <message id="1" to="a@example.org" /> and <message id="2" to="a@example.org" /> would then be allowed because any error message could still be matched ✎

  34. larma

    i.e. sending <message id="1" to="a@example.org" /> and <message id="1" to="b@example.org" /> would then be allowed because any error message could still be matched ✏

  35. Ge0rG

    larma: not what I'm taking about. You may never reuse an ID to a given recipient because you don't know if they did restart in the meantime

  36. larma

    yes, that's true

  37. larma

    except if you change your JID of course 😉

  38. Ge0rG

    Well, welcome random non persistent resource identifiers!

  39. Zash

    Something something (kind, id, to, from) unique, or somesuch.

  40. larma

    yeah, except that MUCs don't use random resource identifiers so they can't guarantee uniqueness on that pair when forwarding an incoming message.

  41. Zash

    And errors have to/from flipped. Easy. What we talking about?

  42. Ge0rG

    So the RFC can't be followed in any sensible form and we should change it

  43. Zash

    larma, still applies to the full JID pairs, does it not?

  44. larma

    Ge0rG, why?

  45. Ge0rG

    larma: my point is that any implementation that will rely on id never repeating will have been broken a long time ago

  46. Zash

    on s2s?

  47. larma

    Ge0rG, ehm, don't we see issues with clients when any other client do it repeatedly?

  48. Ge0rG

    Because in practice, client implementations were considering a stream as their connection, and used an auto increment for IDs, and that caused repetition issues at all recipients

  49. Ge0rG

    larma: only on receiving clients that think a "stream" is something eternal and persistent

  50. larma

    in practice we have XEPs that by design would break should ids be reused.

  51. larma

    we just workaround by making them use origin-id

  52. Zash

    If you do that, do you break anything but yourself (the client) ✎

  53. Zash

    If you do that, do you break anything but yourself (the client)? ✏

  54. larma

    you typically break the recipient client 😉

  55. Ge0rG

    larma: an evil client will break you by sending repeated origin-id. You haven't solved anything, you just limited the problem to pidgin.

  56. larma

    it's not about evil clients, it's about standard compliant clients

  57. Ge0rG

    Except that pidgin won't send origin-id so it's exactly the status quo, but with one more useless xml element

  58. Zash

    What if the MUC just renumbers all the messages, but includes the origin-id in the reflection back to the sender (and only to them)

  59. Ge0rG

    Zash: what if MUC renumbers all the messages but the one sent to the original sending client?

  60. Ge0rG

    But also what if the client gets reconnected between sending the message and getting the reflection?

  61. larma

    Ge0rG, the original client wouldn't know the MUCs message id 😉

  62. larma

    Let's just agree that MUC is just a bunch of hacks and undefined behavior

  63. Ge0rG

    What if we stop relying on message id being unique except for purposes of reflection tracking?

  64. larma

    You mean as it's described in the RFC?

  65. Ge0rG

    Should a client be able to send a correction to a message that's still in flight?

  66. Zash

    Bring back "last" message correction

  67. Zash

    Or should we finally go ahead and mandate all IDs be HMAC(stream-id, stanza counter) ?

  68. Ge0rG

    Zash: have the server rewrite any client ID into this format!

  69. Zash

    Yes

  70. Ge0rG

    With eternal tracking, of course

  71. Zash

    Plus the client can know AOT what id messages will have

  72. Zash

    Didn't we invent this at every summit?

  73. Ge0rG

    Zash: yes, and I liked it every time

  74. Ge0rG

    Let's make it part of XMPP 2.0

  75. Ge0rG

    But then it won't prove that the ID is really unique to other servers.

  76. Ge0rG

    So we don't gain anything in the presence of malicious servers.

  77. Zash

    "Don't write malicious servers"

  78. Ge0rG

    Except that you could terminate s2s to a server that sends repeating IDs

  79. Zash

    Make every entity on the path attach their own ƒ(stream-id, counter)! Seal it with crypto, no, blockchain!

  80. Ge0rG

    Zash: but then we reuse the counter from 0198, only to realize that it'll wrap around at 2^31

  81. Zash

    `<reset xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>`, bye

  82. deuill

    (I'm sure the above is tongue-in-cheek but) unique message IDs are useful for threading/message attaching/reactions/etc. as well, right?

  83. deuill

    I seem to remember the original RFCs saying IDs SHOULD be globally unique, though I might be wrong.

  84. Ge0rG

    deuill: yes. Any modern client will send globally unique IDs anyway

  85. Zash

    Twice. And then the MUC adds another. And some timestamps on that.

  86. deuill

    Hm, what's to prevent clients from sending duplicates?

  87. deuill

    Oh right yeah.

  88. Ge0rG

    deuill: larma quoted the RFC one and a bit hours ago

  89. deuill

    Yeah I think Dino not doing MAM-MUC bit me there

  90. deuill

    Or is it MUC-MAM

  91. Ge0rG

    deuill: an evil client can do whatever it wants. A broken client will make other clients break some functionality

  92. Ge0rG

    MAM is always using the server generated IDs. Luckily, servers will never misbehave

  93. Zash

    True fact. Servers are perfect.

  94. deuill

    Praise be!

  95. Zash

    Trust in the server. The server is good.

  96. deuill

    What if we just did away with clients altogether and just had the servers talk to one another

  97. mdosch

    To protect and serve?

  98. Zash

    YES

  99. Zash

    As a bonus we then get a pure p2p system

  100. Ge0rG

    Zash: "server" is a discriminatory word, because serving is an implication of involuntary labor.

  101. deuill

    Having worked at a cafe in Greece, I can attest to that

  102. Zash

    Ge0rG: What, you don't tip your servers?

  103. Ge0rG

    Zash: xmp2p!

  104. Ge0rG

    Zash: no, I master them.

  105. deuill

    Please don't tip your servers, the hard drives will thank you

  106. Ge0rG

    Hard drives have been forbidden a long time ago, because of the IDE Master Slave jumped ✎

  107. Ge0rG

    Hard drives have been forbidden a long time ago, because of the IDE Master Slave jumper ✏