Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-01 09:14:10 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Merge branch 'rav/e2e_guide'

Browse source
This commit is contained in:
Richard van der Hoff 2016-10-18 18:25:40 +01:00
parent 05ca311be3 703b782ea1
commit 4c008a4771
1 changed files with 7 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
supporting-docs/guides/2016-10-18-e2e_implementation.rst
View file

@ -12,6 +12,8 @@ support for end-to-end encryption. It is highly recommended that readers
be familiar with the Matrix protocol and the use of access tokens before be familiar with the Matrix protocol and the use of access tokens before
proceeding. proceeding.
.. contents::
The libolm library The libolm library
------------------ ------------------
@ -45,12 +47,11 @@ response; a client is also free to generate its own ``device_id`` or, as
above, reuse a device, in which case the client should pass the above, reuse a device, in which case the client should pass the
``device_id`` in the request body. ``device_id`` in the request body.
The lifetime of devices and ``access_token``\ s (technically: chains of The lifetime of devices and ``access_token``\ s are closely related. In
``refresh_token``\ s and ``access_token``\ s), are closely related. In
the simple case where a new device is created each time you log in, the simple case where a new device is created each time you log in,
there is a one-to-one mapping between a ``device_id`` and an there is a one-to-one mapping between a ``device_id`` and an
``access_token`` chain. If a client reuses a ``device_id`` when logging ``access_token``. If a client reuses a ``device_id`` when logging
in, there will be several ``access_token`` chains associated with a in, there will be several ``access_token``\ s associated with a
given ``device_id`` - but still, we would expect only one of these to be given ``device_id`` - but still, we would expect only one of these to be
active at once (though we do not currently enforce that in Synapse). active at once (though we do not currently enforce that in Synapse).
@ -614,8 +615,8 @@ relevant user's devices (using the wildcard ``*`` in place of the
``device_id``) via ``PUT ``device_id``) via ``PUT
/_matrix/client/unstable/sendToDevice/m.new_device/<txnId>.`` /_matrix/client/unstable/sendToDevice/m.new_device/<txnId>.``
Handling an m.new_device event Handling an ``m.new_device`` event
------------------------------- ----------------------------------
As with ``m.room_key`` events, these will appear in the ``to_device`` As with ``m.room_key`` events, these will appear in the ``to_device``
section of the ``/sync`` response. section of the ``/sync`` response.