Let's assume, for a moment, that we do not wish to attempt to solve deliberate duplication of ids, and instead assume that any duplication is a bug.
Let's further assume that "if only" the @id attribute of a stanza were both always present, and globally unique, it'd work. What if: a) Clients can make some assertion that they will generate a globally-unique @id on stanzas. b) Servers can also advertise assertions that they, too, deal with globally unique stanzas identifiers. If a connected client fails to make the assertion, the server either: i) Injects a stanza-id of its own, or: ii) Changing the @id and encodes the original @id within it, somehow. (They could use any scheme for that, and might want to consider something that's difficult or impossible to emulate). c) MUC services (and similar broadcasters) advertise a "stable identifier" thing. Since @id's are now globally unique, they can be passed through - but a MUC service faced with a server that isn't asserting the Thing can choose to override the @id. d) If a server is doing the id thing, and a client asserts same, and fails to include an @id on any stanza, that stanza is bounced. Is that enough? And if not, can it be refined to the point it works? On Tue, 29 Jan 2019 at 15:31, Georg Lukas <[email protected]> wrote: > Hi together, > > I've added a "Message IDs and References" agendum to the Summit > discussion agenda. As I probably won't be able to attend, I wanted to > elaborate what exactly the problems I'd like to see solved are, and > maybe even ignite a bit of on-list discussion pre-Summit. > > We currently have three ways to identify a message: > > - the semi-optional semi-unique stanza @id > <https://xmpp.org/rfcs/rfc6120.html#stanzas-attributes-id> > > - the <origin-id/> introduced as a work-around for @id being rewritten > by MUCs and not being unique in a guaranteed, observable from the > outside, way <https://xmpp.org/extensions/xep-0359.html#origin-id> > > - the <stanza-id/> injected by MAM and MUC (I count the MIX generated > @id into this category as well) > <https://xmpp.org/extensions/xep-0359.html#stanza-id> > > Furthermore, we have different use cases for referencing a message: > > - own message reflection matching in a MUC (scoped by your participant > JID, might be needed over reconnects under bad timing) > > - XEP-0184 Receipts (scoped by the sender JID, except for MUCs where it > is NOT RECOMMENDED but might still be requested and sent, persistent > over connections) > > - XEP-0333 Markers (no explicit scoping defined, but probably implicitly > scoped by the bare JID, so a MUC participant can send markable > messages with duplicate @id to confuse other participants) > > - XEP-0372 References ("TODO: URI scheme for messages", probably > requires scoping by bare JID or participant JID and sufficient > persistence) > > - Emoji Reactions (same requirements as 0372) > <https://github.com/jabbercat/jabbercat/issues/80> > > - XEP-0367 Message Attaching (scoped by MUC/bare JID, with persistence, > has the most sophisticated @id usage rules) > <https://xmpp.org/extensions/xep-0367.html#business-id> > > - Threading (this has largely unsolved UX and is widely ignored) > > Out of these, XEP-0367 has the most robust and most advanced rules, and > those are probably the best foundation for a universal reference-id > specification that could be put into all of the other XEPs mentioned > above. > > However, there are multiple issues I see with those rules: > > - they are rather complex > > - they require 0359+MAM support in a MUC (and 0359 in the client) > > - they don't cover MIX yet (but the change should be trivial) > > - you can not reference a message that wasn't yet reflected(*) > > (*) I see this as problematic in offline/high-latency situations: if you > want to send a message and a reference to it back-to-back, you need to > delay the second one until the first one was reflected. If you want to > prepare a message and a reference-message while offline (writing a > message for later delivery is a useful feature in a mobile client), you > need to keep a local reference (based on @id presumably), then to not > send the second message until the first one is reflected, and then to > rewrite the reference to the server-mandated one. > > The last one is a nasty, but not unsolvable problem. Maybe somebody can > come up with a more elegant solution that is not prone to the problem of > attacker-sends-id-duplicates, in which case I'd like to make this set of > rules into the official way to reference messages (maybe it should be > put into an Informational XEP and referenced from all the others?) > > > > Georg > -- > || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ > || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || > || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || > ++ IRCnet OFTC OPN ||_________________________________________________|| > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
