Re: [Standards] XEP-0424: Message Retraction - Remove Fastening
I think we came up with the common understanding that to reference a previous message in a conversation, we use - the origin-id or message id in direct chats - the MUC service's stanza-id in MUCs + some kind of method (e.g. presence tracking, occupant-id) to have certainty that the sender is the same if necessary (would be required for retraction) (These rules are currently duplicated in XEPs 0367, 0444, 0461 and probably others) The only exception right now is last message correction, which always uses the message id (even in MUCs), but in that case it's fine, because LMC always refers the last message and the id does not really serve the purpose of referencing a message. If we just properly spec those rules for referencing messages (in an informational XEP) and just always refer to those rules, I think your suggested by-attribute is mostly superfluous. In a MUC, any by- attribute-value that is not the MUC would be spoofable, so it couldn't be used for referencing. That suggested by-attribute can even cause more confusion because one might want to mention the sender of the message (XEP-0461 does that in a 'to'-attribute) Marvin On Mon, 2023-02-20 at 10:32 +0100, Florian Schmaus wrote: > On 13/02/2023 16.57, Daniel Gultsch wrote: > > I’m currently looking at implementing 'Message Retraction' and I > > think > > it should get rid of Fastening. > > > > I mentioned it during Summit and while it wasn’t discussed much > > further my comment also didn’t get much protest: I think Fastening > > is > > dead. > > > > A general purpose approach doesn’t seem to work for MAM. > > > > Luckily I think removing it from Retraction is fairly simple. > > > > We can just stick the ID into the retract element and send > > something > > > > > > Since origin-id is spoofable, one should not use it when referencing > other stanzas. Instead always use the 'id' *and* 'by' value of > xep359's > element. > > So the example above should become something like > > > > > > While one could argue that the 'by' attribute could potentially be > omitted and made implicit, e.g., it has the value of the MUC service > that hosts the MUC in which a message got retracted, I believe this > could lead far too easily to insecure implementations that only > compare > the id value, making the technically unspoofable xep359 stanza-id > spoofable again [1]. Therefore I would strongly consider making it > mandatory and explicit. > > - Flow > > > 1: Similar to the insecure carbons implementations we saw in the > wild. > ___ > 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-0424: Message Retraction - Remove Fastening
On 20/02/2023 11.05, JC Brand wrote: On 20.02.23 10:32, Florian Schmaus wrote: On 13/02/2023 16.57, Daniel Gultsch wrote: I’m currently looking at implementing 'Message Retraction' and I think it should get rid of Fastening. I mentioned it during Summit and while it wasn’t discussed much further my comment also didn’t get much protest: I think Fastening is dead. A general purpose approach doesn’t seem to work for MAM. Luckily I think removing it from Retraction is fairly simple. We can just stick the ID into the retract element and send something Since origin-id is spoofable, one should not use it when referencing other stanzas. Instead always use the 'id' *and* 'by' value of xep359's element. So the example above should become something like While one could argue that the 'by' attribute could potentially be omitted and made implicit, e.g., it has the value of the MUC service that hosts the MUC in which a message got retracted, I believe this could lead far too easily to insecure implementations that only compare the id value, making the technically unspoofable xep359 stanza-id spoofable again [1]. Therefore I would strongly consider making it mandatory and explicit. Fair enough. I searched in the XEPs repo to see if some other XEP uses and no-one does, even though there are other XEPs that do similar things, like XEP-0444 reactions That is probably because I just made that example up. But I am a long time advocate that referencing other stanzas must always use the 'id' *and* 'by' tuple. That recent discussion motivated me to prepare https://github.com/xsf/xeps/pull/1272 - Flow ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0424: Message Retraction - Remove Fastening
On 20.02.23 10:32, Florian Schmaus wrote: On 13/02/2023 16.57, Daniel Gultsch wrote: I’m currently looking at implementing 'Message Retraction' and I think it should get rid of Fastening. I mentioned it during Summit and while it wasn’t discussed much further my comment also didn’t get much protest: I think Fastening is dead. A general purpose approach doesn’t seem to work for MAM. Luckily I think removing it from Retraction is fairly simple. We can just stick the ID into the retract element and send something Since origin-id is spoofable, one should not use it when referencing other stanzas. Instead always use the 'id' *and* 'by' value of xep359's element. So the example above should become something like While one could argue that the 'by' attribute could potentially be omitted and made implicit, e.g., it has the value of the MUC service that hosts the MUC in which a message got retracted, I believe this could lead far too easily to insecure implementations that only compare the id value, making the technically unspoofable xep359 stanza-id spoofable again [1]. Therefore I would strongly consider making it mandatory and explicit. Fair enough. I searched in the XEPs repo to see if some other XEP uses and no-one does, even though there are other XEPs that do similar things, like XEP-0444 reactions. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0424: Message Retraction - Remove Fastening
On 13/02/2023 16.57, Daniel Gultsch wrote: I’m currently looking at implementing 'Message Retraction' and I think it should get rid of Fastening. I mentioned it during Summit and while it wasn’t discussed much further my comment also didn’t get much protest: I think Fastening is dead. A general purpose approach doesn’t seem to work for MAM. Luckily I think removing it from Retraction is fairly simple. We can just stick the ID into the retract element and send something Since origin-id is spoofable, one should not use it when referencing other stanzas. Instead always use the 'id' *and* 'by' value of xep359's element. So the example above should become something like While one could argue that the 'by' attribute could potentially be omitted and made implicit, e.g., it has the value of the MUC service that hosts the MUC in which a message got retracted, I believe this could lead far too easily to insecure implementations that only compare the id value, making the technically unspoofable xep359 stanza-id spoofable again [1]. Therefore I would strongly consider making it mandatory and explicit. - Flow 1: Similar to the insecure carbons implementations we saw in the wild. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0424: Message Retraction - Remove Fastening
Hi Daniel Thanks for bringing this up again. This was also the feedback when the XEP was reviewed by council about 2 (!) years ago. As one of the XEP authors, I've gone ahead and made a PR with the change. https://github.com/xsf/xeps/pull/1270 The next XEP, 0425 'Message Moderation' is related and similar and also relies on fastenings. I'll look into remove them there as well. Regards JC On 13.02.23 16:57, Daniel Gultsch wrote: Hi, I’m currently looking at implementing 'Message Retraction' and I think it should get rid of Fastening. I mentioned it during Summit and while it wasn’t discussed much further my comment also didn’t get much protest: I think Fastening is dead. A general purpose approach doesn’t seem to work for MAM. Luckily I think removing it from Retraction is fairly simple. We can just stick the ID into the retract element and send something All the business rules and much of the wording can remain intact for now. (I think long term we might want to adopt the ID rules from Replies; but that can be a different discussion) If people are happy with that suggestion (to get rid of Fastening) I think I can very easily make a PR. cheers Daniel ___ 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-0424: Message Retraction - Remove Fastening
Hi Daniel, If fastening is dead indeed, but retraction is not, I think it's reasonable to remove references to fastening in retraction. Looks good to me. -- Nicolas ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0424: Message Retraction - Remove Fastening
Hi, I’m currently looking at implementing 'Message Retraction' and I think it should get rid of Fastening. I mentioned it during Summit and while it wasn’t discussed much further my comment also didn’t get much protest: I think Fastening is dead. A general purpose approach doesn’t seem to work for MAM. Luckily I think removing it from Retraction is fairly simple. We can just stick the ID into the retract element and send something All the business rules and much of the wording can remain intact for now. (I think long term we might want to adopt the ID rules from Replies; but that can be a different discussion) If people are happy with that suggestion (to get rid of Fastening) I think I can very easily make a PR. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
