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

Merge branches 'feature/xep-0368', 'feature/protoxep-occupant-id' and 'feature/protoxep-reactions'

rm-impossible-guarantee
Jonas Schäfer 4 years ago
parent
586c0d4295 790e9bdae0 687a13c821
commit
de98527aad
2 changed files with 443 additions and 0 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 212
      inbox/occupant-id.xml
  2. 231
      inbox/reactions.xml

212
inbox/occupant-id.xml
Unescape View File

@ -0,0 +1,212 @@ @@ -0,0 +1,212 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Anonymous unique occupant identifiers for MUCs</title>
<abstract>This specification defines a method that allows clients to identify a MUC participant across reconnects and renames. It thus prevents impersonification of anonymous users.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
<spec>XEP-0030</spec>
<spec>XEP-0045</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>occupant-id</shortname>
<author>
<firstname>Marvin</firstname>
<surname>Wissfeld</surname>
<email>xsf@larma.de</email>
<jid>jabber@larma.de</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2019-07-13</date>
<initials>mw</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>
&xep0045; allows the creation of semi-anonymous multi-user text chats where
the real JID of a occupant can not be discovered by other MUC
occupants except moderators. As such users can freely join with using
any identity of their choice, allowing to impersonate users while they are
not online.
</p>
<p>
With recent standard extensions, it becomes more relevant to be able to
know if the occupant that sends one message is the same as the sender
of another message, for example for &xep0308;. At the same time it becomes
harder for clients to determine this, for example due to the use of &xep0313;
with MUCs.
</p>
<p>
This specification defines a method to combat issues arising out of the
anonymity of MUC occupants while at the same time ensuring their privacy
by not leaking their real JID to other occupants.
</p>
</section1>
<section1 topic='Discovering support' anchor='disco'>
<p>
If a MUC implements anonymous unique occupant identifiers, it MUST
specify the 'urn:xmpp:occupant-id:0' feature in its service discovery
information features as specified in &xep0030;.
</p>
<example caption='Client requests information about a MUC'><![CDATA[
<iq type='get'
to='coven@chat.shakespeare.lit'
from='hag66@shakespeare.lit/pda'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>]]></example>
<example caption='MUC advertises support for anonymous unique occupant identifiers'><![CDATA[
<iq type='result'
to='hag66@shakespeare.lit/pda'
from='coven@chat.shakespeare.lit'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:occupant-id:0'/>
...
</query>
</iq>]]></example>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic="Entering a Room" anchor="enter">
<p>
When a user enters a room, they send a presence to claim the nickname in
the MUC. A MUC that supports anonymous unique occupant identifiers
attaches an &lt;occupant-id&gt; element to the presence sent to all
occupants in the room.
</p>
<example caption="Client sends a message"><![CDATA[
<presence
from='hag66@shakespeare.lit/pda'
id='n13mt3l'
to='coven@chat.shakespeare.lit/thirdwitch'>
<x xmlns='http://jabber.org/protocol/muc'/>
</presence>]]></example>
<example caption="Service Sends New Occupant's Presence to All Occupants"><![CDATA[
<presence
from='coven@chat.shakespeare.lit/thirdwitch'
id='27C55F89-1C6A-459A-9EB5-77690145D624'
to='crone1@shakespeare.lit/desktop'>
<x xmlns='http://jabber.org/protocol/muc#user' />
<occupant-id xmlns="urn:xmpp:occupant-id:0" id="dd72603deec90a38ba552f7c68cbcc61bca202cd" />
</presence>]]></example>
</section2>
<section2 topic="Sending a Message to All Occupants" anchor="message">
<p>
An occupant sends a message to all other occupants in the room by
sending a message of type "groupchat" to the &lt;room@service&gt;. A MUC
supporting anonymous unique occupant identifiers attaches an
&lt;occupant-id&gt; element to the message sent to all occupants in the
room.
</p>
<example caption="Occupant Sends a Message to All Occupants"><![CDATA[
<message
from='hag66@shakespeare.lit/pda'
id='hysf1v37'
to='coven@chat.shakespeare.lit'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>]]></example>
<example caption="Service Reflects Message to All Occupants"><![CDATA[
<message
from='coven@chat.shakespeare.lit/thirdwitch'
id='hysf1v37'
to='crone1@shakespeare.lit/desktop'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<occupant-id xmlns="urn:xmpp:occupant-id:0" id="dd72603deec90a38ba552f7c68cbcc61bca202cd" />
</message>]]></example>
</section2>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<p>
Messages and presences MUST NOT contain more then one &lt;occupant-id&gt;
element. If the message or presence received by the MUC service already
contains &lt;occupant-id&gt; element, the MUC service MUST replace such
element before reflecting the message or presence including it.
</p>
<p>
The &lt;occupant-id&gt; element MUST be attached to every message and every
presence sent by a MUC. This includes messages sent as part of the
discussion history after joining a room, requested via &xep0313; or any
other means.
</p>
<p>
The &lt;occupant-id&gt; element MUST be ignored if support for the feature
is not announced via &xep0030;, as malicious clients might forge occupant
identifiers if the room does not support them.
</p>
<p>
A MUC service MAY allow the administrator to enable or disable occupant
identifiers on a per-room basis. If occupant identifiers are force enabled
for all rooms on a MUC service, it SHOULD additionally specify the
'urn:xmpp:occupant-id:0' feature on the MUC service. It MUST NOT specify
the feature on the service otherwise.
</p>
<section2 topic='Occupant ID generation' anchor='id-generation'>
<p>
The occupant identifier MUST be generated such that it is stable. This
means that if a user joins the same room a second time, the occupant
identifier MUST be the same as was assigned the first time. A user in
the sense of this specification is identified by its real bare JID.
</p>
<p>
The occupant identifier MUST be generated such that it is unique. This
means that it MUST be sufficiently improbable that one user is able to
re-create the occupant identifier of another user.
</p>
<p>
The occupant identifier MUST be generated such that it is anonymous. This
means that it MUST be sufficiently hard to determine the real bare JID of
an occupant from its occupant identifier. Additionally, a MUC service
SHOULD generate the identifier such that the occupant identifier of a user
in one room of the service does not match the occupant identifier of the
same user in another room of the same service.
</p>
<p>
The occupant identifier MUST have a maximum length of 128 characters. The
recipient MUST consider the occupant identifier to be an opaque string.
</p>
<p>
One way to ensure these properties is to generate a private secret key for
every room and use an HMAC algorithm with a sufficiently secure hash
function to generate the occupant identifier from the real bare JID and
that secret key. This procedure ensures all the required properties with
minimal server side storage requirements.
</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>
If a MUC uses occupant identifiers, nickname changes will be visible to
all occupants of the room. Clients MAY warn users about this circumstance
before joining the room.
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>The &REGISTRAR; includes 'urn:xmpp:occupant-id:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
<ul>
<li>urn:xmpp:occupant-id:0</li>
</ul>
</section2>
</section1>
</xep>

