End to end encrypted channels

Encryption settings event

This is the event stored to store the encryption settings in the guild or channel.

{
  "id": event_id, // ID of the channel security settings event
  "guild_id": guild_id, // ID of the guild
  "channel_id": channel_id, 
  // ID of the channel (0: guild-wide default, 1: guild-wide with no per-channel override, all other values: actual channel IDs)
  "encryption_permission_mask": encryption_permissions, // a bitmask related to encryption-related permission
  "allowed_algorithms": array_of_algorithms, // array of allowed end-to-end encrpytion algorithm
  "current_algorithm": algo, // currently used encryption algorithm
  "used_since_message": message_id // the first message that uses this algorithm
}

The encryption permissions mask would look sth like this:
1<<0: enable end-to-end encryption
1<<1: enable double-ratchet encryption
1<<2: enable homomorphic encryption
1<<3: change allowed algorithms
1<<4: create encrypted threads within text channel
1<<5: defer valid-since time
1<<6: change currently used algorithm
Those fields will inherit from guilds when unset, except used_since_message, which will be set by system when first message using that algorithm in the channel is sent and not allowed to be overridden.
Encryption settings events should appear in the timeline as messages with a type of ENCRYPTION (type 50).
The channel and guild objects will refer to encryption settings events using a encryption property, whose value is the ID of the encryption settings event.
The server should not allow encryption settings events to be removed, as that would cause downgrade attacks.

• Initial steps (31bfe2a22)
• Permission checks on settings

Key exchange procedure

• MLS support #387
• Secret storage #285
• Device verification and session revocation
• Routing of to-device and to-channel key negotiation events

Security invariant

Once encryption is enabled you cannot disable it any more.

No files, tests, or implementation entry points are named. Start by reviewing the completed initial-steps commit and the Encryption settings event and Key exchange procedure sections, then inspect issues #387 and #285; done would require agreed implementations for the unchecked permission, key exchange, verification, routing, and security-invariant work.