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 ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
