[Standards] XEP-0045 message ids

Dave Cridland dave at cridland.net
Fri Nov 12 11:29:16 UTC 2010

On Wed Nov 10 19:17:48 2010, Justin Karneges wrote:
> On Wednesday 10 November 2010 04:30:20 Dave Cridland wrote:
> > If a client sends a chatroom a message, and that message has an  
> id,
> > should outbound messages from the chatroom to the occupants use  
> the
> > same id?
> >
> > Doing so has obvious implications on id uniqueness, but apparently
> > most implementations preserve the id, and the result is that at  
> least
> > one client implementation is relying on this behaviour.
> >
> > Personally, I consider the two stanzas - occupant to MUC, and MUC  
> to
> > occupants - to be distinct, just having the same (or similar, at
> > least) payloads - and therefore have different ids (indeed,  
> different
> > per occupant). Everyone else seems to consider this a silly idea.
> >
> > I'll go along with whatever people think - but it's something  
> else to
> > add to XEP-0045, whichever way people decide.
> The other day in jdev we were discussing using message ids to  
> assist in
> creating a hierarchical tree of messages within a MUC room.  This  
> would mean
> the MUC enforcing uniqueness of ids sent out to participants (so  
> that every
> past message is uniquely identifiable), and then participants could  
> choose a
> "parent" message id when sending new messages to the MUC room.  So  
> this is at
> least one use-case that would demand the MUC being able to rewrite  
> the id.

That's different *again*.

So there's at least there cases to ponder:

1) The id on the broadcast messages should be the same as the id on  
the stanza sent to the MUC.

This appears to be what Prosody, Openfire, and Jabber XCP do. (Not  
that I've tested personally). 
2) The id on the broadcast messages is generated each time by the  
MUC, hence all ids are different.

3) The id on the broadcast messages is the same for each broadcast,  
but different to the id on the stanza sent to the MUC.

I think you're describing (3). I think that's sufficient for error  
handling, but our contact wants (1), which breaks that too.

Personally, I think that in your case you want either a <thread/>, or  
a more message-id-like element. (I think our id attributes map closer  
to transaction identifiers than message identifiers).

Either has a more controlled lifetime, and is thus considerably more  
reliable for most cases, as compared to an id which might be reused  
on reconnect (or by a different client).

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list