Use title heading sizings of =,-,~,+ since that is what most of our docs use. Inconsistent use breaks when you try to merge them.
This commit is contained in:
parent
5279541c28
commit
109c8a97a8
2 changed files with 11 additions and 11 deletions
|
@ -134,7 +134,7 @@ federate with other HSes. It is typically responsible for multiple clients.
|
||||||
more home servers.
|
more home servers.
|
||||||
|
|
||||||
Events
|
Events
|
||||||
++++++
|
~~~~~~
|
||||||
|
|
||||||
Data in Matrix is encapsulated in an "event". An event is an action within the
|
Data in Matrix is encapsulated in an "event". An event is an action within the
|
||||||
system. Typically each action (e.g. sending a message) correlates with exactly
|
system. Typically each action (e.g. sending a message) correlates with exactly
|
||||||
|
@ -148,7 +148,7 @@ is the event type for instant messages. Events are usually sent in the context
|
||||||
of a "Room".
|
of a "Room".
|
||||||
|
|
||||||
Event Graphs
|
Event Graphs
|
||||||
++++++++++++
|
~~~~~~~~~~~~
|
||||||
|
|
||||||
Each event has a list of zero or more `parent` events. These relations form
|
Each event has a list of zero or more `parent` events. These relations form
|
||||||
directed acyclic graphs of events called `event graphs`. Every event graph has a single root event, and each event graph forms the
|
directed acyclic graphs of events called `event graphs`. Every event graph has a single root event, and each event graph forms the
|
||||||
|
@ -247,7 +247,7 @@ participating in a room.
|
||||||
|
|
||||||
|
|
||||||
Room Aliases
|
Room Aliases
|
||||||
~~~~~~~~~~~~
|
++++++++++++
|
||||||
|
|
||||||
Each room can also have multiple "Room Aliases", which looks like::
|
Each room can also have multiple "Room Aliases", which looks like::
|
||||||
|
|
||||||
|
@ -282,7 +282,7 @@ that are in the room that can be used to join via.
|
||||||
|________________________________|
|
|________________________________|
|
||||||
|
|
||||||
Identity
|
Identity
|
||||||
~~~~~~~~
|
++++++++
|
||||||
|
|
||||||
Users in Matrix are identified via their matrix user ID (MXID). However,
|
Users in Matrix are identified via their matrix user ID (MXID). However,
|
||||||
existing 3rd party ID namespaces can also be used in order to identify Matrix
|
existing 3rd party ID namespaces can also be used in order to identify Matrix
|
||||||
|
@ -303,7 +303,7 @@ the Matrix ecosystem. However, without one clients will not be able to look up
|
||||||
user IDs using 3PIDs.
|
user IDs using 3PIDs.
|
||||||
|
|
||||||
Presence
|
Presence
|
||||||
~~~~~~~~
|
++++++++
|
||||||
|
|
||||||
Each user has the concept of presence information. This encodes the
|
Each user has the concept of presence information. This encodes the
|
||||||
"availability" of that user, suitable for display on other user's clients. This
|
"availability" of that user, suitable for display on other user's clients. This
|
||||||
|
@ -343,7 +343,7 @@ the other direction it will not). This timestamp is presented via a key called
|
||||||
message is generated/emitted that the user was last seen active.
|
message is generated/emitted that the user was last seen active.
|
||||||
|
|
||||||
Presence List
|
Presence List
|
||||||
+++++++++++++
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
Each user's home server stores a "presence list". This stores a list of user IDs
|
Each user's home server stores a "presence list". This stores a list of user IDs
|
||||||
whose presence the user wants to follow.
|
whose presence the user wants to follow.
|
||||||
|
@ -353,7 +353,7 @@ and accept the invitation. Once accepted, both user's HSes track the
|
||||||
subscription.
|
subscription.
|
||||||
|
|
||||||
Presence and Permissions
|
Presence and Permissions
|
||||||
++++++++++++++++++++++++
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
For a viewing user to be allowed to see the presence information of a target
|
For a viewing user to be allowed to see the presence information of a target
|
||||||
user, either:
|
user, either:
|
||||||
|
@ -367,7 +367,7 @@ presence information in a user list for a room.
|
||||||
|
|
||||||
|
|
||||||
Profiles
|
Profiles
|
||||||
~~~~~~~~
|
++++++++
|
||||||
|
|
||||||
.. TODO-spec
|
.. TODO-spec
|
||||||
- Metadata extensibility
|
- Metadata extensibility
|
||||||
|
|
|
@ -38,7 +38,7 @@ using this representation.
|
||||||
).encode("UTF-8")
|
).encode("UTF-8")
|
||||||
|
|
||||||
Grammar
|
Grammar
|
||||||
+++++++
|
~~~~~~~
|
||||||
|
|
||||||
Adapted from the grammar in http://tools.ietf.org/html/rfc7159 removing
|
Adapted from the grammar in http://tools.ietf.org/html/rfc7159 removing
|
||||||
insignificant whitespace, fractions, exponents and redundant character escapes
|
insignificant whitespace, fractions, exponents and redundant character escapes
|
||||||
|
@ -76,7 +76,7 @@ the signature for that sequence and then adding the signature to the original
|
||||||
JSON object.
|
JSON object.
|
||||||
|
|
||||||
Signing Details
|
Signing Details
|
||||||
+++++++++++++++
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
JSON is signed by encoding the JSON object without ``signatures`` or keys grouped
|
JSON is signed by encoding the JSON object without ``signatures`` or keys grouped
|
||||||
as ``unsigned``, using the canonical encoding described above. The JSON bytes are then signed using the
|
as ``unsigned``, using the canonical encoding described above. The JSON bytes are then signed using the
|
||||||
|
@ -133,7 +133,7 @@ and additional signatures.
|
||||||
return json_object
|
return json_object
|
||||||
|
|
||||||
Checking for a Signature
|
Checking for a Signature
|
||||||
++++++++++++++++++++++++
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
To check if an entity has signed a JSON object a server does the following
|
To check if an entity has signed a JSON object a server does the following
|
||||||
|
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue