MSC4261: "Do not encrypt for device" flag #4261
Conversation
uhoreg
changed the title
uhoreg
added
e2e
proposal
|
|
||
| ## Proposal | ||
|
|
||
| A new optional `do_not_encrypt` property is added to the `DeviceKeys` structure |
There was a problem hiding this comment.
Suggestions for better names welcome
There was a problem hiding this comment.
Implementation requirements:
- Client asking to not be encrypted to
- Client not encrypting to that other client
| Some devices (such as bots and application service puppets) may not need to | ||
| receive encrypted messages. For example, an application service may have | ||
| multiple puppeted users in a room, but only needs to receive room keys once to | ||
| decrypt a message; sending the room keys to all of the application service's |
There was a problem hiding this comment.
#4350 defines a method for appservices to avoid creating multiple sessions in the first place
There was a problem hiding this comment.
#4350 looks like a more complete solution for bridges. This MSC might still be useful for bots that only need to send messages, but not read messages. But without the bridge use-case, it might not be worth it. So I plan on closing this MSC once 4350 gets far enough along.
There was a problem hiding this comment.
Oh yes, this could still be useful for normal bots, especially if combined with a command system like MSC4332 to give bots the ability to say "only encrypt commands for me". Telegram bots have a similar "privacy mode" flag where they either receive all messages or only registered commands
3 participants
Rendered
Conflict of interest statement: I am a Matrix Spec Core Team member, and and employee of Element on the Cryptography team. This proposal was written as part of my work on the Element Cryptography team, based on feedback on MSC4153.