Start converting the presence module. Add Rationale admonition.

scripts/nature.css

@@ -282,3 +282,9 @@ td[colspan]:not([colspan="1"]) {
 thead {
     background: #eeeeee;
 }
+
+div.admonition-rationale {
+    background-color: #efe;
+    border: 1px solid #ccc;
+}
+

specification/1-client_server_api.rst

@@ -1092,6 +1092,27 @@ Profiles
 
 {{profile_http_api}}
 
+Events on Change of Profile Information
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Because the profile display name and avatar information are likely to be used in
+many places of a client's display, changes to these fields cause an automatic
+propagation event to occur, informing likely-interested parties of the new
+values. This change is conveyed using two separate mechanisms:
+
+ - a ``m.room.member`` event is sent to every room the user is a member of,
+   to update the ``displayname`` and ``avatar_url``.
+ - a ``m.presence`` presence status update is sent, again containing the new
+   values of the ``displayname`` and ``avatar_url`` keys, in addition to the
+   required ``presence`` key containing the current presence state of the user.
+
+Both of these should be done automatically by the home server when a user
+successfully changes their display name or avatar URL fields.
+
+Additionally, when home servers emit room membership events for their own
+users, they should include the display name and avatar URL fields in these
+events so that clients already have these details to hand, and do not have to
+perform extra round trips to query it.
+
 Security
 --------
 

specification/modules/presence.rst

@@ -1,63 +1,89 @@
 Presence
 ========
  
-Each user has the concept of presence information. This encodes the
+Each user has presence information associated with them. This encodes the
-"availability" of that user, suitable for display on other user's clients.
+"availability" of that user, suitable for display on other clients.
 This is transmitted as an ``m.presence`` event and is one of the few events
-which are sent *outside the context of a room*. The basic piece of presence
+which are sent *outside the context of a room*. Their presence state is
-information is represented by the ``presence`` key, which is an enum of one
+represented by the ``presence`` key, which is an enum of one of the following:
-of the following:
 
       - ``online`` : The default state when the user is connected to an event
         stream.
-      - ``unavailable`` : The user is not reachable at this time.
+      - ``unavailable`` : The user is not reachable at this time e.g. they are
-      - ``offline`` : The user is not connected to an event stream.
+        idle.
+      - ``offline`` : The user is not connected to an event stream or is
+        explicitly suppressing their profile information from being sent.
       - ``free_for_chat`` : The user is generally willing to receive messages
         moreso than default.
-      - ``hidden`` : Behaves as offline, but allows the user to see the client
-        state anyway and generally interact with client features. (Not yet
-        implemented in synapse).
-
-In addition, the server maintains a timestamp of the last time it saw a
-pro-active event from the user; either sending a message to a room, or
-changing presence state from a lower to a higher level of availability
-(thus: changing state from ``unavailable`` to ``online`` counts as a
-proactive event, whereas in the other direction it will not). This timestamp
-is presented via a key called ``last_active_ago``, which gives the relative
-number of milliseconds since the message is generated/emitted that the user
-was last seen active.
 
 Events
 ------
 
 {{presence_events}}
 
-Presence HTTP API
+Client behaviour
------------------
+----------------
-.. TODO-spec
+
-  - Define how users receive presence invites, and how they accept/decline them
+Clients can manually set/get their presence using the HTTP APIs listed below.
 
 {{presence_http_api}}
 
+Idle timeout
+~~~~~~~~~~~~
+
+Clients SHOULD implement an "idle timeout". This is a timer which fires after
+a period of inactivity on the client. The definition of inactivity varies
+depending on the client. For example, web implementations may determine
+inactivity to be not moving the mouse for a certain period of time. When this
+timer fires it should set the presence state to ``unavailable``. When the user
+becomes active again (e.g. by moving the mouse) the client should set the
+presence state to ``online``. A timeout value between 1 and 5 minutes is
+recommended. 
+
+Server behaviour
+----------------
+
+Propagating profile information
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Events on Change of Profile Information
----------------------------------------
 Because the profile display name and avatar information are likely to be used in
-many places of a client's display, changes to these fields cause an automatic
+many places of a client's display, changes to these fields SHOULD cause an
-propagation event to occur, informing likely-interested parties of the new
+automatic propagation event to occur, informing likely-interested parties of the
-values. This change is conveyed using two separate mechanisms:
+new values. One of these change mechanisms SHOULD be via ``m.presence`` events.
-
+These events should set ``displayname`` and ``avatar_url`` to the new values
- - a ``m.room.member`` event is sent to every room the user is a member of,
+along with the presence-specific keys. This SHOULD be done automatically by the
-   to update the ``displayname`` and ``avatar_url``.
+home server when a user successfully changes their display name or avatar URL.
- - a ``m.presence`` presence status update is sent, again containing the new values of the
+
-   ``displayname`` and ``avatar_url`` keys, in addition to the required
+.. admonition:: Rationale
-   ``presence`` key containing the current presence state of the user.
+
-
+  The intention for sending this information in ``m.presence`` is so that any
-Both of these should be done automatically by the home server when a user
+  "user list" can display the *current* name/presence for a user ID outside the
-successfully changes their displayname or avatar URL fields.
+  scope of a room (e.g. a user page which has a "start conversation" button).
-
+  This is bundled into a single event to avoid "flickering" on this page which
-Additionally, when home servers emit room membership events for their own
+  can occur if you received presence first and then display name later (the
-users, they should include the displayname and avatar URL fields in these
+  user's name would flicker from their user ID to the display name).
-events so that clients already have these details to hand, and do not have to
+
-perform extra roundtrips to query it.
+
+Last active ago
+~~~~~~~~~~~~~~~
+The server maintains a timestamp of the last time it saw a
+pro-active event from the user. A pro-active event may be sending a message to a
+room or changing presence state to a higher level of availability. Levels of
+availability are defined from low to high as follows:
+
+      - ``offline``
+      - ``unavailable``
+      - ``online``
+      - ``free_for_chat``
+
+Based on this list, changing state from ``unavailable`` to ``online`` counts as
+a pro-active event, whereas ``online`` to ``unavailable`` does not. This
+timestamp is presented via a key called ``last_active_ago`` which gives the
+relative number of milliseconds since the pro-active event.
+
+Security considerations
+-----------------------
+    
+Presence information is shared with all users who share a room with the target
+user. In large public rooms this could be undesirable.