I think there is two problems that are somehow merged within this: 1. Knowing the last outgoing message's server stanza-id for the purpose of fetching only newer messages with MAM.
2. Knowing all outgoing message's server stanza-id, for undefined purpose. While any solution to 2 also solves 1, it may as well be total overkill if only 1 is to solve. A possible solution to 1 could be that when trying to do session resumption on a timeouted session, the server includes the server stanza-id of the last received message from that session. The overhead of this is very minimal and, if session resumption is possible, it's no overhead at all. Another solution would be to allow fetching the last outgoing message from MAM at any point - which would include the server stanza id. Clients can apply some intelligent logic here, like only fetching it when there have been n outgoing messages in a row without an incoming message in between, thus having less overhead. This could be done by allowing MAM queries to not only filter *with* but also *from* and *to* - so I can just fetch the last message from my own full jid. I personally would like to not see any solution of servers replying to every message beyond stream management. And IMO stream management is definitely a different protocol layer and thus shouldn't be used to transport server stanza-id used for MAM. I personally would like to consider to make the server pick a server stanza id that the client can know *without* asking the server or getting it returned. However this may still require deduplication as the server and client message timeline might be not the same due to transfer delays. Related: I'd like to propose a feature that announces that a) origin-id, if present, matches the message id field of the original message b) message id of the original message (and thereby origin-id if present) is a random UUID v4 - If this feature is announced and the sending user's server sees a message id from that client that is known to have been used before, the message should cause an error. - If this feature is announced and any server sees an origin-id from that client that is known to have been used before, the message should cause an error. Motivation of this feature is mostly to get client to do things the right way. Announcing this feature could also become a dependency for things like message correction where we want to have a proper way to reference a message. But: The very same feature announcement could be used by sending user's server to use the message id as the server stanza id for MAM purposes. And for MUC servers to use the origin-id as the server stanza id for MAM purposes. Marvin On 27.09.20 17:45, Holger Weiß wrote: > 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: standards-unsubscr...@xmpp.org > _______________________________________________ > _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
