diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/specification.rst | 55 |
1 files changed, 30 insertions, 25 deletions
diff --git a/docs/specification.rst b/docs/specification.rst index 23b6bed764..07c57f9dda 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -78,9 +78,10 @@ The functionality that Matrix provides includes: + Mapping of 3PIDs to Matrix IDs The end goal of Matrix is to be a ubiquitous messaging layer for synchronising -arbitrary data between sets of people, devices and services - be that for instant -messages, VoIP call setups, or any other objects that need to be reliably and -persistently pushed from A to B in an interoperable and federated manner. +arbitrary data between sets of people, devices and services - be that for +instant messages, VoIP call setups, or any other objects that need to be +reliably and persistently pushed from A to B in an interoperable and federated +manner. Architecture @@ -1120,8 +1121,8 @@ There are several APIs provided to ``GET`` events for a room: |/rooms/<room_id>/initialSync|_ Description: - Get all relevant events for a room. This includes state events, paginated non-state - events and presence events. + Get all relevant events for a room. This includes state events, paginated + non-state events and presence events. Response format: `` { TODO } `` Example: @@ -1129,20 +1130,22 @@ There are several APIs provided to ``GET`` events for a room: Redactions ---------- -Since events are extensible it is possible for malicious users and/or servers to add -keys that are, for example offensive or illegal. Since some events cannot be simply -deleted, e.g. membership events, we instead 'redact' events. This involves removing -all keys from an event that are not required by the protocol. This stripped down -event is thereafter returned anytime a client or remote server requests it. +Since events are extensible it is possible for malicious users and/or servers +to add keys that are, for example offensive or illegal. Since some events +cannot be simply deleted, e.g. membership events, we instead 'redact' events. +This involves removing all keys from an event that are not required by the +protocol. This stripped down event is thereafter returned anytime a client or +remote server requests it. -Events that have been redacted include a ``redacted_because`` key whose value is the -event that caused it to be redacted, which may include a reason. +Events that have been redacted include a ``redacted_because`` key whose value +is the event that caused it to be redacted, which may include a reason. -Redacting an event cannot be undone, allowing server owners to delete the offending -content from the databases. +Redacting an event cannot be undone, allowing server owners to delete the +offending content from the databases. -Currently, only room admins can redact events by sending a ``m.room.redacted`` event, -but server admins also need to be able to redact events by a similar mechanism. +Currently, only room admins can redact events by sending a ``m.room.redacted`` +event, but server admins also need to be able to redact events by a similar +mechanism. Room Events @@ -1346,13 +1349,15 @@ prefixed with ``m.`` JSON format: ``{ "reason": "string" }`` Description: - Events can be redacted by either room or server admins. Redacting an event means that - all keys not required by the protocol are stripped off, allowing admins to remove - offensive or illegal content that may have been attached to any event. This cannot be - undone, allowing server owners to physically delete the offending data. - There is also a concept of a moderator hiding a non-state event, which can be undone, - but cannot be applied to state events. - The event that has been redacted is specified in the ``redacts`` event level key. + Events can be redacted by either room or server admins. Redacting an event + means that all keys not required by the protocol are stripped off, allowing + admins to remove offensive or illegal content that may have been attached + to any event. This cannot be undone, allowing server owners to physically + delete the offending data. There is also a concept of a moderator hiding a + non-state event, which can be undone, but cannot be applied to state + events. + The event that has been redacted is specified in the ``redacts`` event + level key. m.room.message msgtypes ----------------------- @@ -1731,8 +1736,8 @@ There are three main kinds of communication that occur between home servers: These are single request/response interactions between a given pair of servers, initiated by one side sending an HTTPS GET request to obtain some information, and responded by the other. They are not persisted and contain - no long-term significant history. They simply request a snapshot state at the - instant the query is made. + no long-term significant history. They simply request a snapshot state at + the instant the query is made. :Ephemeral Data Units (EDUs): These are notifications of events that are pushed from one home server to |