Hi,

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?

Cheers,
Tobi

[1] http://logs.xmpp.org/xsf/2016-09-16/#10:58:21 
<http://logs.xmpp.org/xsf/2016-09-16/#10:58:21>
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to