mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-08-04 15:07:47 +02:00
Merge a4607b35dd into e2b879d13d
This commit is contained in:
commit
fdc517365f
|
|
@ -0,0 +1 @@
|
|||
Clarify history key sharing requirements. Contributed by @HarHarLinks and Matrix Stammtisch Aachen.
|
||||
|
|
@ -1551,7 +1551,7 @@ objects described as follows:
|
|||
|
||||
{{% added-in v="1.19" %}}
|
||||
|
||||
When Alice invites Bob to an encrypted room, she might want Bob to have access
|
||||
When Alice invites Bob to an encrypted room, she likely wants Bob to have access
|
||||
to messages that were previously sent in that room, subject to the [history
|
||||
visibility](#room-history-visibility) setting of the room.
|
||||
|
||||
|
|
@ -1610,12 +1610,22 @@ room.
|
|||
|
||||
##### Construction and sharing of the key bundle
|
||||
|
||||
Alice's client MAY choose not to share any room history (even messages sent when the
|
||||
history visibity setting would allow sharing) if the current history
|
||||
visibility setting does not allow sharing (i.e. if `history_visibility` is
|
||||
set to `invited` or `joined`).
|
||||
Marking keys as [shareable](#shareable-encryption-sessions) essentially serves as
|
||||
precomputation of which keys Bob needs to decrypt all messages he can see, as
|
||||
defined by the room's history visibility.
|
||||
|
||||
Otherwise, before inviting Bob to a room, Alice's client constructs and sends a key bundle as follows:
|
||||
History visibility mechanics prevent changing the visibility of events in
|
||||
hindsight. It is thus possible for a room timeline to have "gappy" visibility,
|
||||
i.e. events sent during `shared` visibility in the past are visible, but events
|
||||
more recently sent during `joined` visibility and before joining are not visible.
|
||||
In such cases where the current history visibility setting does not allow sharing
|
||||
(i.e. if `history_visibility` is set to `invited` or `joined`), Alice's client
|
||||
MAY choose not to share *any* room history, even messages sent when the
|
||||
history visibility setting would allow sharing.
|
||||
|
||||
In all other cases, Alice's client MUST share all available shareable keys.
|
||||
|
||||
Before inviting Bob to a room, Alice's client constructs and sends a key bundle as follows:
|
||||
|
||||
1. Alice's client SHOULD ensure that it has downloaded all keys relevant to the room
|
||||
from [server-side key backup](#server-side-key-backups), if she is using it.
|
||||
|
|
|
|||
|
|
@ -33,7 +33,9 @@ properties:
|
|||
- m.no_olm
|
||||
- m.history_not_shared
|
||||
description: |-
|
||||
A machine-readable code for why the key was not sent. Codes beginning
|
||||
A machine-readable code for why the key was not sent, as defined by
|
||||
[Reporting that decryption keys are withheld](#reporting-that-decryption-keys-are-withheld).
|
||||
Codes beginning
|
||||
with `m.` are reserved for codes defined in the Matrix
|
||||
specification. Custom codes must use the Java package naming
|
||||
convention.
|
||||
|
|
|
|||
Loading…
Reference in a new issue