From 21888b554285c1dd58d6288d34a5f5cf67fdfd7b Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 18 Oct 2016 16:05:17 +0100 Subject: [PATCH 1/2] e2e guide: formatting tweaks --- supporting-docs/guides/2016-10-18-e2e_implementation.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/supporting-docs/guides/2016-10-18-e2e_implementation.rst b/supporting-docs/guides/2016-10-18-e2e_implementation.rst index 79ff5109b..c89d558cf 100644 --- a/supporting-docs/guides/2016-10-18-e2e_implementation.rst +++ b/supporting-docs/guides/2016-10-18-e2e_implementation.rst @@ -6,6 +6,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 proceeding. +.. contents:: + The libolm library ------------------ @@ -608,8 +610,8 @@ relevant user's devices (using the wildcard ``*`` in place of the ``device_id``) via ``PUT /_matrix/client/unstable/sendToDevice/m.new_device/.`` -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`` section of the ``/sync`` response. From 703b782ea1aa9281d5bd5b2d22b7b33e9512a87f Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 18 Oct 2016 16:06:22 +0100 Subject: [PATCH 2/2] e2e guide: remove refs to refresh tokens refresh tokens are d34d --- supporting-docs/guides/2016-10-18-e2e_implementation.rst | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/supporting-docs/guides/2016-10-18-e2e_implementation.rst b/supporting-docs/guides/2016-10-18-e2e_implementation.rst index c89d558cf..4f323630e 100644 --- a/supporting-docs/guides/2016-10-18-e2e_implementation.rst +++ b/supporting-docs/guides/2016-10-18-e2e_implementation.rst @@ -41,12 +41,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 ``device_id`` in the request body. -The lifetime of devices and ``access_token``\ s (technically: chains of -``refresh_token``\ s and ``access_token``\ s), are closely related. In +The lifetime of devices and ``access_token``\ s are closely related. 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 -``access_token`` chain. If a client reuses a ``device_id`` when logging -in, there will be several ``access_token`` chains associated with a +``access_token``. If a client reuses a ``device_id`` when logging +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 active at once (though we do not currently enforce that in Synapse).