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

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