Specify history sharing#2399
Conversation
... instead of the ad-hoc table we have currently.
Co-authored-by: Kévin Commaille <76261501+zecakeh@users.noreply.github.com>
... so that we can reuse it in key bundles
richvdh
force-pushed
the
rav/history_sharing
branch
from
d2329c3 to
e81ffe1
Compare
| 1. Alice SHOULD ensure that she has downloaded all keys relevant to the room | ||
| from [server-side key backup](#server-side-key-backups), if she is using it. |
There was a problem hiding this comment.
I'm wondering if we should rephrase this section so that the requirements and actions are worded with respect to Alice's client rather than herself? The section below about Bob does it this way and it feels a little cleaner to me, if a bit more wordy.
| may be shared with future room members in this way. | ||
|
|
||
| Recipients SHOULD keep a record of the `shared_history` flag for each | ||
| encryption session. The state of the flag is also saved in the |
There was a problem hiding this comment.
Likely a stupid question but why do we RECOMMEND keeping a local record here?
There was a problem hiding this comment.
Not a stupid question.
I dunno really. I try to reserve MUST for circumstances where the protocol's going to stop working if implementations don't do it, as opposed to where the user's going to get a poor experience (if you want to make a client that gives your user a crappy experience, that's on you). It gets more complicated when we're talking about giving other users a poor experience, as in this case, but still I don't feel like it crosses the line into needing a MUST. Hard to justify objectively though.
| received a copy of the decryption keys for the session, is seen to leave the | ||
| room. | ||
|
|
||
| {{% changed-in v="1.19" %}} Since any user that received an invite to the |
There was a problem hiding this comment.
Should this not also list the new requirement to rotate the session when history visibility changes?
| containing the sessions she is aware of in the room. Alice SHOULD include | ||
| only [shareable encryption sessions](#shareable-encryption-sessions) in the | ||
| `room_keys` section of the structure; other sessions should be listed un the | ||
| with `withheld` section. |
There was a problem hiding this comment.
I probably missed it when scanning the MSC but I was surprised that this is a SHOULD. Does that not undermine the shared_history setting and allow for sharing keys that should be deemed unshareable?
There was a problem hiding this comment.
yup, good point. Let's change this.
Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>
| may be shared with future room members in this way. | ||
|
|
||
| Recipients SHOULD keep a record of the `shared_history` flag for each | ||
| encryption session. The state of the flag is also saved in the |
There was a problem hiding this comment.
Not a stupid question.
I dunno really. I try to reserve MUST for circumstances where the protocol's going to stop working if implementations don't do it, as opposed to where the user's going to get a poor experience (if you want to make a client that gives your user a crappy experience, that's on you). It gets more complicated when we're talking about giving other users a poor experience, as in this case, but still I don't feel like it crosses the line into needing a MUST. Hard to justify objectively though.
| 1. Alice SHOULD ensure that she has downloaded all keys relevant to the room | ||
| from [server-side key backup](#server-side-key-backups), if she is using it. |
| containing the sessions she is aware of in the room. Alice SHOULD include | ||
| only [shareable encryption sessions](#shareable-encryption-sessions) in the | ||
| `room_keys` section of the structure; other sessions should be listed un the | ||
| with `withheld` section. |
There was a problem hiding this comment.
yup, good point. Let's change this.
| received a copy of the decryption keys for the session, is seen to leave the | ||
| room. | ||
|
|
||
| {{% changed-in v="1.19" %}} Since any user that received an invite to the |
3 participants
Spec for MSC4268.
Based on #2398.Pull Request Checklist
Preview: https://pr2399--matrix-spec-previews.netlify.app