Add function to share megolm keys for historical messages, take 2 #1640
Conversation
jryans
changed the title
| @@ -192,7 +210,7 @@ utils.inherits(MegolmEncryption, EncryptionAlgorithm); | |||
| * OutboundSessionInfo when setup is complete. | |||
| */ | |||
| MegolmEncryption.prototype._ensureOutboundSession = async function( | |||
| devicesInRoom, blocked, singleOlmCreationPhase, | |||
| room, devicesInRoom, blocked, singleOlmCreationPhase, | |||
There was a problem hiding this comment.
Would it make sense for EncryptionAlgorithm to hold the room model from the start at construction time, rather than expecting in certain functions...? It already has the room ID. Just an idea, perhaps there's a reason to prefer this instead.
There was a problem hiding this comment.
Yeah, I don't know if there's a particular reason why the EncryptionAlgorithm only holds the room ID rather than the whole room model. But I wanted to avoid making too many unrelated changes.
| @@ -1370,10 +1400,14 @@ MegolmDecryption.prototype.onRoomKeyEvent = function(event) { | |||
| keysClaimed = event.getKeysClaimed(); | |||
| } | |||
|
|
|||
| const extraSessionData = {}; | |||
| if (content["org.matrix.msc3061.shared_history"]) { | |||
| extraSessionData.sharedHistory = true; | |||
There was a problem hiding this comment.
Should this locally stored session data be prefixed with the MSC while it's an experiment, or do we assume it's not necessary to guard local data like that?
There was a problem hiding this comment.
In general, local data doesn't need to be guarded in the same way as data sent between client, as the local client can usually manage any changes itself.
Implements matrix-org/matrix-spec-proposals#3061