Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relegate message retraction to xep-0424 instead of using custom one. #1047

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Relegate message retraction to xep-0424 instead of using custom one. #1047

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
f9ba694
Relegate message retraction to xep-0424 instead of using custom one.
woj-tek Mar 25, 2021
63c963b
Clarify retraction and 424 usage: stanza-id in retraction payload, to…
woj-tek May 14, 2021
420cdbe
Remove old text and fix the build.
woj-tek May 14, 2021
3f679af
Improve message retraction in MIX example
woj-tek Dec 3, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 32 additions & 11 deletions xep-0407.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,8 +28,11 @@
<spec>XEP-0292</spec>
<spec>XEP-0297</spec>
<spec>XEP-0313</spec>
<spec>XEP-0359</spec>
<spec>XEP-0369</spec>
<spec>XEP-0372</spec>
<spec>XEP-0424</spec>
<spec>XEP-0359</spec>
</dependencies>
<supersedes/>
<supersededby/>
Expand Down Expand Up @@ -172,20 +175,38 @@

<section1 topic="Retracting a Message" anchor="usecase-retract">
<p>
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. A MIX channel MAY limit the time frame in which a message is allowed to be retracted, for example to prevent retraction of very old messages. When a messages is retracted the original message MAY be replaced by a tombstone. Message retraction is done by sending a special message that identifies the original message. This mechanism allows the retraction to be distributed on the same path as the original message so that all participating servers and clients MAY honour the retraction. The protocol to request retraction does this by adding to a message a &lt;retract&gt; element qualified by the 'urn:xmpp:mix:misc:0' namespace. A retract messages MUST NOT have a body. The &lt;retract&gt; element MUST include an 'id' attribute that holds the MAM-ID of the original message. The message sender will need to look up the MAM-ID. The MAM-ID is the convenient message identification for message recipients. A message and its retraction shown in the following example.
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. A MIX channel MAY limit the time frame in which a message is allowed to be retracted, for example to prevent retraction of very old messages. When a messages is retracted the original message MAY be replaced by a tombstone. Message retraction is done by sending a special message that identifies the original message. This mechanism allows the retraction to be distributed on the same path as the original message so that all participating servers and clients MAY honour the retraction.

The protocol to request retraction is defined in &xep0424;. If a server is aware of message retractions it MUST advertise it's support by advertising 'urn:xmpp:message-retract:0' feature. The retract message MUST be addressed to the mix channel and the &lt;apply-to&gt; element (as defined in &xep0422;) MUST include an 'id' attribute that holds the stable-id (as defined in &xep0359;) of the original message send by the channel itself. A message and its retraction shown in the following example.
</p>
<example caption="User Retracts a Message"><![CDATA[

<example caption="User Sends a Message to channel"><![CDATA[
<message from='[email protected]/UUID-a1j/7533'
to='[email protected]'
id='abcde'>
id='abcde'
type='groupchat'>
<body> A Message I did not mean to send </body>
</message>

]]></example>
<example caption="MIX channel reflects message to Participants with generated stanza-id"><![CDATA[
<message from='[email protected]/123456'
to='[email protected]'
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
type='groupchat'>
<body> A Message I did not mean to send </body>
<stanza-id by='[email protected]' id='a568706e-867b-49f1-a31b-e428ba9cece1' xmlns='urn:xmpp:sid:0'/>
<mix xmlns='urn:xmpp:mix:core:1'>
<nick>thirdwitch</nick>
<jid>[email protected]</jid>
</mix>
</message>
]]></example>
<example caption="User Retracts a Message"><![CDATA[
<message from='[email protected]/UUID-a1j/7533'
to='[email protected]'
id='92vax143g'>
<retract id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' xmlns='urn:xmpp:mix:misc:0'/>
<apply-to id="a568706e-867b-49f1-a31b-e428ba9cece1" xmlns="urn:xmpp:fasten:0">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is using the id as sent by the original client, and it needs to be an id as assigned by the mix channel, I believe (I said this in the first round of comments)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this could be solved if apply-to would not only refer to the id, but also to the 'by' value of the stanza-id element. For example

<apply-to
  xmlns="urn:xmpp:fasten:0"
  id="a568706e-867b-49f1-a31b-e428ba9cece1"
  by='[email protected]'>

See also my 2019 mail to @standards: https://mail.jabber.org/pipermail/standards/2019-September/036435.html

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think stamping the origin of the id actually matters very much in this case (it very much does in others), because in this case only one id is going to be usable - the one from the MIX itself, so the stamper can be implicit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe, but I wonder how many implementations will get the implicit value wrong and open a security hole due that. I am usually a fan of avoiding unnecessary bytes on the wire and implicit values. But this smells a little bit like the carbon 'from' security hole that many implementations had.

I think at least, it should be clearly spelled out that the message is fastened to a message containing a stanza-id element where the 'id' matches the 'id' value from apply-to, and the 'by' value is the bare JID of the MIX channel (right?).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm with @Kev here - the example was just bad and used wrong ID. Adding "by" wouldn't change that here.

<retract xmlns='urn:xmpp:message-retract:0'/>
</apply-to>
</message>
]]></example>
<p>
Expand All @@ -198,19 +219,19 @@
Two approaches to message retraction can be used. In the first approach, the retracted message is simply removed. This is appropriate where retraction is provided as a user service and the user has rights to remove messages sent from the record.
</p>
<p>
The second approach is to leave a tombstone, which if taken MUST be done in the following manner. It is recommended to use a tombstone, as simply deleting the message may cause confusion with MAM queries. Use of a tombstone is appropriate where it is desired to leave a record of the message that was redacted.
With this approach, the original message &lt;body&gt; is removed and replaced with a tombstone using the &lt;retracted&gt; element qualified by the 'urn:xmpp:mix:misc:0' namespace that shows the JID of user performing the retraction and the time of the retraction.
The second approach is to leave a tombstone. It is recommended to use a tombstone, as simply deleting the message may cause confusion with MAM queries. Use of a tombstone is appropriate where it is desired to leave a record of the message that was redacted. The tombstones are also defined in &xep0424;. A service which supports tombstones MUST advertise the 'urn:xmpp:message-retract:0#tombstone' feature in its Service Discovery responses.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think we need to be explicit which version of 424 is required.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be fixed by correcting first example.

</p>

<example caption="Retracted message tombstone in a MAM result"><![CDATA[
<message id='aeb213' to='[email protected]/UUID-e3r/9264'>
<result xmlns='urn:xmpp:mam:2' queryid='f27' id='28482-98726-73623'>
<forwarded xmlns='urn:xmpp:forward:0'>
<delay xmlns='urn:xmpp:delay' stamp='2010-07-10T23:08:25Z'/>
<message xmlns='jabber:client' from="[email protected]"
to="[email protected]">
<retracted xmlns='urn:xmpp:mix:misc:0' by='[email protected]'
time='2010-07-10T23:08:25Z'/>
</message>
<retracted xmlns='urn:xmpp:message-retract:0' stamp='2010-07-10T23:08:25Z'>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The id of the MAM result needs to be the id the mix channel originally assigned to the retracted stanza.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be fixed by correcting first example.

<origin-id xmlns='urn:xmpp:sid:0' id='a568706e-867b-49f1-a31b-e428ba9cece1'/>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is missing the note of who retracted the message (also a comment from my original round ;))

</retracted>
</forwarded>
</result>
</message>
Expand Down