diff --git a/content/implementation-guidelines/_index.md b/content/implementation-guidelines/_index.md index 4a38efac4..eb137a16a 100644 --- a/content/implementation-guidelines/_index.md +++ b/content/implementation-guidelines/_index.md @@ -7,7 +7,7 @@ layout: single ## Overview **Modern XMPP** is an independent project launched to improve the quality of user-to-user messaging applications -that use XMPP. [XMPP](https://xmpp.org/) is a mature open standard for internet messaging. If you are reading +that use XMPP. [XMPP](/) is a mature open standard for internet messaging. If you are reading this, you have probably heard of it. We are developing a handful of simple documents aimed at people who wish to build on top of XMPP. The recommendations are derived from healthy discussions between developers from multiple XMPP projects and other members of the XMPP community. @@ -22,11 +22,9 @@ and thus make it possible to identify and weed out software that falls behind th ## Current status -It is early days. We are still building the foundations of what will become the initial set of documents. Nevertheless, we already have a bunch of stuff documented that developers of XMPP software (both new and experienced) will find useful. This includes [design guidelines](client/design.md) and lower-level [protocol implementation recommendations](client/protocol.md). +It is early days. We are still building the foundations of what will become the initial set of documents. Nevertheless, we already have a bunch of stuff documented that developers of XMPP software (both new and experienced) will find useful. This includes [design guidelines](/implementation-guidelines/design) and lower-level [protocol implementation recommendations](/implementation-guidelines/protocol). If you're interested in joining us, our primary discussion venue is our *channel* which can be reached at: - XMPP: [modernxmpp@rooms.modernxmpp.org](xmpp:modernxmpp@rooms.modernxmpp.org?join) - Web: [chat.modernxmpp.org](https://chat.modernxmpp.org/) - -Contributions to the docs can be made through Github [modernxmpp/modernxmpp](https://github.com/modernxmpp/modernxmpp). diff --git a/content/implementation-guidelines/design.md b/content/implementation-guidelines/design.md index 1f9330102..e0336e731 100644 --- a/content/implementation-guidelines/design.md +++ b/content/implementation-guidelines/design.md @@ -1,11 +1,7 @@ --- -Title: Design Guidelines +Title: Client Design Guidelines --- -Title: - -# Client design guidelines - This document lays out a set of guidelines for designing Modern XMPP clients. For contributions, please [open an issue or pull request](https://github.com/modernxmpp/modernxmpp) at Github for discussion. @@ -41,8 +37,8 @@ Support for these options is OPTIONAL, but **not** recommended. They are only ne | Connect port | The network port to connect to | | TLS Mode[^tls-mode] | Multiple choice: "STARTTLS" or "Direct TLS" | -Both of the above should be automatically discovered from DNS, according to the [rules in RFC 6120](https://xmpp.org/rfcs/rfc6120.html#tcp-resolution). -Clients that support other connection mechanisms, such as BOSH, SHOULD also implement [XEP-0156](https://xmpp.org/extensions/xep-0156.html). +Both of the above should be automatically discovered from DNS, according to the [rules in RFC 6120](/rfcs/rfc6120.html#tcp-resolution). +Clients that support other connection mechanisms, such as BOSH, SHOULD also implement [XEP-0156](/extensions/xep-0156.html). ### Deprecated options @@ -50,7 +46,7 @@ Support for these options is NOT RECOMMENDED. | Option | Description | Notes | |:-------------|:-----------------------------------------|:--------| -| Resource | The resource to request from the server | see [Resource generation](protocol.md#resource-generation) | +| Resource | The resource to request from the server | see [Resource generation](/implementation-guidelines/protocol#resource-generation) | | Priority | The priority to include in presence | 0 | ## User status @@ -133,7 +129,7 @@ Support for multiple accounts is OPTIONAL. ## Group chat -You can find more details about [group chats here](groupchat.md). +You can find more details about [group chats here](/implementation-guidelines/groupchat). ## Documentation @@ -168,7 +164,7 @@ Address book : Platform-dependent. If the application is somehow linked to the user's address book and is able to access a contact's information there. User nickname -: A nickname published by the sender in PEP per [XEP-0172](https://xmpp.org/extensions/xep-0172.html). +: A nickname published by the sender in PEP per [XEP-0172](/extensions/xep-0172.html). Resource : The resource of the sending JID. @@ -203,7 +199,7 @@ A client may want to associate a color with a user. Example use cases for this i - Dummy avatars in contexts where an avatar cannot be or has not yet been retrieved - Coloring the user name in a conversation log (be aware that this needs to be done very carefully to be accessible!) -To generate a color for a user, the algorithm described in [XEP-0392](https://xmpp.org/extensions/xep-0392.html) MUST be used. +To generate a color for a user, the algorithm described in [XEP-0392](/extensions/xep-0392.html) MUST be used. ### Generator input based on context diff --git a/content/implementation-guidelines/groupchat.md b/content/implementation-guidelines/groupchat.md index 5ab3f71dc..22e4148b0 100644 --- a/content/implementation-guidelines/groupchat.md +++ b/content/implementation-guidelines/groupchat.md @@ -20,9 +20,9 @@ To detect if a multi-user chat is a *group chat* or a *channel* | Publicly listed | muc#roomconfig_publicroom | No (3) | muc_hidden | Yes | muc_public | | PMs | muc#roomconfig_allowpm | No (3) | muc#roomconfig_allowpm to `none` | Yes | muc#roomconfig_allowpm to `anyone` | -(1) As defined in [XEP-0045: Multi-User Chat - 16.5.3](https://xmpp.org/extensions/xep-0045.html#registrar-formtype-owner) +(1) As defined in [XEP-0045: Multi-User Chat - 16.5.3](/extensions/xep-0045.html#registrar-formtype-owner) -(2) As defined in [XEP-0045: Multi-User Chat - 16.3](https://xmpp.org/extensions/xep-0045.html#registrar-features) +(2) As defined in [XEP-0045: Multi-User Chat - 16.3](/extensions/xep-0045.html#registrar-features) (3) Immutable for *group chats*. @@ -31,7 +31,7 @@ Options marked `(3) Immutable` should be used when creating group chats, and als #### About PMs While it is possible to entirely prevent PMs from being sent with -[`muc#roomconfig_allowpm`](https://xmpp.org/extensions/xep-0045.html#privatemessage), +[`muc#roomconfig_allowpm`](/extensions/xep-0045.html#privatemessage), clients should prefer using JIDs when `muc#roomconfig_whois` is set to `anyone`. In channels, if the initiating client has access to revealed JIDs (with @@ -73,12 +73,12 @@ Bookmark : If the chat is present in the user's bookmarks and has a nickname present (as the resource). Reserved name -: A chat [may be queried](https://xmpp.org/extensions/xep-0045.html#reservednick) to fetch the +: A chat [may be queried](/extensions/xep-0045.html#reservednick) to fetch the name that is registered by the user for that chat. User nickname (PEP) : The name stored in the user's account according to - [XEP-0172](https://xmpp.org/extensions/xep-0172.html#manage). + [XEP-0172](/extensions/xep-0172.html#manage). User nickname (vCard) : The name stored in the user's vCard as `NICKNAME`. @@ -91,7 +91,7 @@ JID username ### Other user's names -The display of other user's names is covered in the [general UI recommendations](design.md#names). +The display of other user's names is covered in the [general UI recommendations](/implementation-guidelines/design#names). ## Bookmarks @@ -99,13 +99,13 @@ Figuring out which group chats to join is the client’s job. For that it should store the list of group chats to rejoin automatically on the server, named bookmarks. Three possible protocols exist for this: -- [XEP-0402](https://xmpp.org/extensions/xep-0402.html) which is the +- [XEP-0402](/extensions/xep-0402.html) which is the current preferred method -- [XEP-0048 1.1](https://xmpp.org/extensions/xep-0048.html), recently +- [XEP-0048 1.1](/extensions/xep-0048.html), recently deprecated but still in use by some clients -- [XEP-0048 1.0](https://xmpp.org/extensions/attic/xep-0048-1.0.html), +- [XEP-0048 1.0](/extensions/attic/xep-0048-1.0.html), in wide use, based on - [XEP-0049](https://xmpp.org/extensions/xep-0049.html) + [XEP-0049](/extensions/xep-0049.html) In order to see the same set of bookmarks as every other client the user might be using, it is recommended to implement **XEP-0048 1.0** first @@ -115,7 +115,7 @@ This legacy protocol however doesn’t support notifications when the bookmarks change due to another client or the server. To avoid this issue, a modern client should also implement **XEP-0402** ("PEP Native Bookmarks"), but use it *only* if the account advertises 'urn:xmpp:bookmarks:1#compat' (as defined in [XEP-0402 paragraph 5.3 -Compatibility](https://xmpp.org/extensions/xep-0402.html#compatibility)). +Compatibility](/extensions/xep-0402.html#compatibility)). Implementing XEP-0048 1.1 is not recommended in modern clients. @@ -133,7 +133,7 @@ Clients must always use real JIDs for messaging privately within a *group chat* -[^rationale-gc]: Rationale [group chats](/rationale#group-chats) +[^rationale-gc]: Rationale [group chats](/implementation-guidelines/rationale#group-chats) [^local-nickname]: To avoid requiring the user to configure a nickname manually on each device, shared cross-device stores such as PEP and vCard should be preferred. [^pm-realjid]: If real JIDs are known to all participants, it is preferable to use that for private communication to avoid confusion. Through-MUC PMs have the following disadvantages: diff --git a/content/implementation-guidelines/invites.md b/content/implementation-guidelines/invites.md index d16e6175a..9ef3374c9 100644 --- a/content/implementation-guidelines/invites.md +++ b/content/implementation-guidelines/invites.md @@ -116,6 +116,6 @@ If possible, platform detection should be used to highlight download links relev If the detected platform is a desktop environment, consider also adding a QR code for easy transmission to a user's mobile device. -[XEP-0401]: https://xmpp.org/extensions/xep-0401.html "Ad-hoc Account Invitation Generation" -[XEP-0445]: https://xmpp.org/extensions/xep-0445.html "Pre-Authenticated In-Band Registration" -[XEP-0379]: https://xmpp.org/extensions/xep-0379.html "Pre-Authenticated Roster Subscription" +[XEP-0401]: /extensions/xep-0401.html "Ad-hoc Account Invitation Generation" +[XEP-0445]: /extensions/xep-0445.html "Pre-Authenticated In-Band Registration" +[XEP-0379]: /extensions/xep-0379.html "Pre-Authenticated Roster Subscription" diff --git a/content/implementation-guidelines/protocol.md b/content/implementation-guidelines/protocol.md index 3df42d435..cfd31bad2 100644 --- a/content/implementation-guidelines/protocol.md +++ b/content/implementation-guidelines/protocol.md @@ -4,7 +4,7 @@ Title: XMPP Protocol Guidelines ## Overview -The XSF has published [over 400 XEPs](https://xmpp.org/extensions/) over many years. However as technology, +The XSF has published [over 400 XEPs](/extensions/) over many years. However as technology, user expectations and best practices evolve, the protocol too is always evolving. This leads to confusion about which set of XEPs are "current", which are required @@ -42,12 +42,12 @@ It is often useful to know what features a remote entity supports before perform For example when deciding whether to send formatted messages, or determining the best available method of transferring a file. -- [XEP-0030](https://xmpp.org/extensions/xep-0030.html) is the basic mechanism for advertising and discovering features -- [XEP-0115](https://xmpp.org/extensions/xep-0115.html) is a strongly recommended extension that allows caching of these features +- [XEP-0030](/extensions/xep-0030.html) is the basic mechanism for advertising and discovering features +- [XEP-0115](/extensions/xep-0115.html) is a strongly recommended extension that allows caching of these features #### Notes -[XEP-0115](https://xmpp.org/extensions/xep-0115.html) may be revised or replaced at some point in the future, such as by [XEP-0390](https://xmpp.org/extensions/xep-0390.html), to allow +[XEP-0115](/extensions/xep-0115.html) may be revised or replaced at some point in the future, such as by [XEP-0390](/extensions/xep-0390.html), to allow hash agility and making the algorithm more robust to cache poisoning attacks. ### Resource generation @@ -62,16 +62,16 @@ This section covers some protocols that are useful for general messaging. ### Formatting -The current recommendation is that developers may simply implement the rules in [XEP-0393](https://xmpp.org/extensions/xep-0393.html) for +The current recommendation is that developers may simply implement the rules in [XEP-0393](/extensions/xep-0393.html) for formatting message bodies that they receive. #### XHTML-IM deprecation -A previous formatting specification defined in [XEP-0071](https://xmpp.org/extensions/xep-0071.html) has been deprecated. Many implementations +A previous formatting specification defined in [XEP-0071](/extensions/xep-0071.html) has been deprecated. Many implementations failed to properly sanitize the formatted payload (it's tricky), leading to security issues (particularly in web applications). -Implementation of [XEP-0071](https://xmpp.org/extensions/xep-0071.html) is not encouraged, but if formatting is a strong requirement along with +Implementation of [XEP-0071](/extensions/xep-0071.html) is not encouraged, but if formatting is a strong requirement along with backwards compatibility (many clients still implement it currently), it remains an option if careful attention is given to sanitizing the XHTML before display. Consider using [xhtml-im.js](https://github.com/zeen/xhtml-im.js) in a web client, or as a reference. @@ -89,8 +89,8 @@ approach to messaging, where all their devices are in sync. Modern XMPP clients should not set a priority in their presence, and they should implement the following XEPs: -- [XEP-0280](https://xmpp.org/extensions/xep-0280.html): Message Carbons - for "live" synchronization of conversations between online devices -- [XEP-0313](https://xmpp.org/extensions/xep-0313.html): Message Archive Management - for "catch-up" of messages that were exchanged while a device was offline +- [XEP-0280](/extensions/xep-0280.html): Message Carbons - for "live" synchronization of conversations between online devices +- [XEP-0313](/xep-0313.html): Message Archive Management - for "catch-up" of messages that were exchanged while a device was offline ### Known issues @@ -106,7 +106,7 @@ If you enable Carbons first, you may receive duplicates from the archive of mess The current best solution is to enable Carbons, perform the query, and de-duplicate any received messages before presentation to the user. -This issue will be solved in the future through [XEP-0386](https://xmpp.org/extensions/xep-0386.html) or an alternative atomic "fetch and subscribe" +This issue will be solved in the future through [XEP-0386](/extensions/xep-0386.html) or an alternative atomic "fetch and subscribe" command. #### IDs of outgoing messages @@ -131,8 +131,8 @@ with the ID added and any other additional info), or through a new MAM subscript There are some special considerations that mobile clients can make to increase battery life and reduce data consumption. -- [XEP-0286](https://xmpp.org/extensions/xep-0286.html) - informational XEP providing advice to mobile developers on efficient data usage -- [XEP-0352](https://xmpp.org/extensions/xep-0352.html) - used to inform the server of whether the client is currently active/focused (which allows +- [XEP-0286](/extensions/xep-0286.html) - informational XEP providing advice to mobile developers on efficient data usage +- [XEP-0352](/extensions/xep-0352.html) - used to inform the server of whether the client is currently active/focused (which allows the server to prioritize traffic) ## Reliability @@ -140,8 +140,8 @@ the server to prioritize traffic) In the real world, it is normal for clients to get briefly disconnected. These extensions deal with ensuring reliable message delivery and reporting. -- [XEP-0184](https://xmpp.org/extensions/xep-0184.html) - end-to-end acknowledgement, i.e. the recipient has successfully received the message -- [XEP-0198](https://xmpp.org/extensions/xep-0198.html) - hop-to-hop acknowledgement, and allows efficient resume of broken connections without data loss +- [XEP-0184](/extensions/xep-0184.html) - end-to-end acknowledgement, i.e. the recipient has successfully received the message +- [XEP-0198](/extensions/xep-0198.html) - hop-to-hop acknowledgement, and allows efficient resume of broken connections without data loss ## Read state synchronization @@ -150,9 +150,9 @@ that further improves the experience is not having to dismiss notifications and unread counters for messages that have already been read on another device. -- [XEP-0280](https://xmpp.org/extensions/xep-0280.html): Carbon copies +- [XEP-0280](/extensions/xep-0280.html): Carbon copies of replies, implying that prior messages have been read. -- [XEP-0333](https://xmpp.org/extensions/xep-0333.html): Chat Markers - +- [XEP-0333](/extensions/xep-0333.html): Chat Markers - to signal that messages have been shown to the user. ### Notifications @@ -182,7 +182,7 @@ There are three file transfer methods that a modern XMPP client may implement: **Required:** *yes* -The newest file transfer mechanism available, described in [XEP-0363](https://xmpp.org/extensions/xep-0363.html). It is strongly recommended to +The newest file transfer mechanism available, described in [XEP-0363](/extensions/xep-0363.html). It is strongly recommended to implement this mechanism to provide the best user experience. #### Benefits @@ -203,7 +203,7 @@ implement this mechanism to provide the best user experience. After uploading the file successfully, the sender should communicate the URL to the recipient by sending a `` stanza with the "Get URL" provided by the server in the `` of the message. -Additionally the sender should include a [jabber:x:oob](https://xmpp.org/extensions/xep-0066.html#x-oob) +Additionally the sender should include a [jabber:x:oob](/extensions/xep-0066.html#x-oob) element in the message stanza with the same URL. !!! note @@ -226,10 +226,10 @@ originally developed at Google and contributed to the XSF where it evolved into Because it is a generic framework that supports different underlying transports and different media types, Jingle is split into multiple XEPs. For file transfer the following are relevant: -- [XEP-0166](https://xmpp.org/extensions/xep-0166.html) - the core Jingle framework -- [XEP-0234](https://xmpp.org/extensions/xep-0234.html) - the Jingle file transfer definition -- [XEP-0260](https://xmpp.org/extensions/xep-0260.html) - the most common transport mechanism for files (SOCKS5 Bytestreams - may be directly peer-to-peer or server-mediated) -- [XEP-0261](https://xmpp.org/extensions/xep-0261.html) - a fallback transport for tunneling the data directly over the XMPP stream (inefficient and slow, but always succeeds) +- [XEP-0166](/extensions/xep-0166.html) - the core Jingle framework +- [XEP-0234](/extensions/xep-0234.html) - the Jingle file transfer definition +- [XEP-0260](/extensions/xep-0260.html) - the most common transport mechanism for files (SOCKS5 Bytestreams - may be directly peer-to-peer or server-mediated) +- [XEP-0261](/extensions/xep-0261.html) - a fallback transport for tunneling the data directly over the XMPP stream (inefficient and slow, but always succeeds) #### Advantages @@ -255,11 +255,11 @@ it suitable for larger files. **Required:** *no - optionally implement for sending large files to pre-Jingle clients* -[XEP-0096](https://xmpp.org/extensions/xep-0096.html) describes the stream negotiation protocol that was used before Jingle. It is widely supported, and can use the same +[XEP-0096](/extensions/xep-0096.html) describes the stream negotiation protocol that was used before Jingle. It is widely supported, and can use the same transports: -- [XEP-0065](https://xmpp.org/extensions/xep-0065.html) -- [XEP-0047](https://xmpp.org/extensions/xep-0047.html) +- [XEP-0065](/extensions/xep-0065.html) +- [XEP-0047](/extensions/xep-0047.html) It is not recommended to implement this mechanism in new clients, except for compatibility with older clients is required (and HTTP Upload does not suffice for some reason). @@ -278,11 +278,11 @@ is required (and HTTP Upload does not suffice for some reason). ## User Profiles -- [XEP-0163](https://xmpp.org/extensions/xep-0163.html) is the base publishing method. -- [XEP-0222](https://xmpp.org/extensions/xep-0222.html) for access controls. -- [XEP-0084](https://xmpp.org/extensions/xep-0084.html) for profile picture. -- [XEP-0172](https://xmpp.org/extensions/xep-0172.html) for nickname. -- [XEP-0292](https://xmpp.org/extensions/xep-0292.html) for extended details (optional). +- [XEP-0163](/extensions/xep-0163.html) is the base publishing method. +- [XEP-0222](/extensions/xep-0222.html) for access controls. +- [XEP-0084](/extensions/xep-0084.html) for profile picture. +- [XEP-0172](/extensions/xep-0172.html) for nickname. +- [XEP-0292](/extensions/xep-0292.html) for extended details (optional). Simpler clients may choose to only use XEP-0084 and XEP-0172 to provide a limited user profile, while more advanced clients could publish more details via XEP-0292. @@ -302,12 +302,12 @@ under 100 KiB. ### Access control -Data published via [XEP-0163](https://xmpp.org/extensions/xep-0163.html) would by default be +Data published via [XEP-0163](/extensions/xep-0163.html) would by default be available only to the user's contacts. Historically, profiles published via the legacy -[XEP-0054](https://xmpp.org/extensions/xep-0054.html) method were public. +[XEP-0054](/extensions/xep-0054.html) method were public. Modern PEP implementations should implement for 'access model' as described by -[XEP-0222](https://xmpp.org/extensions/xep-0222.html), and allow users to share or limit their +[XEP-0222](/extensions/xep-0222.html), and allow users to share or limit their personal details as they choose. Access model for both XEP-0084 nodes and the XEP-0172 node should be kept the same. @@ -321,20 +321,20 @@ such as: ### Legacy -- [XEP-0054](https://xmpp.org/extensions/xep-0054.html) is the legacy profile publishing method. -- [XEP-0153](https://xmpp.org/extensions/xep-0153.html) notifies contacts about avatar changes. -- [XEP-0398](https://xmpp.org/extensions/xep-0398.html) tells you whether you can ignore that and +- [XEP-0054](/extensions/xep-0054.html) is the legacy profile publishing method. +- [XEP-0153](/extensions/xep-0153.html) notifies contacts about avatar changes. +- [XEP-0398](/extensions/xep-0398.html) tells you whether you can ignore that and let the server do it for you. ## Group chat -See [Group Chat](../groupchat/). +See [Group Chat](/implementation-guidelines/groupchat). ## Contact management ### Blocking -- [XEP-0191](https://xmpp.org/extensions/xep-0191.html) for blocking communication with a list of other JIDs +- [XEP-0191](/extensions/xep-0191.html) for blocking communication with a list of other JIDs ## Encryption @@ -346,7 +346,7 @@ the contents of exchanged messages, and is known as 'end-to-end encryption'. The current preferred protocol for this in XMPP is OMEMO, specified -in [XEP-0384](https://xmpp.org/extensions/xep-0384.html). Client support is indicated at . +in [XEP-0384](/extensions/xep-0384.html). Client support is indicated at [omemo.top](https://omemo.top/). ### Notes @@ -362,7 +362,7 @@ very well, nor group chats, and it only protects the message body. These issues lead to a poor user experience. -Modern XMPP clients that implement OTR must add a [XEP-0380](https://xmpp.org/extensions/xep-0380.html) tag to their outgoing +Modern XMPP clients that implement OTR must add a [XEP-0380](/extensions/xep-0380.html) tag to their outgoing messages. #### MLS diff --git a/content/implementation-guidelines/rationale.md b/content/implementation-guidelines/rationale.md index c37e15cd5..46286245e 100644 --- a/content/implementation-guidelines/rationale.md +++ b/content/implementation-guidelines/rationale.md @@ -8,7 +8,7 @@ in the Modern XMPP documentation are made. ## Group chats Discussion about the UI/UX issues around group chats initially happened -at the first [UX sprint](meetings/2019-01-brussels.md). Some observations +at the first [UX sprint](/implementation-guidelines/2019-01-brussels.md). Some observations were made: * MUC configuration is messy, for users and developers diff --git a/content/implementation-guidelines/sync.md b/content/implementation-guidelines/sync.md index f753a65dc..9fef15506 100644 --- a/content/implementation-guidelines/sync.md +++ b/content/implementation-guidelines/sync.md @@ -53,4 +53,4 @@ implementation recommendations for MAM. `end: && limit: X` -[MAM]: https://xmpp.org/extensions/xep-0313.html +[MAM]: /extensions/xep-0313.html diff --git a/content/implementation-guidelines/terminology.md b/content/implementation-guidelines/terminology.md index db7cc0d0d..0137a5c82 100644 --- a/content/implementation-guidelines/terminology.md +++ b/content/implementation-guidelines/terminology.md @@ -31,14 +31,14 @@ At the moment, this table intends to support discussing the translation of key t | Contact list | Kontaktliste | Liste de contacts | Lista de contactos | Lista de contactos | 連絡帳 | | Profile picture | Profilbild | | | | プロフィーロ写真 | -You’ll find more terms in the [term overview](/translation-discussion). +You’ll find more terms in the [term overview](/implementation-guidelines/translation-discussion). [Add a language...](https://github.com/modernxmpp/modernxmpp) -[^rationale-gc]: Rationale [group chat terminology](/rationale#terminology) +[^rationale-gc]: Rationale [group chat terminology](/implementation-guidelines/rationale#terminology) -[Multi-user Chats]: client/groupchat.md +[Multi-user Chats]: /implementation-guidelines/groupchat [^rationale-dev-terms]: General agreement is that this would only cause confusion, for little gain. See e.g. discussion at https://github.com/modernxmpp/modernxmpp/pull/23