Merge branch 'master' into push

drafts/general_api.rst

@@ -111,6 +111,7 @@ Global initial sync API ``[Draft]``
       - The invite event
       - Other state info (e.g. room name, topic, join_rules to know if pubilc)
       - # members?
+
     so clients know more information about the room other than the user_id of the
     inviter, timestamp and the room ID.
 
@@ -637,7 +638,7 @@ A client may wish to send multiple actions in parallel. The send event APIs
 support sending multiple events in a batch.
  
 Inviting a user ``[ONGOING]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 .. NOTE::
   - Clients need to know *why* they are being invited (e.g. a ``reason`` key,
     just like for kicks/bans). However, this opens up a spam vector where any
@@ -1028,8 +1029,8 @@ relate to other events are referred to as "Child Events". The event being
 related to is referred to as "Parent Events". Child events cannot stand alone as
 a separate entity; they require the parent event in order to make sense.
 
-Bundling
+Bundling updates
-++++++++
+++++++++++++++++
 Events that relate to another event should come down inside that event. That is,
 the top-level event should come down with all the child events at the same time.
 This is called a "bundle" and it is represented as an array of events inside the
@@ -1081,8 +1082,8 @@ not update the event itself*, and are *not required* in order to display the
 parent event. Crucially, the child events can be paginated, whereas ``updates`` 
 child events cannot be paginated.
 
-Bundling
+Bundling relations
-++++++++
+++++++++++++++++++
 Child events can be optionally bundled with the parent event, depending on your 
 display mechanism. The number of child events which can be bundled should be 
 limited to prevent events becoming too large. This limit should be set by the 

drafts/model/profiles.rst

@@ -198,12 +198,11 @@ Requests that a client can make to its Home Server
 
  * get another user's Display Name / Avatar / metadata fields
 
-[[TODO(paul): At some later stage we should consider the API for:
+TODO(paul): At some later stage we should consider the API for:
 
  * get/set ACL permissions on my metadata fields
 
  * manage my ACL tokens
-]]
 
 Server-Server
 -------------

drafts/model/protocol_examples.rst

@@ -3,7 +3,9 @@ Host: ...
 Content-Length: ...
 Content-Type: application/json
 
-{
+.. code :: javascript
+
+  {
     "origin": "localhost:5000",
     "pdus": [
         {
@@ -27,7 +29,7 @@ Content-Type: application/json
         "1404381396852"
     ],
     "ts": 1404381427823
-}
+  }
 
 HTTP/1.1 200 OK
 ...
@@ -42,7 +44,9 @@ HTTP/1.1 200 OK
 Content-Length: ...
 Content-Type: application/json
 
-{
+.. code :: javascript
+
+  {
     origin: ...,
     prev_ids: ...,
     data: [
@@ -59,6 +63,6 @@ Content-Type: application/json
         },
         ...,
     ]
-}
+  }
 
 

drafts/model/rooms.rst

@@ -125,12 +125,13 @@ m.invite_level
 m.join_rules
   Encodes the rules on how non-members can join the room. Has the following
   possibilities:
-    "public" - a non-member can join the room directly
+
-    "knock" - a non-member cannot join the room, but can post a single "knock"
+    - "public" - a non-member can join the room directly
+    - "knock" - a non-member cannot join the room, but can post a single "knock"
       message requesting access, which existing members may approve or deny
-    "invite" - non-members cannot join the room without an invite from an
+    - "invite" - non-members cannot join the room without an invite from an
       existing member
-    "private" - nobody who is not in the 'may_join' list or already a member
+    - "private" - nobody who is not in the 'may_join' list or already a member
       may join by any mechanism
 
   In any of the first three modes, existing members with sufficient permission
@@ -263,9 +264,10 @@ resolve this:
    that duplicate requests can be suppressed. On receipt of a room creation
    request that the HS thinks there already exists a room for, the invitation to
    join can be rejected if:
-      a) the HS believes the sending user is already a member of the room (and
+
+      - a) the HS believes the sending user is already a member of the room (and
         maybe their HS has forgotten this fact), or
-      b) the proposed room has a lexicographically-higher ID than the existing
+      - b) the proposed room has a lexicographically-higher ID than the existing
         room (to resolve true race condition conflicts)
       
  * The room ID for a private 1:1 chat has a special form, determined by

drafts/state_resolution.rst

@@ -27,6 +27,7 @@ all state events eventually.
 Algorithm requirements
 ----------------------
 We want the algorithm to have the following properties:
+
 - Since we aren't guaranteed what order we receive state events in, except that
   we see parents before children, the state resolution algorithm must not depend
   on the order and must always come to the same result. 

drafts/use_cases.rst

@@ -268,6 +268,7 @@ Chat Screen
  What's visible:
   - Enough scrollback to fill a "screen full" of content.
   - Threads:
+
     - Initially will only display the timestamp and user ID of the *first*
       message. But can expand to show the entire tree.
     - Tree of messages indicating which message is a reply to which.
@@ -280,6 +281,7 @@ Chat Screen
   - Desktop/Push Notifications for messages
  What you can do:
   - Send a message in reply to another message:
+
     - Immediate local echo, may cause messages to re-order
     - Messages that haven't reached the server are queued.
     - Thread is displayed where it should be in the thread order once the
@@ -303,6 +305,7 @@ Chat Screen
       +------------+ | * A2 -> A1     | | * B2 -> B1   |
                      | * M -> A2, B2  | +--------------+
                      +----------------+
+
   - Typing notifications. Displayed within the correct thread/column.
 
  What you can do: