From b5b25c2741943428a304a73a797858574b227849 Mon Sep 17 00:00:00 2001 From: Denis Kasak Date: Thu, 26 May 2022 15:37:48 +0200 Subject: [PATCH] Consistently capitalise "Olm" and "Megolm". --- .../modules/end_to_end_encryption.md | 10 +++++----- content/client-server-api/modules/secrets.md | 4 ++-- data/api/client-server/key_backup.yaml | 6 +++--- data/event-schemas/schema/m.room_key.withheld.yaml | 12 ++++++------ 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/content/client-server-api/modules/end_to_end_encryption.md b/content/client-server-api/modules/end_to_end_encryption.md index b883034e..528fb163 100644 --- a/content/client-server-api/modules/end_to_end_encryption.md +++ b/content/client-server-api/modules/end_to_end_encryption.md @@ -1498,9 +1498,9 @@ should use the session from which it last received and successfully decrypted a message. For these purposes, a session that has not received any messages should use its creation time as the time that it last received a message. A client may expire old sessions by defining a -maximum number of olm sessions that it will maintain for each device, +maximum number of Olm sessions that it will maintain for each device, and expiring sessions on a Least Recently Used basis. The maximum number -of olm sessions maintained per device should be at least 4. +of Olm sessions maintained per device should be at least 4. ###### Recovering from undecryptable messages @@ -1698,12 +1698,12 @@ requests](#key-requests), the device from which the key is being requested may want to tell the requester that it is purposely not sharing the key. -If Alice withholds a megolm session from Bob for some messages in a +If Alice withholds a Megolm session from Bob for some messages in a room, and then later on decides to allow Bob to decrypt later messages, -she can send Bob the megolm session, ratcheted up to the point at which +she can send Bob the Megolm session, ratcheted up to the point at which she allows Bob to decrypt the messages. If Bob logs into a new device and uses key sharing to obtain the decryption keys, the new device will -be sent the megolm sessions that have been ratcheted up. Bob's old +be sent the Megolm sessions that have been ratcheted up. Bob's old device can include the reason that the session was initially not shared by including a `withheld` property in the `m.forwarded_room_key` message that is an object with the `code` and `reason` properties from the diff --git a/content/client-server-api/modules/secrets.md b/content/client-server-api/modules/secrets.md index 17b515c7..cbb9af0b 100644 --- a/content/client-server-api/modules/secrets.md +++ b/content/client-server-api/modules/secrets.md @@ -279,7 +279,7 @@ To request a secret from other devices, a client sends an `m.secret.requests` device event with `action` set to `request` and `name` set to the identifier of the secret. A device that wishes to share the secret will reply with an `m.secret.send` event, encrypted -using olm. When the original client obtains the secret, it sends an +using Olm. When the original client obtains the secret, it sends an `m.secret.request` event with `action` set to `request_cancellation` to all devices other than the one that it received the secret from. Clients should ignore `m.secret.send` events received from devices that it did @@ -287,7 +287,7 @@ not send an `m.secret.request` event to. Clients must ensure that they only share secrets with other devices that are allowed to see them. For example, clients should only share secrets -with the user’s own devices that are verified and may prompt the user to +with the user's own devices that are verified and may prompt the user to confirm sharing the secret. ##### Event definitions diff --git a/data/api/client-server/key_backup.yaml b/data/api/client-server/key_backup.yaml index 0b438b9e..d9d8a796 100644 --- a/data/api/client-server/key_backup.yaml +++ b/data/api/client-server/key_backup.yaml @@ -398,7 +398,7 @@ paths: - in: path type: string name: sessionId - description: The ID of the megolm session that the key is for. + description: The ID of the Megolm session that the key is for. required: true x-example: "sessionid" - in: body @@ -470,7 +470,7 @@ paths: - in: path type: string name: sessionId - description: The ID of the megolm session whose key is requested. + description: The ID of the Megolm session whose key is requested. required: true x-example: "sessionid" responses: @@ -517,7 +517,7 @@ paths: - in: path type: string name: sessionId - description: The ID of the megolm session whose key is to be deleted. + description: The ID of the Megolm session whose key is to be deleted. required: true x-example: "sessionid" responses: diff --git a/data/event-schemas/schema/m.room_key.withheld.yaml b/data/event-schemas/schema/m.room_key.withheld.yaml index 797b51f9..40a122b7 100644 --- a/data/event-schemas/schema/m.room_key.withheld.yaml +++ b/data/event-schemas/schema/m.room_key.withheld.yaml @@ -16,20 +16,20 @@ description: |- was not in the room when the original message was sent. * `m.unavailable`: sent in reply to a key request if the device that the key is requested from does not have the requested key. - * `m.no_olm`: an olm session could not be established. + * `m.no_olm`: an Olm session could not be established. In most cases, this event refers to a specific room key. The one exception to - this is when the sender is unable to establish an olm session with the + this is when the sender is unable to establish an Olm session with the recipient. When this happens, multiple sessions will be affected. In order to avoid filling the recipient\'s device mailbox, the sender should only send one `m.room_key.withheld` message with no `room_id` nor `session_id` - set. If the sender retries and fails to create an olm session again in the + set. If the sender retries and fails to create an Olm session again in the future, it should not send another `m.room_key.withheld` message with a - `code` of `m.no_olm`, unless another olm session was previously + `code` of `m.no_olm`, unless another Olm session was previously established successfully. In response to receiving an `m.room_key.withheld` message with a `code` of `m.no_olm`, the - recipient may start an olm session with the sender and send an `m.dummy` - message to notify the sender of the new olm session. The recipient may + recipient may start an Olm session with the sender and send an `m.dummy` + message to notify the sender of the new Olm session. The recipient may assume that this `m.room_key.withheld` message applies to all encrypted room messages sent before it receives the message. properties: