Consistently capitalise "Olm" and "Megolm".

This commit is contained in:
Denis Kasak 2022-05-26 15:37:48 +02:00
parent 7122ceb6a8
commit b5b25c2741
4 changed files with 16 additions and 16 deletions

View file

@ -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

View file

@ -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 users 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

View file

@ -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:

View file

@ -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: