From 687a13c8211a8b1e65eaae7cab2658129198e77f Mon Sep 17 00:00:00 2001 From: Marvin W Date: Sun, 14 Jul 2019 18:51:08 +0200 Subject: [PATCH 1/2] Add ProtoXEP for reactions --- inbox/reactions.xml | 231 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 231 insertions(+) create mode 100644 inbox/reactions.xml diff --git a/inbox/reactions.xml b/inbox/reactions.xml new file mode 100644 index 00000000..46b2a4de --- /dev/null +++ b/inbox/reactions.xml @@ -0,0 +1,231 @@ + + + %ents; + ]> + + +
+ Message Reactions + This specification defines a way for adding reactions to a message. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0030 + XEP-0115 + XEP-0203 + XEP-0334 + XEP-0359 + + + + reactions + + Natalie + Wirth + xsf@larma.de + + + Marvin + Wissfeld + xsf@larma.de + jabber@larma.de + + + 0.0.1 + 2019-07-14 + nw/mw +

First draft.

 + +
+ +

+ 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. +

+

+ Reactions are typically displayed in a summarizing fashion visually attached + to the message they belong to. +

+

+ 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. +

+ + +

+ 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;. +

+ + +]]> + + +... + +... + +]]> + + + +

+ 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. +

+ + Hello, world! +]]> + + + 👋 + + +]]> + + +

+ 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. +

+ + + 👋 + 🐢 + + +]]> +

+ In order to remove all reactions from a message, an empty + <reactions> element is sent. +

+ + + +]]> + + + +

Messages MUST NOT contain more then one <reactions> element

+

+ A message containing a <reactions> element SHOULD be of type 'chat' + or 'groupchat'. +

+

+ A <reaction> element SHOULD only contain Unicode codepoints that can + be displayed as a single emoji, as specified in the latest revision of the + Unicode® Technical Standard #51 Unicode® Technical Standard #51 <http://www.unicode.org/reports/tr51/>.. + Receiving entities MAY ignore <reaction> elements that do not comply + with this specification. +

+

+ A receiving client SHOULD show reactions attached to the message they where + in response to. Reactions MAY be displayed in a summarized fashion. +

+

+ A <reactions> element MUST NOT contain the same reaction more than + once. A receiving entity SHOULD ignore duplicate reactions inside a + <reactions> element. +

+

+ 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. +

+

+ 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. +

+ +

+ 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. +

+

+ 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. +

+

+ 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. +

+

+ 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. +

+ + +

+ 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;. +

+

+ This implies that group chat messages without a &xep0359; stanza-id cannot + be reacted to. +

+

+ 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. +

+ + + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; includes 'urn:xmpp:reactions:0' in its registry of protocol namespaces (see &NAMESPACES;).

+
    +
  • urn:xmpp:reactions:0
    • +
+ + + From 790e9bdae0a53f8dca0b2536540d88ac9dd07662 Mon Sep 17 00:00:00 2001 From: Marvin W Date: Sun, 14 Jul 2019 18:46:35 +0200 Subject: [PATCH 2/2] Add ProtoXEP for occupant identifiers --- inbox/occupant-id.xml | 212 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 212 insertions(+) create mode 100644 inbox/occupant-id.xml diff --git a/inbox/occupant-id.xml b/inbox/occupant-id.xml new file mode 100644 index 00000000..a35596bc --- /dev/null +++ b/inbox/occupant-id.xml @@ -0,0 +1,212 @@ + + + %ents; + ]> + + +
+ Anonymous unique occupant identifiers for MUCs + This specification defines a method that allows clients to identify a MUC participant across reconnects and renames. It thus prevents impersonification of anonymous users. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0030 + XEP-0045 + + + + occupant-id + + Marvin + Wissfeld + xsf@larma.de + jabber@larma.de + + + 0.0.1 + 2019-07-13 + mw +

First draft.

 + +
+ +

+ &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. +

+

+ 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. +

+

+ 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. +

+ + +

+ 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;. +

+ + +]]> + + +... + +... + +]]> + + + +

+ 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. +

+ + +]]> + + + +]]> + + +

+ 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. +

+ + Harpier cries: 'tis time, 'tis time. +]]> + + Harpier cries: 'tis time, 'tis time. + +]]> + + + +

+ 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. +

+

+ 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. +

+

+ 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. +

+

+ 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. +

+ +

+ 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. +

+

+ 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. +

+

+ 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. +

+

+ The occupant identifier MUST have a maximum length of 128 characters. The + recipient MUST consider the occupant identifier to be an opaque string. +

+

+ 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. +

+ + + +

+ 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. +

+ + +

This document requires no interaction with &IANA;.

+ + + +

The ®ISTRAR; includes 'urn:xmpp:occupant-id:0' in its registry of protocol namespaces (see &NAMESPACES;).

+
    +
  • urn:xmpp:occupant-id:0
    • +
+ + +