diff --git a/inbox/muc2-addressing-occupancy.xml b/inbox/muc2-addressing-occupancy.xml new file mode 100644 index 000000000..0e07432fb --- /dev/null +++ b/inbox/muc2-addressing-occupancy.xml @@ -0,0 +1,199 @@ + + +%ents; + + +]> + + +
+ New MUC: Addressing and Occupancy + This document specifies an enhanced Multi-User Chat protocol that is broadly backwards compatible with that of XEP-0045, but adds a number of key improvements. + &LEGALNOTICE; + XXXX + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + MUC2-Addr + &dcridland; + + 0.1 + 2026-05-06 + dwd + Second Attempt + +
+ +

In the beginning was IRC. And we saw IRC, and made GC. And then MUC. And we looked upon them, and saw they were not good. But we used MUC for 25 years, so it must be pretty good for all that.

+

We also made MIX, but MIX has not seen adoption.

+

This is an attempt at addressing some of the shortcomings of &xep0045; (herein "MUC1"), but it is phrased as extensions to MUC1 rather than a whole new protocol.

+

This document only discusses the addressing of occupants in MUC2 rooms, and how to join MUC2 rooms.

+ + + +

Whenever a client joins a room, they start an "occupancy session". There can also be an occupancy session for their bare JID, which is independent of any client session. If at least one occupancy session exists, the room will contain an occupant JID, and the user will be considered an occupant of the room for all purposes.

+

Presence-based occupancy sessions are ephemeral for a given client session, and will not persist beyond that. This is the only type supported by &xep0045;, and these are highly suitable for many use-cases. Currently, these are also the only way for a client to obtain a continuous stream of messages and other events from a room.

+

Bare jid occupancy sessions persist across sessions and server restarts. While limited in this specification, they form the basis for advanced features such as "inbox" functionality, push notifications, and other cases where the user's server is required to have visibility of the message data even when the user is offline. Note that bare jid occupancy is distinct from affiliations entirely.

+ + +

In MUC2, occupants are addressed by a JID consisting of the room's bare JID (see &xep0045;) and an occupant-id (see &xep0421;) as resource. This requires that in MUC2, servers MUST provide an occupant-id, and furthermore that servers MUST use an occupant-id generation algorithm that results in a valid resource.

+

MUC2 rooms MUST include the nickname within presence as a nickname element qualified by the urn:xmpp:muc:0 namespace within the usual &X;. Explicit inclusion of the &xep0421; element is not needed in the presence sent to MUC2 sessions, and advertising support for &xep0421; is therefore not required for "pure" MUC2.

+ +

If compatibility with MUC1 is required, note the following:

+

A client joining via MUC1's presence-based joins will not see these occupant-id based addresses, but instead sees the nickname-based addressing. This implies that MUC1 and MUC2 clients will see different addresses for the same occupant simultaneously.

+

Servers SHOULD use the same occupant-id for both MUC1 and MUC2. That is, it is RECOMMENDED that the resource string of a MUC2 occupant precisely match the occupant-id given by &xep0421; - it is expected that &xep0421; will be supported for MUC1 sessions, and if so it MUST be advertised

+

In addition, MUC1 nicknames MUST NOT be allowed to clash with occupant-ids, and as such, servers SHOULD prefix the occupant-id used in the resource with some prefix, such as "-", to enforce this. This prefix is then rejected as (part of) a nickname.

+ + + + + Bastanio + + + ]]> + + +

Joining a MUC1 room can be done with (relatively) simple presence. MUC2, as well, can be done this way, though this will not automatically create a bare JID occupancy session. To do so, the same joining presence stanza is used, but the &X; element includes a muc2 element qualified by the &NSMUC2; namespace, and the presence is normally sent to the bare JID. This will indicate to the room that MUC2 is expected, and will cause the occupancy session to be a MUC2 session.

+ + + + + Bastiano + + + + ]]> +

