Compare commits

...

7 commits

Author SHA1 Message Date
Kim Brose 33500357af
Merge bb623a587e into e2b879d13d 2026-07-15 13:10:53 -04:00
HarHarLinks bb623a587e author's intention was a SHOULD requirement
Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>
2026-07-15 19:10:46 +02:00
HarHarLinks a4607b35dd add newsfragment
Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>
2026-07-14 13:25:23 +02:00
HarHarLinks b5de7d3804 reference source for key withholding codes
Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>
2026-07-14 13:23:25 +02:00
HarHarLinks c3758791dc clarify wording around history sharing exception
Signed-off-by: HarHarLinks <2803622+HarHarLinks@users.noreply.github.com>
2026-07-14 13:05:29 +02:00
Kim Brose 28183d4607
Fix typo 2026-07-10 21:12:45 +02:00
Kim Brose f76b68eced
Clarify keys must be shared according to history visiblity 2026-07-10 21:09:14 +02:00
3 changed files with 20 additions and 7 deletions

View file

@ -0,0 +1 @@
Clarify history key sharing requirements. Contributed by @HarHarLinks and Matrix Stammtisch Aachen.

View file

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

View file

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