[Standards] XEP-0313: pending 0.7 update review
mwild1 at gmail.com
Tue May 12 20:29:10 UTC 2020
On Mon, 11 May 2020 at 09:22, Michal Piotrowski <
michal.piotrowski at 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards