moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

Use MAM-ID in retract

This commit is contained in:
Steve Kille 2018-01-02 11:07:11 +00:00
parent 34b3cf81c1
commit f9d7d56b87
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
xep-0369.xml
View File

@ -52,6 +52,7 @@
Creating Channel Clarification,
Address security concerns on Converting a 1:1 Conversation to a Channel,
Remove requirement for all user clients to support MIX,
Change Retract to use MAM-ID,
</p></remark>
</revision> <revision>
@ -1750,7 +1751,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 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. If this is done the original message MAY be replaced by a tombstone. The protocol to request retraction does this by adding to the message a &lt;retract&gt; element qualified by the 'urn:xmpp:mix:1' namespace. The &lt;retract&gt; element MUST include an &lt;id&gt; attribute that holds the id of the original message. A message and it's 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 does this by adding to a message a &lt;retract&gt; element qualified by the 'urn:xmpp:mix:1' namespace. A retract messages MUST NOT have a body. The &lt;retract&gt; element MUST include an &lt;id&gt; 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 it's retraction shown in the following example.
</p>
<example caption="User Retracts a Message"><![CDATA[
@ -1763,20 +1764,20 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<message from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'
id='92vax143g'>
<retract id='abcde' xmlns='urn:xmpp:mix:1'/>
<retract id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD' xmlns='urn:xmpp:mix:1'/>
</message>
]]></example>
<p>
The MIX channel will allow a user to retract a message sent by the user if the 'Allow User Message Retraction' option is configured. The MIX channel will allow an administrative user to retract any message if the user is in the group specified by the 'Administrator Message Retraction Rights' option.
</p>
<p>
If the retraction message is accepted, it will be distributed to channel participants. This will allow retraction to happen in the MAM archive of each channel participant and to reflect the retraction in client GUI. A client receiving a retraction message SHOULD ensure that the retracted message is no longer displayed to the end user.
If the retraction message is accepted, it MUST be distributed to channel participants. This will allow retraction to happen in the MAM archive of each channel participant and to reflect the retraction in client GUI. A client receiving a retraction message SHOULD ensure that the retracted message is no longer displayed to the end user.
</p>
<p>
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. This is appropriate where it is desired to leave a record of the message that was redacted.
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:1' namespace that shows the JID of user performing the retraction and the time of the retraction.
</p>
<example caption="Retracted message tombstone in a MAM result"><![CDATA[