wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Merge pull request #2562 from matrix-org/travis/spec/2432-alias-semantics

Browse source 
Add spec for new alias handling (client-server)
This commit is contained in:
Travis Ralston 2020-05-26 13:04:32 -06:00 • committed by GitHub
commit c3289614da
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
10 changed files with 144 additions and 63 deletions
Download patch file Download diff file Expand all files Collapse all files

29
specification/client_server_api.rst
View file

@ -1614,8 +1614,6 @@ Room Events
This specification outlines several standard event types, all of which are
prefixed with ``m.``
{{m_room_aliases_event}}
{{m_room_canonical_alias_event}}
{{m_room_create_event}}
@ -1628,6 +1626,15 @@ prefixed with ``m.``
{{m_room_redaction_event}}
Historical events
+++++++++++++++++
Some events within the ``m.`` namespace might appear in rooms, however they
serve no significant meaning in this version of the specification. They are:
* ``m.room.aliases``
Previous versions of the specification have more information on these events.
Syncing
~~~~~~~
@ -1891,15 +1898,15 @@ send update requests to other servers. However, homeservers MUST handle
``GET`` requests to resolve aliases on other servers; they should do this using
the federation API if necessary.
Rooms store a *partial* list of room aliases via the ``m.room.aliases`` state
event. This alias list is partial because it cannot guarantee that the alias
list is in any way accurate or up-to-date, as room aliases can point to
different room IDs over time. Crucially, the aliases in this event are
**purely informational** and SHOULD NOT be treated as accurate. They SHOULD
be checked before they are used or shared with another user. If a room
appears to have a room alias of ``#alias:example.com``, this SHOULD be checked
to make sure that the room's ID matches the ``room_id`` returned from the
request.
Rooms do not store a list of all aliases present on a room, though members
of the room with relevant permissions may publish preferred aliases through
the ``m.room.canonical_alias`` state event. The aliases in the state event
should point to the room ID they are published within, however room aliases
can and do drift to other room IDs over time. Clients SHOULD NOT treat the
aliases as accurate. They SHOULD be checked before they are used or shared
with another user. If a room appears to have a room alias of ``#alias:example.com``,
this SHOULD be checked to make sure that the room's ID matches the ``room_id``
returned from the request.
{{directory_cs_http_api}}

10
specification/modules/instant_messaging.rst
View file

@ -275,13 +275,9 @@ choose a name:
1. If the room has an `m.room.name`_ state event with a non-empty ``name``
field, use the name given by that field.
#. If the room has an `m.room.canonical_alias`_ state event with a non-empty
``alias`` field, use the alias given by that field as the name.
#. If neither of the above conditions are met, the client can optionally guess
an alias from the ``m.room.alias`` events in the room. This is a temporary
measure while clients do not promote canonical aliases as prominently. This
step may be removed in a future version of the specification.
#. If the room has an `m.room.canonical_alias`_ state event with a valid
``alias`` field, use the alias given by that field as the name. Note that
clients should avoid using ``alt_aliases`` when calculating the room name.
#. If none of the above conditions are met, a name should be composed based
on the members of the room. Clients should consider `m.room.member`_ events