diff --git a/inbox/room-activity-indicators.xml b/inbox/room-activity-indicators.xml
new file mode 100644
index 00000000..8a4e3845
--- /dev/null
+++ b/inbox/room-activity-indicators.xml
@@ -0,0 +1,150 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE xep SYSTEM 'xep.dtd' [
+  <!ENTITY % ents SYSTEM 'xep.ent'>
+%ents;
+]>
+<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
+<xep>
+<header>
+  <title>Room Activity Indicators</title>
+  <abstract>This specification describes a lightweight mechanism for activity notifications in MUCs</abstract>
+  &LEGALNOTICE;
+  <number>xxxx</number>
+  <status>ProtoXEP</status>
+  <type>Standards Track</type>
+  <sig>Standards</sig>
+  <approver>Council</approver>
+  <dependencies>
+    <spec>XMPP Core</spec>
+  </dependencies>
+  <supersedes/>
+  <supersededby/>
+  <shortname>NOT_YET_ASSIGNED</shortname>
+  &mwild;
+  <revision>
+    <version>0.0.1</version>
+    <date>2020-04-13</date>
+    <initials>mw</initials>
+    <remark><p>First draft.</p></remark>
+  </revision>
+</header>
+<section1 topic='Introduction' anchor='intro'>
+  <p>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.</p>
+
+  <p>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.</p>
+
+  <p>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.</p>
+</section1>
+
+<section1 topic='Requirements' anchor='reqs'>
+  <ul>
+    <li>A client must be able to receive an indication that activity has occurred in a room without joining it</li>
+    <li>The protocol must scale to a large number of rooms, while remaining simple to implement on the client and server</li>
+  </ul>
+
+  <p>This protocol explicitly does not attempt to define:</p>
+
+  <ul>
+    <li>Usage with &xep0369; (MIX architecture is fundamentally different to MUC)</li>
+    <li>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).</li>
+  </ul>
+</section1>
+
+<section1 topic='Use Cases' anchor='usecases'>
+  <section2 topic='Client subscribes to activity indicators'>
+    <p>To inform the MUC service that you are interested in receiving
+       activity indicators, send a presence to the service including the
+       &lt;rai&gt; element:</p>
+
+      <example caption='Client subscribes to activity indicators'><![CDATA[
+<presence to="conference.example.com" id="dwZ3vL">
+  <rai xmlns="xmpp:prosody.im/protocol/rai"/>
+</presence>
+]]></example>
+
+    <p>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:</p>
+
+      <example caption='Server notifies client of room activity'><![CDATA[
+<message from="conference.example.com">
+  <rai xmlns="xmpp:prosody.im/protocol/rai">
+    <activity>room1@conference.example.com</activity>
+    <activity>room3@conference.example.com</activity>
+  </rai>
+</message>
+]]></example>
+
+    <p>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.</p>
+
+  </section2>
+
+  <section2 topic='Client unsubscribes from activity indicators'>
+    <p>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.</p>
+  </section2>
+</section1>
+
+<section1 topic='Business Rules' anchor='rules'>
+  <p>Upon receiving a presence stanza addressed to the service JID that includes
+     a &lt;rai xmlns="xmpp:prosody.im/protocol/rai"&gt; 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.</p>
+
+  <p>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.</p>
+
+  <p>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.</p>
+  <p>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.</p>
+</section1>
+
+<section1 topic='Implementation Notes' anchor='impl'>
+  <section2 topic='Determining the list of rooms'>
+    <p>This specification does not dictate how a server determines which rooms a client
+       should receive notifications for. The list may be large and varying.</p>
+    <p>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.</p>
+  </section2>
+</section1>
+
+<section1 topic='Security Considerations' anchor='security'>
+  <p>This specification is not expected to introduce any security concerns.</p>
+  <p>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.</p>
+  <p>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.</p>
+  <p>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.</p>
+</section1>
+<section1 topic='IANA Considerations' anchor='iana'>
+  <p>This document requires no interaction with &IANA;.</p>
+</section1>
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
+  <p>This document requires no interaction with &REGISTRAR;.</p>
+</section1>
+
+<section1 topic='XML Schema' anchor='schema'>
+  <p>REQUIRED for protocol specifications.</p>
+</section1>
+</xep>