diff options
author | Matthew Hodgson <matthew@matrix.org> | 2014-08-14 18:58:01 +0100 |
---|---|---|
committer | Matthew Hodgson <matthew@matrix.org> | 2014-08-14 18:58:01 +0100 |
commit | 7a025d63687e43c96532f69860c68ee6c19543ba (patch) | |
tree | 88770342e4c954ee8a2d64ff07029dbf4b56ea64 /docs/server-server/specification.rst | |
parent | manual syutil (diff) | |
download | synapse-7a025d63687e43c96532f69860c68ee6c19543ba.tar.xz |
It's called Matrix :)
Diffstat (limited to '')
-rw-r--r-- | docs/server-server/specification.rst | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/docs/server-server/specification.rst b/docs/server-server/specification.rst index 5a1f28745c..a9ab9bff66 100644 --- a/docs/server-server/specification.rst +++ b/docs/server-server/specification.rst @@ -1,8 +1,8 @@ -============================ -Synapse Server-to-Server API -============================ +=========================== +Matrix Server-to-Server API +=========================== -A description of the protocol used to communicate between Synapse home servers; +A description of the protocol used to communicate between Matrix home servers; also known as Federation. @@ -10,7 +10,7 @@ Overview ======== The server-server API is a mechanism by which two home servers can exchange -Synapse event messages, both as a real-time push of current events, and as a +Matrix event messages, both as a real-time push of current events, and as a historic fetching mechanism to synchronise past history for clients to view. It uses HTTP connections between each pair of servers involved as the underlying transport. Messages are exchanged between servers in real-time by active pushing @@ -19,7 +19,7 @@ historic data for the purpose of back-filling scrollback buffers and the like can also be performed. - { Synapse entities } { Synapse entities } + { Matrix clients } { Matrix clients } ^ | ^ | | events | | events | | V | V @@ -64,10 +64,10 @@ top-level element, passed over an HTTP PUT request. A Transaction is meaningful only to the pair of home servers that exchanged it; they are not globally- meaningful. -Each transaction has an opaque ID and timestamp (UNIX epoch time in miliseconds) -generated by its origin server, an origin and destination server name, a list of -"previous IDs", and a list of PDUs - the actual message payload that the -Transaction carries. +Each transaction has an opaque ID and timestamp (UNIX epoch time in +milliseconds) generated by its origin server, an origin and destination server +name, a list of "previous IDs", and a list of PDUs - the actual message payload +that the Transaction carries. {"transaction_id":"916d630ea616342b42e98a3be0b74113", "ts":1404835423000, @@ -114,7 +114,7 @@ field of a PDU refers to PDUs that any origin server has sent, rather than previous IDs that this origin has sent. This list may refer to other PDUs sent by the same origin as the current one, or other origins. -Because of the distributed nature of participants in a Synapse conversation, it +Because of the distributed nature of participants in a Matrix conversation, it is impossible to establish a globally-consistent total ordering on the events. However, by annotating each outbound PDU at its origin with IDs of other PDUs it has received, a partial ordering can be constructed allowing causallity |