MattJJust 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
Ge0rGwaves with the "told you so" stamp
ZashAnd what is the point of @id == origin-id/@id for normal chat messages?
mdoschadmits to don't know (yet) what's the difference between those IDs.
MattJJust pretend origin-id doesn't exist, and join the campaign to have it removed from the XEP :)
ZashLook at this and tell me, for each byte, why you really need it:
<message type='chat' firstname.lastname@example.org' email@example.com/c' id='ceb792ed-e033-4e2d-8e00-c01dbc2e7673' xml:lang='en'>
<origin-id id='ceb792ed-e033-4e2d-8e00-c01dbc2e7673' xmlns='urn:xmpp:sid:0'/>
<stanza-id id='BsxtFkWgYn1TCs5c' xmlns='urn:xmpp:sid:0' firstname.lastname@example.org'/>
<delay xmlns='urn:xmpp:delay' stamp='2021-03-22T12:47:00Z' from='recv.example'/>
flowmdosch, 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
flowand <origin-id/> is simply the ID the entity where the stanza originated from assigned
MattJand 'id' is what?
mdoschOk, I think I go for 'pretend it doesn't exist' until I have time to thoroughly look at this.
KevI also don’t see why origin ID can’t be a stanza ID stamped by the originator :)
flowKev, to avoid leaking the JID
flowconsider a semi-anonymous MUC for example
KevOr a stanza-id with no originator, then :)
But yes, I’d forgotten about that.
flowKev, allowing <stanza-id/> without by attribute would complicate the rules for <stanza-id/> validation
Ge0rGCan we just get rid of origin-id and pretend it never existed?
jonas’et ceterum censeo origin-id delendam esse?
larmaAs 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.
Link MauveFor 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.”
larmaWhich was only added later and may be in conflict with RFC✎
larmaWhich was only added "recently" and may be in conflict with RFC ✏
Ge0rGlarma: what's the "current stream" in an s2s context?
larmaHard to say. But in RFC terms, the originator of a broadcasted MUC message clearly is the MUC service
Ge0rGlarma: and it could "open" a new "stream" for each message
larmaI'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
larmaBut how does it match error messages then?
Ge0rGlarma: 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
larmaGe0rG, huh? I can just not reuse the id with a single recipient but reuse with another recipient
larmai.e. sending <message id="1" to="email@example.com" /> and <message id="2" to="firstname.lastname@example.org" /> would then be allowed because any error message could still be matched✎
larmai.e. sending <message id="1" to="email@example.com" /> and <message id="1" to="firstname.lastname@example.org" /> would then be allowed because any error message could still be matched ✏
Ge0rGlarma: 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
larmayes, that's true
larmaexcept if you change your JID of course 😉
Ge0rGWell, welcome random non persistent resource identifiers!
ZashSomething something (kind, id, to, from) unique, or somesuch.
larmayeah, except that MUCs don't use random resource identifiers so they can't guarantee uniqueness on that pair when forwarding an incoming message.
ZashAnd errors have to/from flipped. Easy. What we talking about?
Ge0rGSo the RFC can't be followed in any sensible form and we should change it
Zashlarma, still applies to the full JID pairs, does it not?
Ge0rGlarma: my point is that any implementation that will rely on id never repeating will have been broken a long time ago
larmaGe0rG, ehm, don't we see issues with clients when any other client do it repeatedly?
Ge0rGBecause 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
Ge0rGlarma: only on receiving clients that think a "stream" is something eternal and persistent
larmain practice we have XEPs that by design would break should ids be reused.
larmawe just workaround by making them use origin-id
ZashIf you do that, do you break anything but yourself (the client)✎
ZashIf you do that, do you break anything but yourself (the client)? ✏
larmayou typically break the recipient client 😉
Ge0rGlarma: an evil client will break you by sending repeated origin-id. You haven't solved anything, you just limited the problem to pidgin.
larmait's not about evil clients, it's about standard compliant clients
Ge0rGExcept that pidgin won't send origin-id so it's exactly the status quo, but with one more useless xml element
ZashWhat if the MUC just renumbers all the messages, but includes the origin-id in the reflection back to the sender (and only to them)
Ge0rGZash: what if MUC renumbers all the messages but the one sent to the original sending client?
Ge0rGBut also what if the client gets reconnected between sending the message and getting the reflection?
larmaGe0rG, the original client wouldn't know the MUCs message id 😉
larmaLet's just agree that MUC is just a bunch of hacks and undefined behavior
Ge0rGWhat if we stop relying on message id being unique except for purposes of reflection tracking?
larmaYou mean as it's described in the RFC?
Ge0rGShould a client be able to send a correction to a message that's still in flight?
ZashBring back "last" message correction
ZashOr should we finally go ahead and mandate all IDs be HMAC(stream-id, stanza counter) ?
Ge0rGZash: have the server rewrite any client ID into this format!
Ge0rGWith eternal tracking, of course
ZashPlus the client can know AOT what id messages will have
ZashDidn't we invent this at every summit?
Ge0rGZash: yes, and I liked it every time
Ge0rGLet's make it part of XMPP 2.0
Ge0rGBut then it won't prove that the ID is really unique to other servers.
Ge0rGSo we don't gain anything in the presence of malicious servers.
Zash"Don't write malicious servers"
Ge0rGExcept that you could terminate s2s to a server that sends repeating IDs
ZashMake every entity on the path attach their own ƒ(stream-id, counter)! Seal it with crypto, no, blockchain!
Ge0rGZash: but then we reuse the counter from 0198, only to realize that it'll wrap around at 2^31