From 9702a427577c381932958fe006056a9b532f78f2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 5 May 2020 18:45:40 +0200 Subject: [PATCH] Accept inbox/room-activity-indicators.xml as XEP-0437 --- xep-0437.xml | 156 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 xep-0437.xml diff --git a/xep-0437.xml b/xep-0437.xml new file mode 100644 index 00000000..31558cd1 --- /dev/null +++ b/xep-0437.xml @@ -0,0 +1,156 @@ + + +%ents; +]> + + +
+ Room Activity Indicators + This specification describes a lightweight mechanism for activity notifications in MUCs + &LEGALNOTICE; + 0437 + Experimental + Standards Track + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + &mwild; + + 0.1.0 + 2020-05-05 + XEP Editor (jsc) + Accepted by vote of Council on 2020-04-15. + + + 0.0.1 + 2020-04-13 + mw +

First draft.

 + +
+ +

Sometimes it is desirable for a client to indicate to a user that +activity has occurred in a MUC, without the overhead of immediately +joining every MUC that the user has an interest in.

+ +

A MUC may already send out-of-band notifications to users who are not +currently joined if e.g. they are mentioned using &xep0372;. However a MUC +typically won't forward other kinds of messages unless the user is joined.

+ +

This protocol describes a lightweight mechanism for the client to display +an indication to the user that there are new messages in a room since the +last time the user was joined there. This can, for example, be used to provide +a UI hint that a room the user is interested in has new unread activity.

+ + + +
    +
  • A client must be able to receive an indication that activity has occurred in a room without joining it
    • +
  • The protocol must scale to a large number of rooms, while remaining simple to implement on the client and server
    • +
+ +

This protocol explicitly does not attempt to define:

+ +
    +
  • Usage with &xep0369; (MIX architecture is fundamentally different to MUC)
    • +
  • A means for the client/server to agree on which rooms the client should be subscribed to (it is assumed the server can + determine a suitable strategy itself, and that this strategy may be deployment-specific).
    • +
+ + + + +

To inform the MUC service that you are interested in receiving + activity indicators, send a presence to the service including the + <rai> element:

+ + + + +]]> + +

After sending this presence, the service may send you activity + indicator updates at any time, each one containing one or more + JIDs of MUC rooms that have new messages:

+ + + + room1@conference.example.com + room3@conference.example.com + + +]]> + +

Note that the service will **only** send notifications for rooms + where the client's session is not currently joined. If the client + is joined to a room, it already receives live events from the room directly.

+ + + + +

A client may unsubscribe from activity indicators by sending an unavailable presence + to the MUC service. This will typically be sent by the user's server automatically when + they go offline.

+ + + + +

Upon receiving a presence stanza addressed to the service JID that includes + a <rai xmlns="xmpp:prosody.im/protocol/rai"> element, the service should + build a list of rooms where activity has occurred since the client was + last in the room, and send them in a single notification.

+ +

When activity happens in a room, a service should send an activity notification + to room members who have subscribed to notifications and who have not already + received a notification for that room in their current subscription's lifetime.

+ +

A server SHOULD only send a single notification for each room where activity + has occured since the last time a given affiliated user was joined to a room. + Each room may only be notified once, even if many events occur while the client + is not present in the room. Therefore the client MUST NOT attempt to count activity + events. A single activity notification for a room means some unspecified number + of events have happened, receiving another activity notification for the same + room adds no further information.

+

A server MUST NOT send activity notifications to a user from a room that the user + would not be allowed to join. This potentially includes hidden rooms where the user + has no affiliation.

+ + + + +

This specification does not dictate how a server determines which rooms a client + should receive notifications for. The list may be large and varying.

+

For example, this information is available to the server through some other means, + or a server may simply subscribe a user to all rooms on the MUC service, or only to + rooms where a user has an affiliation.

+ + + + +

This specification is not expected to introduce any security concerns.

+

From a privacy perspective, a user's availability is exposed to the MUC service, but not + beyond what would be exposed if the user simply joined a room as normal.

+

Servers may place restrictions on who may subscribe to room activity notifications, e.g. + by only serving local users, or only permitting a sensible number of active subscriptions.

+

Servers must be careful not to leak room activity indicators to users who would not otherwise + have permission to view the content in the room.

+ + +

This document requires no interaction with &IANA;.

+ + +

This document requires no interaction with ®ISTRAR;.

+ + + +

REQUIRED for protocol specifications.

+ +