From f17f86418c8b3d7af3ddfb9ef331efe586275fbe Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Sun, 8 Mar 2020 16:02:09 +0100 Subject: [PATCH] XEP-0384: define group chats --- xep-0384.xml | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 68 insertions(+), 1 deletion(-) diff --git a/xep-0384.xml b/xep-0384.xml index 05e0ea11..536a2448 100644 --- a/xep-0384.xml +++ b/xep-0384.xml @@ -29,6 +29,32 @@ andy@strb.org andy@strb.org + + Daniel + Gultsch + daniel@gultsch.de + daniel@gultsch.de + + + Tim + Henkes + + + Klaus + Herberth + klaus@jsxc.org + + + Paul + Schaub + vanitasvitae@fsfe.org + + + Marvin + Wißfeld + jabber@larma.de + xmpp@larma.de + 0.3.0 2018-07-31 @@ -465,7 +491,7 @@ BASE64ENCODED... - + BASE64ENCODED... BASE64ENCODED... @@ -487,6 +513,47 @@ After either the OMEMOKeyExchange or the OMEMOAuthenticatedMessage is decrypted, the content is decrypted as described in the section about Message Decryption.

+ +

Note: OMEMO encrypted group chats are currently specified to work with &xep0045;. This XEP might be updated in the future to also specify the usage in &xep0369;.

+

A Multi-User Chat room that supports OMEMO MUST be configured non-anonymous and SHOULD be configured members-only.

+

A participant wanting to send a message to a group chat MUST first retrieve the members list and then fetch the device list for each member (via pubsub and to their real JIDs) and then subsequently fetch all active bundles.

+ +

On join a participant MUST request the member list, the admin list and the owner list as described in XEP-0045 §9.5, XEP-0045 §10.8, and XEP-0045 §10.5 respectively. Those three lists MUST be combined as the recipients of OMEMO encrypted messages. Once joined a participant MUST keep track of affiliation changes that occur in the room. This is both for removals (users getting banned or have their affiliation set to none) and users becoming members, admins or owners.

+
+ +

Before sending a message a participant SHOULD explicitly fetch device lists for all other participant if the list isn’t already cached..

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

Before publishing a freshly generated Device ID for the first time, a device MUST check whether that Device ID already exists, and if so, generate a new one.