[Standards] XEP-0308: Last Message Correction and Carbons

Tobias M tmarkmann at googlemail.com
Tue Sep 27 09:06:30 UTC 2016

> On 27 Sep 2016, at 00:33, Kevin Smith <kevin.smith at isode.com> wrote:
>> However, it has little discussion on why there is this restriction. While it certainly is a MUST for security reasons in MUC situations where different full JIDs are different accounts (i.e. associated to different bare JIDs), it is less so for security reasons in the non-MUC case.
> I think one can construct other situations like MUC, where multiple people control different resources of the same bare JID, but maybe that’s pathological (although I’m not sure).

If multiple people would use different resources of the same bare JID, this would also lead to strange UX regarding Carbons where the user will see messages as sent which they didn’t write. I think this is a rather rare edge case we shouldn’t put much efforts in to support.

>> I’ve shortly discussed it with other community members in the XSF chatroom [1], but thought I’d bring it up here for discussion with a wider audience, while providing a short summary of the room discussions below:
>> When would a client send an correction for a message from another account resource? Two cases come to mind:
>> a) Carbons, editing a message from another client when you switch clients mid-discussion.
> Certainly in this case we’d want to be able to correct them.
>> b) Reconnection, where a client has the server assign it a resource.
> Which is more or less the same instance as (a), I think.
>> What do you think? Do you have further comments on this issue?
> I think there’s also a concern that different resources may use the same IDs. Perhaps we should be moving away from using stanza IDs for this, and move towards something like 359 (although 359 has the client-id, stanza-id oddity which we should probably fix at some point and just use multiple stanza-id stamps with the relevant ‘by’ instead).

Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could provide a solution if we can’t rely on unique and stable stanza IDs. It’s not discussed in XEP-0359, but I guess it’s the reason for its existence, that stanza IDs may only be stable/unique regarding one XMPP stream and might change in a multi-hop routing like C-to-S -> S-to-S -> S-to-C or C-to-S -> MUC -> S-to-C.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160927/7acb2059/attachment.html>

More information about the Standards mailing list