For compatibility with MUC1, and to avoid explicit discovery, this joining presence MAY be sent to an arbitrary resource (typically, the user's requested nickname) of the room's bare JID. The factor that makes the room treat the join as a MUC2 join is the presence of the <muc2/> element with the &NSMUC2; namespace - a MUC1 room will then execute a MUC1 style join, a MUC2 room will execute a MUC2 join:

+ + + + Bastiano + + + + ]]> +

The sequence of joining either type of room is broadly identical. The differences are listed in the following sections:

+ + +
    +
  1. Existing Occupant Presence to a MUC1 client MUST include all occupants, addressed by nickname, including those bare JID occupants that are not online. These latter MUST be normal (available) presence, and SHOULD be annotated with a &xep0310; annotation to indicate they are not online. Servers MAY also override a <show/> to 'xa', to indicate their absence.
    2. +
  2. Existing Occupant Presence to a MUC2 client also includes all occupants, but this time addressed by occupant-id, and shows bare JID occupants that are not online as offline presence.
    3. +
  3. Servers MAY include a delay tag in presence for either join to indicate when the presence state last changed.
    4. +
+ + +

Many MUC2 clients will not want this feature - but it can be trivially turned off in the usual manner. MUC2 rooms MUST implement MAM, as defined in &xep0313;.

+ + +

If a MUC1 client is joining, this will be as normal. For MUC2 clients, this will also include an additional element giving the MAM summary <metadata/> of the room, defined in &xep0313; section 5.

+ + Boring subject + + + 1609459200 + 1609459200 + 10 + + + + ]]> + + + +

In order to handle the offline case, an iq-based joining protocol is also included. Clients joining the room in this way essentially request to be visible as an occupant (subject to the room's configuration), and also to receive messages to their bare JIDs. Groupchat messages sent to bare JIDs do not get sent to clients, and, in an unextended server, are bounced with a <service-unavailable/> error. Therefore clients MUST first establish if their server has MUC2-PAM support; if it does not, they MUST avoid this mechanism and use presence-based joins instead.

+

MUC2 rooms MUST send all messages to all occupancy sessions, including bare jid occupancy sessions. Messages to the MUC room MUST be accepted from all occupants, irrespective of whether they're presence-based occupancy sessions or bare jid occupancy sessions, and regardless of

+ +

To advertise support for handling bare jid occupancy sessions, the user's server MUST include a &xep0030; feature of &NSMUC2PAM;.

+ + +

Bare JIDs join the room with an &IQ; request sent by the user's server from the user's bare jid to the room's bare JID of type "set", containing a join element within the namespace &NSMUC2;, containing a nickname element. The room processes this, sending the room's current subject in the same way as a join - containing the MAM summary metadata as per &xep0313; section 5 - and respond with an &IQ; of type result which reflects the join element within &NSMUC2; also containing the nickname element. This allows the room to assign a different nickname as needed. Note that an iq-based join from a full jid (ie, one with a resource) MUST be rejected.

+

To trigger this, a client performs an iq-set request to their own bare JID, with a join element, this time with a "room" attribute containing the bare JID of the room, and containing a <nickname/>. The client will receive a response containing the same join element with the nickname element, once the join is complete.

+ + + + + nickname + + + + + + nickname + + + + + Boring subject + + + 1609459200 + 1609459200 + 10 + + + + + + + nickname + + + + + + + nickname + + + ]]> + + + +

Leaving a room is performed by a similar sequence, this time using a <part/> element:

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

IM servers support the server-side component of MUC2 by:

+
    +
  1. Including urn:xmpp:muc:pam:0 in the service discovery features on the bare jid and server's own domain.
    2. +
  2. Not bouncing groupchat messages to the bare jid. (Meaning, do not return an error to the sender for message stanzas of type groupchat sent to the bare jid). Note that there is no fan-out either - messages are essentially ignored in this base specification.
    3. +
  3. Responding to a &IQ; request to join or leave the room by sending one of their own to the room, as above.
    4. +
+

This is (deliberately) a minimalist base, but given this base, other features can be added.

+ + + + \ No newline at end of file