mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 08:45:04 -05:00
Merge branches 'feature/xep-0368', 'feature/protoxep-occupant-id' and 'feature/protoxep-reactions'
This commit is contained in:
Jonas Schäfer
commit
de98527aad
212
inbox/occupant-id.xml
Normal file
212
inbox/occupant-id.xml
Normal file
@ -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 <occupant-id> 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 <room@service>. A MUC
|
||||
supporting anonymous unique occupant identifiers attaches an
|
||||
<occupant-id> 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 <occupant-id>
|
||||
element. If the message or presence received by the MUC service already
|
||||
contains <occupant-id> element, the MUC service MUST replace such
|
||||
element before reflecting the message or presence including it.
|
||||
</p>
|
||||
<p>
|
||||
The <occupant-id> 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 <occupant-id> 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 ®ISTRAR; 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
Normal file
231
inbox/reactions.xml
Normal file
@ -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'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'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 <message> stanza containing a <reactions>
|
||||
element. The chosen emoji is included in a <reaction> element within
|
||||
the <reactions> 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 <message>
|
||||
with all <reaction> 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
|
||||
<reactions> 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 <reactions> element</p>
|
||||
<p>
|
||||
A message containing a <reactions> element SHOULD be of type 'chat'
|
||||
or 'groupchat'.
|
||||
</p>
|
||||
<p>
|
||||
A <reaction> 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 <<link url="http://www.unicode.org/reports/tr51/">http://www.unicode.org/reports/tr51/</link>>.</note>.
|
||||
Receiving entities MAY ignore <reaction> 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 <reactions> element MUST NOT contain the same reaction more than
|
||||
once. A receiving entity SHOULD ignore duplicate reactions inside a
|
||||
<reactions> element.
|
||||
</p>
|
||||
<p>
|
||||
The sending entity SHOULD add a <store/> hint, as defined in &xep0334;,
|
||||
if the message being reacted to does not carry a <no-store/> hint.
|
||||
</p>
|
||||
<p>
|
||||
If a message is updated using &xep0308;, the 'id' attribute of the
|
||||
<reactions> element SHOULD reference the original message id.
|
||||
A receiving entity SHOULD accept messages with a <reactions> 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 <reactions> element arrives delayed, which
|
||||
means it carries a <delay/> 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
|
||||
<stanza-id> 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;
|
||||
<origin-id> if present, or the value of the 'id' attribute on the
|
||||
<message> 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 ®ISTRAR; 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>
|
||||
Loading…
Reference in New Issue
Block a user