spec should be clearer about how to handle m.room.encryption events

[uhoreg]

For example, how to interpret:

• m.room.encryption events that have been redacted
  • when you're in the room when the event is redacted
  • when you join the room after the event is redacted and so don't see the original event
• m.room.encryption events that are "invalid"
  • missing fields
  • use an algorithm that you don't understand
• multiple m.room.encryption events

[uhoreg]

e.g. see discussion at matrix-org/matrix-spec-proposals#2176 (comment)

[turt2live]

this can probably all be solved in a single MSC ftr. The current recommendations that would be put into the spec still have holes.

[dkasak]

I propose that we should treat any change in the algorithm as breaking the room. It's the simplest and most obviously secure choice, and the algorithm can easily be changed by tombstoning the room.

[Mikaela]

https://spec.matrix.org/v1.9/client-server-api/#events-8 has this event:

{
  "algorithm": "m.megolm.v1.aes-sha2",
  "rotation_period_ms": 604800000,
  "rotation_period_msgs": 100
}

I understand that I am not allowed to touch algorithm, but how about rotation_period_ms and rotation_period_msgs? Setting them to the recommended defaults in the link breaks Element Web and I don't see anything forbidding me from touching them if I want to.

If I understood correctly, this particular case is also tracked at element-hq/element-web#27103.