On Fri, 16 Jul 2021 at 12:47, Sam Whited <s...@samwhited.com> wrote: > > Hi all, > > There has been a lot of discussion about bind2 as a potential way to fix > the Message Carbons race condition (quick summary: when the connection > starts you go to enable carbons with the IQ, but you've already received > a few messages that aren't carbon copied before the IQ gets sent).
This doesn't solve it, or rather, it only solves a part of it (that can already be solved without protocol changes). Today you would just bind, enable carbons, and request MAM. MAM will return you anything you missed between resource binding and carbons activation. The only downside of doing it this way is that you then have to de-duplicate stuff (because you _may_ have already received some things that are already in the archive). Documented here: https://docs.modernxmpp.org/client/protocol/#race-during-login The clean solution is for the server to atomically enable carbons from a known point in the MAM archive, and then tell the client what that point is, so it can use it in its initial MAM query (if it wants to). However, as discussed recently in one of the MUCs, this is hard for servers to do atomically in a clustered environment (but it's nevertheless the right place to do it). My feeling is that the suggested protocol changes (i.e. the stream feature) would still take as much time to be implemented and deployed as bind2, while bringing very little practical improvement in comparison. Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
