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

Matthew Wild mwild1 at gmail.com
Sun Jun 7 21:14:07 UTC 2015


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



More information about the Standards mailing list