Skip to content

Commit

Permalink
initial proposal
Browse files Browse the repository at this point in the history
  • Loading branch information
uhoreg committed Feb 1, 2025
1 parent eb813af commit 5745065
Showing 1 changed file with 51 additions and 0 deletions.
51 changes: 51 additions & 0 deletions proposals/xxxx-do-not-encrypt-for-device-flag.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
# MSCxxxx: "Do not encrypt for device" flag

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
puppeted users is redundant. Another example is bots that only need to send
messages, but not receive messages.

We propose adding a flag to the device keys to indicate that encrypted messages
should not be sent to certain devices.

## Proposal

A new optional `do_not_encrypt` property is added to the `DeviceKeys` structure
that the client uploads to the server via the `POST /keys/upload` endpoint, or
downloads via the `POST /keys/query` endpoint. This property is a boolean that
defaults to `false`.

Clients MUST NOT send room keys to devices that have this property set to `true`.

## Potential issues

Since this is a device-level flag, application services must ensure that at
least one device that is able to receive room keys is present in each room where
it needs to receive encrypted messages. This can be done, for example, by
having a single application service user that is in all bridged rooms.

## Alternatives

Rather than including a flag in the device keys, a flag could be put in room
state, such as the user's `m.room.member` state event. However, by putting the
flag in the device keys, the flag is signed so that it cannot be forged. In
addition, the `m.room.member` state may not work well as the server generates
these events in response to profile changes, and may overwrite the flag.
Creating a new state event for this seems unnecessary if using the device keys
works.

## Security considerations

This proposal decreases the number of devices that will receive room keys, so
does not pose any risk for leaking messages.

## Unstable prefix

Until this is proposal is accepted, implementations should use the property name
`org.matrix.mscxxxx.do_not_encrypt` rather than `do_not_encrypt`.

## Dependencies

None

0 comments on commit 5745065

Please sign in to comment.