Too loud, man

proposals/3032-presence-revamp.md

@@ -5,8 +5,7 @@ This is deliberately a loose-form, draft MSC to note down my current thoughts
 on how we might improve the presence system and integrate it with
 profiles-as-rooms (MSC1769).
 
-`PUT /_matrix/client/r0/presence/{userId}/status`
-=================================================
+## `PUT /_matrix/client/r0/presence/{userId}/status`
 `status_msg` becomes deprecated. In it's place there's a new state event in the
 user's MSC1769 profile room, `m.status`. It's not a field in the `m.profile`
 object because it's intended to be updated fairly frequently and we don't need
@@ -17,16 +16,14 @@ races).
 endpoint is explicitly for the *user* setting their presence manually, eg. selecting
 'busy' or 'unavailable' from a checkbox in the UI.
 
-`set_presence` in `/sync`
-=========================
+## `set_presence` in `/sync`
 This is differentiated from `PUT /_matrix/client/r0/presence/{userId}/status`
 by being explicitly for automatic updates from clients, eg.:
  * A client supplies `unavailable` if it doesn't believe the user is paying attention
    (eg. they haven't moved the mouse ina  while).
  * A client supplies `busy` if the user is on a call in that client.
 
-Effective presence
-==================
+## Effective presence
 The homeserver can then combine the multiple sources of presence information from
 the clients and the user-set value to determine an effective presence for the user.
 This is a black-box as far as the spec is concerned, but semantics will be along
@@ -35,8 +32,7 @@ the lines of 'if any status is busy, the user is busy`.
 Question: if a user sets themselves 'busy', what status do they set when they're
 free again? 'online'?
 
-Publishing presence
-===================
+## Publishing presence
 Homeservers take the effective presence and publish it as an `m.presence` state
 event in the user's profile room. You subscribe to a user's presence by peeking
 into their profile room.
@@ -48,12 +44,10 @@ Question: How would we restrict the set of people allowed to see presence
 Question: What happens if a user send an `m.presence`event to their profile room?
           Should they be allowed to?
 
-`GET /_matrix/client/r0/presence/{userId}/status`
-=================================================
+## `GET /_matrix/client/r0/presence/{userId}/status`
 Also goes away.
 
-Presence for the smartphone generation
-======================================
+## Presence for the smartphone generation
 The presence status enum was designed in a time when smartphones were relatively
 new and it was still assumed that if you weren't at your computer, you were
 unavailable. This isn't true now we all carry our computers in our pockets.