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

Clarify profile propagation section more

Browse source
This commit is contained in:
Kegsay 2015-01-19 17:24:28 +00:00
parent a1964b466b
commit 61b8664286
1 changed files with 7 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

12
drafts/general_api.rst
View file

@ -444,15 +444,17 @@ and membership changes.
However, this introduces its own set of problems, namely flicker. The
client would receive the ``m.room.member`` event first, followed by
the ``m.room.member.profile`` event, which could cause a flicker. In
addition, federation may not send both event types in a single transaction,
addition, federation may not send both events in a single transaction,
resulting in missing information on the receiving home server.
For federation, these problems can be resolved by sending the
``m.room.member`` event as they are in v1 (with ``displayname`` and
``avatar_url`` in the ``content``). The receiving home server will then
extract these keys and create a server-generated ``m.room.member.profile``
event. To avoid confusion with duplicate information, the ``avatar_url``
and ``displayname`` keys should be removed by the receiving home server.
``avatar_url`` in the ``content``). They *have* to be sent in the
``content`` as this information needs to be signed. The receiving home
server will then extract these keys and create a server-generated
``m.room.member.profile`` event. To avoid confusion with duplicate
information, the ``avatar_url`` and ``displayname`` keys should be
removed from the ``m.room.member`` event by the receiving home server.
When a client requests these events (either from the event stream
or from an initial sync), the server will send the generated
``m.room.member.profile`` event under the ``unsigned.profile`` key of the