[stripping out the arguments I don't disagree with, to further illuminate a specific point]
* Kevin Smith <kevin.sm...@isode.com> [2019-04-02 13:03]: > I don’t really think what you’re looking for here is a clarification > of the intent of the XEP, but a change of behaviour. I can agree with that, so in retrospect, the point of my -1 is also to ignite (enforce?) a discussion on whether such a change of behavior could be the better solution in the long term. > > (and you will drop the correction messages) > As further evidence that this isn’t a good idea, it’ll break anything else > using the id - e.g. message receipts. Thank you for bringing this up! The interaction of Receipts and Corrections is a challenge I've had on my mind as well. Can we agree that for the sending user, it is important to see that the latest corrected message arrived successfully, and that the status of earlier versions is unimporant? The sending client would then do two things when sending out a correction: a) clear the "acknowledged" flag on the corrected message b) add a receipt request to the LMC message: <m id=2><b>fixed</b><r id=1/><rr/></m> Now, if the sending client does not keep the incorrect versions of the message, all that remains in its storage is this: <m id=1><b>fixed</b></m> If we follow the "a correction replaces all child-elements" rationale, the receiving client now needs to treat the new message as an update of the original and to send a receipt for the _original_ message id: <m id=4711><received id=1/></m> Obviously, this doesn't make sense for the sending client as it can not distinguish this ack from a delayed ack for the original incorrect message. Obviously, the receiver could send a 'replace' on its initial ack: <m id=4712><received id=1/><r id=4711></m> That would indicate to the sender that *some* edit of the message was acknowledged, but the reference to the original ACK number is rather irrelevant because there is no use in keeping track of those, and the original ACK does not define which revision of the message it related to. If we bend the rationale into "a receipt request in a correction is not part of the correction but part of the meta-data of the correction message", then the receiver will actually send a receipt for the LMC id: <m id=4711><received id=2/></m> The original sender still can not associate this id with the corrected message without also keeping track of _at least_ the last correction ID that was applied to the original message. A similar problem (and the associated race condition) exists with other message reference schemes like Message Attaching and References. The entity that emitted the Reference can then send out a corrected Reference when processing a correction of the initial message. But again, which id should the Reference in the correction reference? I'm not sure how we should treat future Emoji Reactions. Should they remain attached to the corrected message (this is probably the most logical thing)? Luckily, MAM ids (which are technically also a child element) can probably be argued as something that definitively is not part of the correction, so that there is no way to confuse the archive. > > While message reordering doesn't exist in XMPP (at least in theory), > > [...] all corrections are equal and the latest one wins. > …which is fine, AFAICS. While a little bit tongue-in-cheek, my comment was intended to provoke further thought. One such situation(*) is when you perform two corrections of the same message from two different clients, with the corrections arriving at the recipient in arbitrary order. The 'wrong' approach spans a tree of message corrections leading to the original message as its root. A recipient will end up showing all leaf messages (because it won't be able to merge different sub-trees) as long as order is maintained over each sub-tree. With the 'right' approach, all corrections are leafs of the original, leaving the most delayed correction as the winner(**). (*) in direct-messaging siutaitons, this is violating the full-JID-MUST-match business rule in 0308, which I disagree with for practical reasons. In a MUC, all clients appear under the same full JID, but the MUC is acting as an order arbitrator. Even if the final order of the messages is not the intended one, the sender will see and be able to issue another correction eventually. (**) I know that this sounds like a very much constructed edge-case, but I've already been in the situation where I corrected a message multiple times from multiple devices. > With one of my other hats on, if we’re going to have a server archive > that understands corrections (and other references, as we discussed at > the Summit), which we’re going to need, it’s going to be much more > straightforward to have everything anchoring off a single message, > rather than needing to follow a chain. This is a very strong argument. I just wonder what quirks will be required on top to address the above issues with references and receipts. Georg
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
