Re: [Standards] XEP-0308: LMC of a previous correction
On Tue, Apr 02, 2019 at 12:06:20PM +0200, Georg Lukas wrote: > While message reordering doesn't exist in XMPP (at least in theory), the > "blockchain" of corrections provides a cleanly ordered relation over all > corresponding corrections, whereas with the 'right' way, all corrections > are equal and the latest one wins. > > However, if you are receiving partial history from MAM or a MUC, it is > well possible that the original message was either lost (because it's > older than the retention interval), or is going to be loaded later as > part of a history scroll back. > > In this case, the 'right' way to interpret the first correction you > receive is "inject a new message placeholder into the history, with > unknown timestamp and no payload, then perform a correction on that". > With the 'wrong' way, the first correction just naturally becomes the > original message if it corrects an unknown @id. I think with MAM catchup, the current reading of the spec (i.e. non-chained) actually makes things easier. With the chained approach, if you get only part of the chain, you'll need to memorize somewhere that you're still waiting for an older message with a particular id (and then when doing another MAM query you need to check whether you got a message with that id). With the non-chained approach, you can simply make a placeholder message (like you suggested) and annotate corrections onto it (ordered by time received). No need to store not-yet-received ids anywhere. > I'm not sure which way is superior for handling an after-the-fact > appearance of the original message. I'd also like to hear opinions from > server archive developers. > > I did that. It would be great if you didn’t -1 the clarification :p > > It is well possible that my interpretation of the XEP ambiguity was > not quite correct. However, it is shared by other widely deployed(?) > implementations, and removing the ambiguity would be a breaking change > to all those (and yes, I'm obviously biased here because of my own one). As Kev already mentioned, there are other clients that implemented it according to the way the XEP was intended, including mine. What you're proposing would in any case require a namespace version bump right? Given that, I think it's fair to merge Kev's clarification of the intent of the current version regardless of whether the chained approach gets accepted or not. - JC ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0308: LMC of a previous correction
On Tue, Apr 02, 2019 at 02:15:24PM +0200, Georg Lukas wrote: > > > 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(**). Are you arguing against your own suggested "chained" approach here? Seems to me this is a problem that would only arise when using the chained approach because then two correcting messages referring to the same ancestor "id" require you to turn your linked list into a tree. When implementing the current version of the spec (made more explicit with Kev's clarification) this problem won't arise because the list of correcting messages is ordered based on reception date, not linked via their "id" attributes. - JC ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0308: LMC of a previous correction
[stripping out the arguments I don't disagree with, to further illuminate a specific point] * Kevin Smith [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: fixed Now, if the sending client does not keep the incorrect versions of the message, all that remains in its storage is this: fixed 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: 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: 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: 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://
Re: [Standards] XEP-0308: LMC of a previous correction
On 2 Apr 2019, at 11:06, Georg Lukas wrote: > thank you for picking this up again, and I'm sorry for the -1. I wrote > in the Meeting that it's not impossible to convince me to change my > mind, but you have to provide very strong arguments… 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. There are plenty of pointers in the XEP at the moment to the intention - saying not to change the nature of the stanza (which naturally includes its identity), correcting a single message multiple times (not correcting a chain of messages), only replacing the payloads, etc. - my PR clarified this, although I don’t pretend that my PR is perfect, or removes all other opportunities for clarity in 308. > * Kevin Smith [2019-04-02 10:52]: >> It’s the original message @id - if you follow the rules in the XEP >> then the other way around wouldn’t work. > > I'm not convinced that it really wouldn't work (and my lack of > conviction is backed by yaxim doing it the "wrong" way and not failing). Of course it could be made to work, but only by munging bits of the XEP as-is, particularly: > Essentially, the interpretation of the XEP boils down to the question > whether the @id can be considered as being part of the payload. Which is not the usual interpretation, which is that it’s the content data (see XEP-0060, for example, for this use of the term). I accept that what I should have written was not the colloquial ‘payload’ but its meaning ‘child elements’ - this would be a purely editorial change, so I can submit a PR for this straightforwardly. > If you > allow that interpretation for a moment, we can explore the other > alternative and compare them. Yes, if you ignore this bit of the intent, everything else can be bashed into working (although with issues, as below). >> If you do this the ‘right’ way [...]: >> >> fixed >> typo 2 >> fixed >> >> Where, again, 2 and 3 can be forgotten, or simply ignored. > > Regarding client-side storage, you can only delete the correction > messages if you do not intend to provide the full message editing > history to the user. If you plan to provide such history, it obviously > doesn't make sense to rewrite the original message (and thus remove its > content from the history). Instead, you probably need to copy the > original and intermediate corrections into a dedicated storage table, > where I can see that a stable reference identifier (id=1) over all > corrections makes some sense. > > The 'wrong' way would include also rewriting the @id of the stored > message with the @id of the last correction you received. The example > would thus become: > >> fixed >> typo 2 >> fixed > (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. > While message reordering doesn't exist in XMPP (at least in theory), the > "blockchain" of corrections provides a cleanly ordered relation over all > corresponding corrections, whereas with the 'right' way, all corrections > are equal and the latest one wins. …which is fine, AFAICS. > However, if you are receiving partial history from MAM or a MUC, it is > well possible that the original message was either lost (because it's > older than the retention interval), or is going to be loaded later as > part of a history scroll back. > > In this case, the 'right' way to interpret the first correction you > receive is "inject a new message placeholder into the history, with > unknown timestamp and no payload, then perform a correction on that". > With the 'wrong' way, the first correction just naturally becomes the > original message if it corrects an unknown @id. That would then mean you’d end up with out-of-order messages, because of the corrections, so I think in both cases you need to wait for the first message (or elide the corrections) to have a sensible stream. > I'm not sure which way is superior for handling an after-the-fact > appearance of the original message. I'd also like to hear opinions from > server archive developers. 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. >> I did that. It would be great if you didn’t -1 the clarification :p > > It is well possible that my interpretation of the XEP ambiguity was > not quite correct. However, it is shared by other widely deployed(?) > implementations, and removing the ambiguity would be a breaking change > to all those (and yes, I'm obviously biased here because of my own one). There are also implementations with the intended interpretation, FWIW. > > Together with the nice and clean "blockchain" ordering of the 'wrong' > interpretation,
Re: [Standards] XEP-0308: LMC of a previous correction
Hello Kev, thank you for picking this up again, and I'm sorry for the -1. I wrote in the Meeting that it's not impossible to convince me to change my mind, but you have to provide very strong arguments... * Kevin Smith [2019-04-02 10:52]: > It’s the original message @id - if you follow the rules in the XEP > then the other way around wouldn’t work. I'm not convinced that it really wouldn't work (and my lack of conviction is backed by yaxim doing it the "wrong" way and not failing). Essentially, the interpretation of the XEP boils down to the question whether the @id can be considered as being part of the payload. If you allow that interpretation for a moment, we can explore the other alternative and compare them. > If you do this the ‘right’ way [...]: > > fixed > typo 2 > fixed > > Where, again, 2 and 3 can be forgotten, or simply ignored. Regarding client-side storage, you can only delete the correction messages if you do not intend to provide the full message editing history to the user. If you plan to provide such history, it obviously doesn't make sense to rewrite the original message (and thus remove its content from the history). Instead, you probably need to copy the original and intermediate corrections into a dedicated storage table, where I can see that a stable reference identifier (id=1) over all corrections makes some sense. The 'wrong' way would include also rewriting the @id of the stored message with the @id of the last correction you received. The example would thus become: > fixed > typo 2 > fixed (and you will drop the correction messages) While message reordering doesn't exist in XMPP (at least in theory), the "blockchain" of corrections provides a cleanly ordered relation over all corresponding corrections, whereas with the 'right' way, all corrections are equal and the latest one wins. However, if you are receiving partial history from MAM or a MUC, it is well possible that the original message was either lost (because it's older than the retention interval), or is going to be loaded later as part of a history scroll back. In this case, the 'right' way to interpret the first correction you receive is "inject a new message placeholder into the history, with unknown timestamp and no payload, then perform a correction on that". With the 'wrong' way, the first correction just naturally becomes the original message if it corrects an unknown @id. I'm not sure which way is superior for handling an after-the-fact appearance of the original message. I'd also like to hear opinions from server archive developers. > I did that. It would be great if you didn’t -1 the clarification :p It is well possible that my interpretation of the XEP ambiguity was not quite correct. However, it is shared by other widely deployed(?) implementations, and removing the ambiguity would be a breaking change to all those (and yes, I'm obviously biased here because of my own one). Together with the nice and clean "blockchain" ordering of the 'wrong' interpretation, however, I remain unconvinced that your PR is the right direction of removing the ambiguity and want to hear more voices (and/or better arguments). Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0308: LMC of a previous correction
Sorry that this got buried in my mailbox and I didn’t notice it. On 17 Nov 2018, at 16:32, Georg Lukas wrote: > when correcting a previously corrected message, do you reference the > original message @id or the message @id of the last correction to that > message? It’s the original message @id - if you follow the rules in the XEP then the other way around wouldn’t work. This is meant to be covered by "A single message may be corrected multiple times by subsequent edits.” - i.e. you are correcting the original message multiple times, not correcting multiple messages once each, but I can see that’s causing confusion. The main reason that it won’t work if you try to correct the id of the correction, but otherwise follow the XEP as-written, is that you lose the context of what you’re correcting. If you do this the ‘right’ way, you have the following flow (hopefully the shorthand is clear): The original message: typo 1 The first correction: typo 2 So now you take the second message, with the replace body, apply the "The receiving client then treats the newly received payloads as completely replacing all payloads of the original message” rule, and you logically have a history that reads like: typo 2 typo 2 Where message2 could now be binned, because it’s done its job, but is otherwise ignored. Now for the second correction: fixed And now you similarly have an updated logical history of: fixed typo 2 fixed Where, again, 2 and 3 can be forgotten, or simply ignored. Everything is happy. If you try it the other way, however, you lose the context of the original message because of the ‘replace all payloads’ rule. The original message: typo 1 The first correction: typo 2 New logical history: typo 2 typo 2 Second correction: fixed So, under this scheme, now we’re going to replace all the payloads of message 2 with the corrected payloads from message 3, so we have a new logical history state of: typo 2 fixed fixed which is certainly not what we want. > > It would be great to clarify in the XEP business rules. I did that. It would be great if you didn’t -1 the clarification :p If there’s a better way for me to express the clarification, please do shout, but I do think that PR or something similar needs to be merged so we can avoid this confusion. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0308: LMC of a previous correction
Or i dont see why this should make a difference? The last message gives you in both cases the current content, and you need in both cases all other messages to display the correction history Am Sa., 17. Nov. 2018 um 18:46 Uhr schrieb Ненахов Андрей < andrew.nenak...@redsolution.ru>: > I tend to think that title of this XEP is misleading and that any message > should be possible to correct. > > Also, I'd rather use the original message ID, because the replaced message > should be stored on original message place in history (with a timestamp of > original message, though possibly amended with correction time). Using id > of last correction would require to fetch all subsequent messages from > archive to get to the original one and it's place in history. This is bad, > especially for clients that could have been offline for some time and would > have to do excessive work digging up message archive. > > On Sat, 17 Nov 2018, 21:35 Georg Lukas >> Hi, >> >> when correcting a previously corrected message, do you reference the >> original message @id or the message @id of the last correction to that >> message? >> >> The XEP proclaims: >> >> | A single message may be corrected multiple times by subsequent edits. >> >> which kind of leaves this question open, and from a quick survey, at >> least poezio, Conversations and yaxim will reference the last >> correction's message @id and not the original one. >> >> It would be great to clarify in the XEP business rules. >> >> >> Georg >> -- >> || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ >> || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || >> || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || >> ++ IRCnet OFTC OPN ||_|| >> ___ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: standards-unsubscr...@xmpp.org >> ___ >> > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0308: LMC of a previous correction
Gajim corrects always the last message that was sent over the wire. regards Philipp ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0308: LMC of a previous correction
I tend to think that title of this XEP is misleading and that any message should be possible to correct. Also, I'd rather use the original message ID, because the replaced message should be stored on original message place in history (with a timestamp of original message, though possibly amended with correction time). Using id of last correction would require to fetch all subsequent messages from archive to get to the original one and it's place in history. This is bad, especially for clients that could have been offline for some time and would have to do excessive work digging up message archive. On Sat, 17 Nov 2018, 21:35 Georg Lukas Hi, > > when correcting a previously corrected message, do you reference the > original message @id or the message @id of the last correction to that > message? > > The XEP proclaims: > > | A single message may be corrected multiple times by subsequent edits. > > which kind of leaves this question open, and from a quick survey, at > least poezio, Conversations and yaxim will reference the last > correction's message @id and not the original one. > > It would be great to clarify in the XEP business rules. > > > Georg > -- > || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ > || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || > || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || > ++ IRCnet OFTC OPN ||_|| > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0308: LMC of a previous correction
* Jonas Schäfer [2018-11-17 17:39]: > I tend slightly towards posting subsequent corrections against the original > @id. This is because in my mind, the correction replaces the payload, not the > message itself. However, if all current implementations refer to the ID of > the > previous correction, we should probably put *that* in the business rules and > also call it a blockchain and tell that to our Marketing department. There is another reason to reference the last correction and not the original message: if you are only fetching the last N messages of history, and the original is outside of that - you still can correct the tail of the list based on the previous-correction id. Example: -- your history sync starts here -- Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0308: LMC of a previous correction
On Samstag, 17. November 2018 17:32:26 CET Georg Lukas wrote: > Hi, > > when correcting a previously corrected message, do you reference the > original message @id or the message @id of the last correction to that > message? > > The XEP proclaims: > | A single message may be corrected multiple times by subsequent edits. > > which kind of leaves this question open, and from a quick survey, at > least poezio, Conversations and yaxim will reference the last > correction's message @id and not the original one. > > It would be great to clarify in the XEP business rules. I tend slightly towards posting subsequent corrections against the original @id. This is because in my mind, the correction replaces the payload, not the message itself. However, if all current implementations refer to the ID of the previous correction, we should probably put *that* in the business rules and also call it a blockchain and tell that to our Marketing department. kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
