Hi Michal, On Mon, 11 May 2020 at 09:22, Michal Piotrowski < michal.piotrow...@erlang-solutions.com> wrote:
> Hi Matthew, > > Thanks for making the changes. I'm really in favour of them. I see there > was no update to the PRs nor here on the mailing list. What needs to happen > in order to proceed with these? > Thanks for the feedback! I think I've incorporated all the feedback so far (there is a minor question about the correct type for the new form fields, but I'm pretty set on what's currently in the PR). I had allocated a chunk of time to work through some XEPs, this one included. Unfortunately I reached the end of that allocated time so things have been on pause the past week or so. I'm hoping to resume later this week or early next, to get this published. > Alos, I have a comment (or rather question) regarding the new way of > querying the archive based on message UIDs. I assume that by UID, you mean > the origin-id as set by the client sending the message. If so, it didn't > find it clearly stated in your proposed changes nor in the current > version of MAM XEP. If not origin-id is meant here, I'd like to know what > UID means in this context. > As Philipp already highlighted, MAM uses server-assigned ids (referred to as "UIDs": https://xmpp.org/extensions/xep-0313.html#archives ). The id attribute of the stanza set by the client is preserved (this is clarified in the new update), but there is no way to search through it. Server-assigned UIDs allows the server to ensure uniqueness of the ids and maintain consistency of the archive. Client-provided IDs are optional, and are not guaranteed to be unique. A legacy/rogue/buggy client logged into the user's account could easily mess up an archive by sending multiple messages with the same ID. Also, the server can encode data into the ID which assists with some optimisations (such as sharding the archive data). You are completely right, there are two big problems with XMPP in general in this area, but solving them is not within the scope of XEP-0313 (which just provides the archive query mechanism): 1) When a client logs in, there is a race condition between enabling carbons and querying MAM, with the potential for the client to either receiving duplicate messages or miss some messages (if done incorrectly). My plan is to solve this with a new resource binding mechanism (potentially XEP-0386, but that spec is not finished and progress has stalled). 2) The client is not informed of UIDs assigned to its outgoing messages. This can cause message duplication if the client tries to sync using the last known incoming ID. We have discussed a bunch of solutions for this, but I think the simplest one is to simply echo something back to the client (either the full message, or just the assigned UID) after successfully archiving. This approach is simple, but obviously raises potential bandwidth considerations. In both cases the current potential for duplication can be worked around by a smart client, but it's extra work that I would like to remove from the burden already on client developers. Regards, Matthew
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
