Hi, Holger. This is actually a subject we know very much about. From our experience, the absence of mandatory stable message IDs is the biggest design flaw of XMPP as a protocol (resource priorities take the second place), and fixing this was the first thing we did when we started implementing our improvements to the protocol.
The basic set of postulates: - only server IDs matter - only server timestamp matters - every message must have unique ID assigned by the server (both incoming or outgoing) before delivery to clients or archiving in message archive - when sending an outgoing message, the client must consider it undelivered until it receives an assigned server ID - message with server ID acts as a delivery receipt - other clients get a carbon copy with added server ID - server ID may or may not be propagated to other servers, in our implementation we do propagate it In detail, our protocol extension is documented here: https://xabber.com/protocol/delivery This is one of the few XEPs we HAD time to put down in more or less formal English. It is internally known as 'Reliable Message Delivery', because we started this extension with a practical goal of ensuring a reliable message delivery, and unique ID assigned by server turned out to be a byproduct of achieving this goal. We implemented it over 2 years ago in our Xabber Server and in our Web / iOS clients, and we use it to great success. Most advanced features that we did would be totally impossible without it. вс, 27 сент. 2020 г. в 20:46, Holger Weiß <[email protected]>: > When opening a new session, MAM clients might want to use the > most-recent known XEP-0359 stanza ID to sync messages. One problem they > face is that there's no way to figure out the stanza ID of outgoing > messages, short of actually querying them back from MAM. Therefore, a > common workaround is to use the stanza ID of the most-recent _incoming_ > message and then de-dup any outgoing messages returned from MAM. > > I think it would be good to find a better solution. The issue has been > discussed before, and I've seen at least the following suggestions: > > 1. Let XEP-0198 include the stanza ID with the stream management ACK. > > I like the idea of acknowledging the stanza and returning its ID in > one go, but one concern I heard is that this might not play well with > existing APIs: libraries may handle stream management transparently, > while dealing with MAM sync is left to the application layer. > > 2. Let XEP-0280 carbon-copy messages back to the sender. > > Presumably the solution that requires the least-intrusive changes, > both spec- and implementation-wise. The downside I see is that the > entire (XEP-0280-wrapped) message stanza is reflected just to return > the stanza ID. > > 3. Let clients subscribe to XEP-0313 archiving, as suggested here, for > example: https://geekplace.eu/xeps/xep-mamsub/xep-mamsub.html > > Would involve more changes, but might remove the need for XEP-0280 > altogether, which could be a nice goal in itself. However, it has > the same downside as solution (2). > > I'd prefer a solution that doesn't involve reflecting the entire stanza > just to make the client aware of the stanza ID. So if (1) is not an > option, I think I'd opt for extending XEP-0359 or XEP-0313 (or, if > people prefer, adding a new XEP) to return an ACK for outgoing 1:1 > messages. E.g., something like this: > > | <message> > | <ack xmlns='urn:xmpp:sid:0' id='42' stanza_id='1234'/> > | </message> > > Thoughts? > > Holger > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com>
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
