[Standards] Proposed XMPP Extension: Unique and stable message IDs

Daniel Gultsch daniel at gultsch.de
Mon Jun 8 06:49:42 UTC 2015

On an abstract level I feel like using the by attribute for the
Message-ID-XEP will make the XEP more general purpose. Even though we might
not necessarily see a benefit for multiple instances adding their own IDs
now we might have a use case for them in the future.

As for letting the client choose the MAM id vs agreeing on some kind of
schema I'm all for the schema since it does not require for elaborate
business rules on how to handle duplicate ids an unknowing or malicious
clients might inject.
Matthew is right in arguing that a remote entity might not know our stream
id however those messages (let's face it we are talking about MUC here)
will get reflected back to us anyway and thus allowing the remote entity to
add their own message id.

MUC is also a great example where the by attribute might come in handy. It
allows for both the MUC component and the users server to both add their
own message-id without requiring complicated business rules such as 'if its
a normal message strip all message ids and add your own but don't do this
when its a group chat message'. It also allows for MAM implementations to
optionally save group messages on behalf of the server (current XEP says


P.S.: I don't have a strong opinion on the MAM id generation schema (And
this doesn't belong to the message-id-discussion but should be in a
separate MAM discussion since it has nothing to do with the actual
message-id XEP besides the fact that it will be using this XEP when
broadcasting messages via the MR2-XEP) but using something like
SHA256(streamId+stanzaId) will have the benefit of not requiring and extra
id and would also make all ids in the archive of the same length which
might make it easier when looking at the database or an xml stream in a
debugging context.

2015-06-07 23:14 GMT+02:00 Matthew Wild <mwild1 at gmail.com>:

> On 7 June 2015 at 21:39, Florian Schmaus <flo at geekplace.eu> wrote:
> > On 07.06.2015 20:42, Georg Lukas wrote:
> >> 3) Create a MID generation scheme that can be independently followed by
> >> client and server, i.e. full-jid + stream-id + packet-id.
> >
> > I'd don't think we'll need the full-jid. The properties of the stream-id
> > are sufficient to generate a unique, collision free MID by concatenating
> > it with the stanza-id.
> >
> > We may not be able to use the stream-id though, because of the RFC
> > requirement that it has to be kept secret. Thus requiring us to
> > introduce a new public-stream-id which has the same properties as the
> > stream-id, but without the 'secret' requirement.
> >
> >> This scheme is
> >> very similar to #2, but the client has less options to game it, and I
> >> don't see significant benefits over #2.
> >
> > "Less options to game it" is not a significant benefit? Also not
> > requiring UUIDs as stanza-id is also a big plus: A dump client can still
> > generate stanza-ids using a simple counter and still participate.
> >
> >
> >> I think these options need to be weighted and one of them chosen before
> >> we can proceed with the MID XEP.
> >
> > I'm all for 3. It solves the "how can a client know the MAM archive ID
> > in advance" problem in an elegant and efficient way.
> I like it too, and I hope Dave can throw together the proposal he's
> been promising for it :)
> I feel it still has some shortcomings though:
>   - It only works for server-local archives (as remote entities won't
> know your stream id)
>   - It removes the ability for the server to use its own ids for
> messages, which may be more efficient
>   - If it's based on stanza ids, we have to verify uniqueness somehow
> (and gracefully fail on non-uniqueness)
>   - If it's based on counters then uniqueness is not a problem, but
> XEP-0198 implementation experience has demonstrated that simple
> counters apparently aren't so simple after all
>   - It removes the need for reflection of all sent messages, but there
> is potentially benefit in that practice (people generally like it in
> MUC)
> Regards,
> Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150608/97c6384a/attachment.html>

More information about the Standards mailing list