maxmustermann/synapse
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Re-wrap content after latest additions

Browse source
This commit is contained in:
Paul "LeoNerd" Evans 2014-09-29 18:40:15 +01:00
parent dca75a08ba
commit 1f76377a7c
1 changed files with 30 additions and 25 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

55
docs/specification.rst
View file

@ -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