231
inbox/reactions.xml
Unescape View File

@ -0,0 +1,231 @@ @@ -0,0 +1,231 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Message Reactions</title>
<abstract>This specification defines a way for adding reactions to a message.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
<spec>XEP-0030</spec>
<spec>XEP-0115</spec>
<spec>XEP-0203</spec>
<spec>XEP-0334</spec>
<spec>XEP-0359</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>reactions</shortname>
<author>
<firstname>Natalie</firstname>
<surname>Wirth</surname>
<email>xsf@larma.de</email>
</author>
<author>
<firstname>Marvin</firstname>
<surname>Wissfeld</surname>
<email>xsf@larma.de</email>
<jid>jabber@larma.de</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2019-07-14</date>
<initials>nw/mw</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>
Message reactions allow to express an opinion or feeling towards a message
in a quick and light-weight way. Reactions are described in the form of
emojis and can enhance communication especially when chatting with multiple
parties. Other possible uses include voting and checking to-do list items.
</p>
<p>
Reactions are typically displayed in a summarizing fashion visually attached
to the message they belong to.
</p>
<p>
Related work has been done in &xep0367;. However, it can't be used for
reactions, as it would cause difficulties with non-supporting clients, is
not tailored to emojis and does not specify removal of reactions. To solve
these issues, this XEP introduces a separate XML element for reactions.
</p>
</section1>
<section1 topic='Discovering support' anchor='disco'>
<p>
If a client implements message reactions, it MUST specify the
'urn:xmpp:reactions:0' feature in its service discovery information features
as specified in &xep0030; and the Entity Capabilities profile specified in &xep0115;.
</p>
<example caption='Client requests information about a chat partner&apos;s client'><![CDATA[
<iq type='get'
to='romeo@montague.lit/orchard'
from='juliet@capulet.lit/balcony'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>]]></example>
<example caption='Partner&apos;s client advertises support for reactions'><![CDATA[
<iq type='result'
to='juliet@capulet.lit/balcony'
from='romeo@montague.lit/orchard'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:reactions:0'/>
...
</query>
</iq>]]></example>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic="Sending reactions to a message" anchor="sending-reactions">
<p>
When a user chooses to react to a message with a certain emoji, the
client sends a &lt;message&gt; stanza containing a &lt;reactions&gt;
element. The chosen emoji is included in a &lt;reaction&gt; element within
the &lt;reactions&gt; element. The message is referred to by including its
id or in MUCs its stanza-id as defined in &xep0359; in the 'id' attribute
of the reactions element.
</p>
<example caption="Romeo sends a message"><![CDATA[
<message to='juliet@capulet.net/balcony' id='744f6e18-a57a-11e9-a656-4889e7820c76' type='chat'>
<body>Hello, world!</body>
</message>]]></example>
<example caption="Juliet sends a 👋 reaction to the message"><![CDATA[
<message to='romeo@capulet.net/orchard' id='7fdd29fa-a57a-11e9-b04a-4889e7820c76' type='chat'>
<reactions id='744f6e18-a57a-11e9-a656-4889e7820c76' xmlns='urn:xmpp:reactions:0'>
<reaction>👋</reaction>
</reactions>
<store xmlns="urn:xmpp:hints"/>
</message>]]></example>
</section2>
<section2 topic="Updating reactions to a message" anchor="updating-reactions">
<p>
If the user chooses to remove reactions from or add reactions to a
message they have already reacted to, the client sends a &lt;message&gt;
with all &lt;reaction&gt; elements that are (still or newly) applicable
to that message.
</p>
<example caption="Juliet adds a 🐢 reaction to the message"><![CDATA[
<message to='romeo@capulet.net/orchard' id='96d73204-a57a-11e9-88b8-4889e7820c76' type='chat'>
<reactions id='744f6e18-a57a-11e9-a656-4889e7820c76' xmlns='urn:xmpp:reactions:0'>
<reaction>👋</reaction>
<reaction>🐢</reaction>
</reactions>
<store xmlns="urn:xmpp:hints"/>
</message>]]></example>
<p>
In order to remove all reactions from a message, an empty
&lt;reactions&gt; element is sent.
</p>
<example caption="Juliet removes all reactions from the message"><![CDATA[
<message to='romeo@capulet.net/orchard' id='973c9d2e-a57a-11e9-af82-4889e7820c76' type='chat'>
<reactions id='744f6e18-a57a-11e9-a656-4889e7820c76' xmlns='urn:xmpp:reactions:0'/>
<store xmlns="urn:xmpp:hints"/>
</message>]]></example>
</section2>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<p>Messages MUST NOT contain more then one &lt;reactions&gt; element</p>
<p>
A message containing a &lt;reactions&gt; element SHOULD be of type 'chat'
or 'groupchat'.
</p>
<p>
A &lt;reaction&gt; element SHOULD only contain Unicode codepoints that can
be displayed as a single emoji, as specified in the latest revision of the
<link url="http://www.unicode.org/reports/tr51/">Unicode® Technical Standard #51</link> <note>Unicode® Technical Standard #51 &lt;<link url="http://www.unicode.org/reports/tr51/">http://www.unicode.org/reports/tr51/</link>&gt;.</note>.
Receiving entities MAY ignore &lt;reaction&gt; elements that do not comply
with this specification.
</p>
<p>
A receiving client SHOULD show reactions attached to the message they where
in response to. Reactions MAY be displayed in a summarized fashion.
</p>
<p>
A &lt;reactions&gt; element MUST NOT contain the same reaction more than
once. A receiving entity SHOULD ignore duplicate reactions inside a
&lt;reactions&gt; element.
</p>
<p>
The sending entity SHOULD add a &lt;store/&gt; hint, as defined in &xep0334;,
if the message being reacted to does not carry a &lt;no-store/&gt; hint.
</p>
<p>
If a message is updated using &xep0308;, the 'id' attribute of the
&lt;reactions&gt; element SHOULD reference the original message id.
A receiving entity SHOULD accept messages with a &lt;reactions&gt; element
referencing a message correction and SHOULD handle such element as if
it was using the message id of the original message.
</p>
<section2 topic='Acceptable reactions' anchor='acceptable-reactions'>
<p>
In direct conversations, a reaction MUST only be accepted if the senders
bare JID matches the bare JID of any of the two involved parties.
</p>
<p>
In MUCs and MUC PMs, the recipient SHOULD ensure that the real bare JID of
the sending occupant did not already send a reaction to that message to
accept it as a new reaction, e.g. by keeping track of leave/join
presences since the message was send. This implies that in semi-anonymous
MUCs it MAY be impossible to attach reactions to a message received from
the history. A reaction MAY still be a valid reaction update (as per the
next paragraph) if it was not accepted as a new reaction.
</p>
<p>
A reaction MUST only be considered an update if it orignates from the same
sender as a previous reaction message. In direct conversations, this means
the bare JID MUST match the original bare JID. In MUCs and MUC PMs the
senders full JID MAY not match the original full JID, but the recipient
MUST ensure that the real bare JID of the sending occupant is the same as
the real bare JID of the previous reaction message, e.g. by keeping track
of leave/join presences.
</p>
<p>
If a message containing a &lt;reactions&gt; element arrives delayed, which
means it carries a &lt;delay/&gt; element, as defined in &xep0203; it SHOULD
only be accepted, if no newer reaction from the same sender was already
accepted.
</p>
</section2>
<section2 topic='Using the correct ID' anchor='business-id'>
<p>
For messages of type 'groupchat', the stanza's 'id' attribute MUST NOT be
used for reactions. Instead, in group chat situations, the ID assigned to
the stanza by the group chat itself must be used. This is discovered in a
&lt;stanza-id&gt; element with a 'by' attribute that matches the bare JID
of the group chat, as defined in &xep0359;.
</p>
<p>
This implies that group chat messages without a &xep0359; stanza-id cannot
be reacted to.
</p>
<p>
For other message types the sender should use the 'id' from a &xep0359;
&lt;origin-id&gt; if present, or the value of the 'id' attribute on the
&lt;message&gt; otherwise.
</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>The &REGISTRAR; includes 'urn:xmpp:reactions:0' in its registry of protocol namespaces (see &NAMESPACES;).</p>
<ul>
<li>urn:xmpp:reactions:0</li>
</ul>
</section2>
</section1>
</xep>
Write Preview
Loading…
Cancel
Save