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

Tobias M tmarkmann at googlemail.com
Fri Sep 16 11:39:03 UTC 2016


Under 4. Business Rules XEP-0308 mentions:

> A correction MUST only be allowed when both the original message and correction are received from the same full-JID.

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’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.
b) Reconnection, where a client has the server assign it a resource.

What would speak for allowing edits across resources:

From a UX perspective, clients show messages the same, no matter if your current resource has send it or another resource and you’ve received a carbons for it. At least this is the case for Conversations and Swift from my experience. I think it would not be obvious to a user why they can edit only some of their sent messages.
Allowing edits across resource changes and carbons would provide a more consistent UX.

What speaks against it:

Cross resource edits may rarely be needed as you usually notice your errors right away and fix them directly afterwards.
Another case is where a server sends different carbons messages to different resources. Some think allowing cross-resource corrections will open a can of worms.

What do you think? Do you have further comments on this issue?


[1] http://logs.xmpp.org/xsf/2016-09-16/#10:58:21 <http://logs.xmpp.org/xsf/2016-09-16/#10:58:21>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160916/61a2a380/attachment.html>

More information about the Standards mailing list