summary refs log tree commit diff
diff options
context:
space:
mode:
authorErik Johnston <erik@matrix.org>2014-10-03 14:50:08 +0100
committerErik Johnston <erik@matrix.org>2014-10-03 14:50:08 +0100
commit1fa04542882f48a6dca27b8ed54bf3e915beada0 (patch)
treeace6a57c262d97a1e290abf944472dbe4cb886a8
parentFlesh out room alias section. (diff)
parentClarify how m.room.alias event works (diff)
downloadsynapse-1fa04542882f48a6dca27b8ed54bf3e915beada0.tar.xz
Merge pull request #6 from matrix-org/paul/doc
Clarify how m.room.alias event works
-rw-r--r--docs/specification.rst30
1 files changed, 26 insertions, 4 deletions
diff --git a/docs/specification.rst b/docs/specification.rst
index e6b85dba33..f2e973de33 100644
--- a/docs/specification.rst
+++ b/docs/specification.rst
@@ -1358,10 +1358,32 @@ prefixed with ``m.``
   Example:
     ``{ "aliases": ["#foo:example.com"] }``
   Description:
-    A server `may` inform the room that it has added or removed an alias for
-    the room. This is purely for informational purposes and may become stale.
-    Clients `should` check that the room alias is still valid before using it.
-    The ``state_key`` of the event is the homeserver which owns the room alias.
+    This event is sent by a homeserver directly to inform of changes to the
+    list of aliases it knows about for that room. As a special-case, the
+    ``state_key`` of the event is the homeserver which owns the room alias.
+    For example, an event might look like::
+
+      {
+        "type": "m.room.aliases",
+        "event_id": "012345678ab",
+        "room_id": "!xAbCdEfG:example.com",
+        "state_key": "example.com",
+        "content": {
+          "aliases": ["#foo:example.com"]
+        }
+      }
+
+    The event contains the full list of aliases now stored by the home server
+    that emitted it; additions or deletions are not explicitly mentioned as
+    being such. The entire set of known aliases for the room is then the union
+    of the individual lists declared by all such keys, one from each home
+    server holding at least one alias.
+
+    Clients `should` check the validity of any room alias given in this list
+    before presenting it to the user as trusted fact. The lists given by this
+    event should be considered simply as advice on which aliases might exist,
+    for which the client can perform the lookup to confirm whether it receives
+    the correct room ID.
 
 ``m.room.message``
   Summary: