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
BASSGODhas joined
ajeremiashas left
Ge0rGwaves with the "told you so" stamp
florettahas left
florettahas joined
pasdesushihas left
Andrzejhas joined
lovetoxhas joined
Andrzejhas left
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 :)
Sam⤴️
pasdesushihas joined
ZashLook 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>
```
Link Mauve:|
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
mdosch🤔
MattJand 'id' is what?
mdoschOk, I think I go for 'pretend it doesn't exist' until I have time to thoroughly look at this.
BASSGODhas left
Zashmod_if_id_eq_origin_id_then_remove_it
pasdesushihas left
Andrzejhas joined
BASSGODhas joined
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
Andrzejhas left
Andrzejhas joined
Ge0rGCan we just get rid of origin-id and pretend it never existed?
jonas’et ceterum censeo origin-id delendam esse?
arcxihas left
arcxihas joined
andrey.ghas joined
arcxihas left
arcxihas joined
arcxihas left
arcxihas joined
peetahhas left
arcxihas left
arcxihas joined
arcxihas left
Mikaelahas joined
arcxihas joined
Mikaelahas left
Andrzejhas left
peetahhas joined
Mikaelahas joined
Andrzejhas joined
Wojtekhas left
Mikaelahas left
peetahhas left
peetahhas joined
mathijshas left
peetahhas left
Andrzejhas left
peetahhas joined
mathijshas joined
nad200has joined
Andrzejhas joined
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.
Nekithas joined
alameyohas left
marchas left
flowhas left
pasdesushihas joined
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?
pasdesushihas left
larmaHard to say. But in RFC terms, the originator of a broadcasted MUC message clearly is the MUC service
pasdesushihas joined
Danielhas left
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
marchas joined
larmaBut how does it match error messages then?
pasdesushihas left
pasdesushihas joined
Andrzejhas left
Andrzejhas joined
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
Danielhas joined
nad200has left
pasdesushihas left
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="a@example.org" /> and <message id="2" to="a@example.org" /> would then be allowed because any error message could still be matched✎
larmai.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 ✏
pasdesushihas joined
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.
neshtaxmpphas left
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?
larmaGe0rG, why?
Ge0rGlarma: my point is that any implementation that will rely on id never repeating will have been broken a long time ago
Zashon s2s?
larmaGe0rG, ehm, don't we see issues with clients when any other client do it repeatedly?
pasdesushihas left
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
Nekithas left
Ge0rGlarma: only on receiving clients that think a "stream" is something eternal and persistent
nad200has joined
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
pasdesushihas joined
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 😉
mathijshas left
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?
pasdesushihas left
pasdesushihas joined
larmaYou mean as it's described in the RFC?
marchas left
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!
ZashYes
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.
pasdesushihas left
Ge0rGSo we don't gain anything in the presence of malicious servers.
pasdesushihas joined
werdanhas joined
Zash"Don't write malicious servers"
Ge0rGExcept that you could terminate s2s to a server that sends repeating IDs
nad200has left
pasdesushihas left
pasdesushihas joined
ZashMake every entity on the path attach their own ƒ(stream-id, counter)! Seal it with crypto, no, blockchain!
pasdesushihas left
pasdesushihas joined
Ge0rGZash: but then we reuse the counter from 0198, only to realize that it'll wrap around at 2^31