Patch power levels on room creation

[digitalentity]

Fixes https://github.com/digitalentity/matrix_encryption_disabler/issues/3

This now works similar to https://github.com/fhirfactory/pegacorn-communicate-roomserver/pull/7, but still keeps encryption from being enabled from the start during room creation and filters the encryption events just to be safe.

If federated servers and clients respect permissions room encryption should never be enabled even if the room is federated.

@spantaleev you might want to test this change and make sure it works with your ansible playbooks (no reason why it shouldn't though).

[digitalentity]

Tested on a private server, works as intended. Not tested with federated servers, but I expect it work correctly if servers comply to the protocol and enforce power levels.

[spantaleev]

Does Synapse not validate these power level values? Is 150 a valid value? The m.room.power_levels description in the Matrix 1.2 spec does not seem to explicitly state that you can't use a value higher than 100.

In practice, it seems like you've tested it and Synapse and the clients you've tested don't break, at least not yet.

Still, it seems a little dangerous to use such values. Any homeserver that gets involved with this room over federation may encounter trouble. Even Synapse itself may reject this unusual value if it encounters it over federation (not tested, but it's a reasonable suspicion).

---

So I think that this feature is a little dangerous to have, especially when enabled by default.

It may make sense to:

• try and clear up what the spec really says
  • [ ] can one go higher than 100?
  • [ ] should the next spec release make that explicit, so that other homeserver and client developers will be made aware of it?
• test if such rooms can federate:
  • [ ] most importantly with Synapse
  • [ ] Dendrite
  • [ ] Conduit
• test other clients:
  • [ ] I assume that at least Element (on which platform?) doesn't break
  • [ ] and you've probably tested Fluffychat yourself
  • [ ] should some other clients be tested?
• consider whether this should be "on by default and always". It creates a non-standard room that has potential to break and that cannot be fixed (I assume you can't bring m.room.encryption down to 100 or lower, once you've set it to a value than your own power level)
  • [ ] a configuration setting may make sense
  • [ ] disabling it by default may make sense
  • [ ] consider mentioning in the docs (or configuration setting information, if a configuration setting is introduced) that power levels may be replaced with a borked up non-standard risky value
  • [ ] .. and that all rooms created while matrix_encyption_disabler is active are forever prevented from becoming encrypted

[spantaleev]

Also, rewriting the m.room.power_levels state event seems risky, because the client may have sent its own other m.room.power_levels configuration. I suppose rooms created using some automation (a bot, a bridge, etc.), may be pre-configured with special power levels. Not sure if bridge-created events go through this "spam checker" event filter though, but bot-created events via the API do. Having matrix_encryption_disabler enabled on the server will throw away their custom values and replace them with these hardcoded defaults, wouldn't it?

m.room.power_levels logic with a higher fidelity would be preferable. Say, if no m.room.power_levels is found, use these defaults (just like now). But if such an event exists, reach into and set or modify its m.room.encryption key only, leaving all other levels intact. For additional safety, you may also wish to verify that the power level for the user (content.user.requestor_id) is less than what you're specifying for m.encryption, etc.

[digitalentity]

Makes sense. I've tested this with Element (Linux, Android, Web), FluffyChat (Android and Web), Syphon (Android). No issues.

I'll propose changes to the spec to allow higher power levels (non-interactively set by automation).

I also thought about something that would rewrite the power_levels event if present, but I wanted something fast to verify the idea and make sure it works on federated rooms. Proper patching is on my to-do list.

Hiding this hack behind a setting makes perfect sense, thanks, that didn't come to my mind when I was writing this.