-
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
- Ge0rG waves with the "told you so" stamp
-
Zash
And what is the point of @id == origin-id/@id for normal chat messages?
- mdosch admits to don't know (yet) what's the difference between those IDs.
-
MattJ
Just pretend origin-id doesn't exist, and join the campaign to have it removed from the XEP :)
-
Sam
⤴️
-
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> ```
-
Link Mauve
:|
-
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
-
flow
and <origin-id/> is simply the ID the entity where the stanza originated from assigned
-
mdosch
🤔
-
MattJ
and 'id' is what?
-
mdosch
Ok, I think I go for 'pretend it doesn't exist' until I have time to thoroughly look at this.
-
Zash
mod_if_id_eq_origin_id_then_remove_it
-
Kev
I also don’t see why origin ID can’t be a stanza ID stamped by the originator :)
-
flow
Kev, to avoid leaking the JID
-
flow
consider a semi-anonymous MUC for example
-
Kev
Or a stanza-id with no originator, then :) But yes, I’d forgotten about that.
-
flow
Kev, allowing <stanza-id/> without by attribute would complicate the rules for <stanza-id/> validation
-
Ge0rG
Can we just get rid of origin-id and pretend it never existed?
-
jonas’
et ceterum censeo origin-id delendam esse?
-
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.
-
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.”
-
larma
Which was only added later and may be in conflict with RFC✎ -
larma
Which was only added "recently" and may be in conflict with RFC ✏
-
Ge0rG
larma: what's the "current stream" in an s2s context?
-
larma
Hard to say. But in RFC terms, the originator of a broadcasted MUC message clearly is the MUC service
-
Ge0rG
larma: and it could "open" a new "stream" for each message
-
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
-
larma
But how does it match error messages then?
-
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
-
larma
Ge0rG, huh? I can just not reuse the id with a single recipient but reuse with another recipient
-
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✎ -
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 ✏
-
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
-
larma
yes, that's true
-
larma
except if you change your JID of course 😉
-
Ge0rG
Well, welcome random non persistent resource identifiers!
-
Zash
Something something (kind, id, to, from) unique, or somesuch.
-
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.
-
Zash
And errors have to/from flipped. Easy. What we talking about?
-
Ge0rG
So the RFC can't be followed in any sensible form and we should change it
-
Zash
larma, still applies to the full JID pairs, does it not?
-
larma
Ge0rG, why?
-
Ge0rG
larma: my point is that any implementation that will rely on id never repeating will have been broken a long time ago
-
Zash
on s2s?
-
larma
Ge0rG, ehm, don't we see issues with clients when any other client do it repeatedly?
-
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
-
Ge0rG
larma: only on receiving clients that think a "stream" is something eternal and persistent
-
larma
in practice we have XEPs that by design would break should ids be reused.
-
larma
we just workaround by making them use origin-id
-
Zash
If you do that, do you break anything but yourself (the client)✎ -
Zash
If you do that, do you break anything but yourself (the client)? ✏
-
larma
you typically break the recipient client 😉
-
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.
-
larma
it's not about evil clients, it's about standard compliant clients
-
Ge0rG
Except that pidgin won't send origin-id so it's exactly the status quo, but with one more useless xml element
-
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)
-
Ge0rG
Zash: what if MUC renumbers all the messages but the one sent to the original sending client?
-
Ge0rG
But also what if the client gets reconnected between sending the message and getting the reflection?
-
larma
Ge0rG, the original client wouldn't know the MUCs message id 😉
-
larma
Let's just agree that MUC is just a bunch of hacks and undefined behavior
-
Ge0rG
What if we stop relying on message id being unique except for purposes of reflection tracking?
-
larma
You mean as it's described in the RFC?
-
Ge0rG
Should a client be able to send a correction to a message that's still in flight?
-
Zash
Bring back "last" message correction
-
Zash
Or should we finally go ahead and mandate all IDs be HMAC(stream-id, stanza counter) ?
-
Ge0rG
Zash: have the server rewrite any client ID into this format!
-
Zash
Yes
-
Ge0rG
With eternal tracking, of course
-
Zash
Plus the client can know AOT what id messages will have
-
Zash
Didn't we invent this at every summit?
-
Ge0rG
Zash: yes, and I liked it every time
-
Ge0rG
Let's make it part of XMPP 2.0
-
Ge0rG
But then it won't prove that the ID is really unique to other servers.
-
Ge0rG
So we don't gain anything in the presence of malicious servers.
-
Zash
"Don't write malicious servers"
-
Ge0rG
Except that you could terminate s2s to a server that sends repeating IDs
-
Zash
Make every entity on the path attach their own ƒ(stream-id, counter)! Seal it with crypto, no, blockchain!
-
Ge0rG
Zash: but then we reuse the counter from 0198, only to realize that it'll wrap around at 2^31
-
Zash
`<reset xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>`, bye
-
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?
-
deuill
I seem to remember the original RFCs saying IDs SHOULD be globally unique, though I might be wrong.
-
Ge0rG
deuill: yes. Any modern client will send globally unique IDs anyway
-
Zash
Twice. And then the MUC adds another. And some timestamps on that.
-
deuill
Hm, what's to prevent clients from sending duplicates?
-
deuill
Oh right yeah.
-
Ge0rG
deuill: larma quoted the RFC one and a bit hours ago
-
deuill
Yeah I think Dino not doing MAM-MUC bit me there
-
deuill
Or is it MUC-MAM
-
Ge0rG
deuill: an evil client can do whatever it wants. A broken client will make other clients break some functionality
-
Ge0rG
MAM is always using the server generated IDs. Luckily, servers will never misbehave
-
Zash
True fact. Servers are perfect.
-
deuill
Praise be!
-
Zash
Trust in the server. The server is good.
-
deuill
What if we just did away with clients altogether and just had the servers talk to one another
-
mdosch
To protect and serve?
-
Zash
YES
-
Zash
As a bonus we then get a pure p2p system
-
Ge0rG
Zash: "server" is a discriminatory word, because serving is an implication of involuntary labor.
-
deuill
Having worked at a cafe in Greece, I can attest to that
-
Zash
Ge0rG: What, you don't tip your servers?
-
Ge0rG
Zash: xmp2p!
-
Ge0rG
Zash: no, I master them.
-
deuill
Please don't tip your servers, the hard drives will thank you
-
Ge0rG
Hard drives have been forbidden a long time ago, because of the IDE Master Slave jumped✎ -
Ge0rG
Hard drives have been forbidden a long time ago, because of the IDE Master Slave jumper ✏