Server access control lists can "ban" users with higher power levels

The server access control lists feature for a room is intended to ban an entire homeserver from participating in a room because its operator is using it for malicious activities, such as spamming. This is implemented via the `m.room.server_acl` event. Users that are residing on a homeserver that has been banned from participating in a room can no longer send events but will still receive events. This makes the server access control lists similar to a ban, albeit a banned user also no longer receives events.

The `m.room.server_acl` event is a regular state event and is not listed separately in the `m.room.power_levels` event, so the emission of `m.room.server_acl` will require a power level of 50 in most rooms. It is also a principle in the design philosophy of Matrix that administrative actions against users require having a higher power level than the targeted user or permission. So, Alice(50) cannot kick Bob(100). The other way around is very well possible.

The `m.room.server_acl` does not have any such restrictions. Assuming Alice(50) resides on alice.org and Bob(100) is on bob.org, then Alice can add bob.org to the deny list and effectively remove him from participation in room.

Yes, this requires an elevated power level in most rooms (assuming a rather standard version of `m.room.power_levels`) and yes, this is currently a design choice that can be made. I just want to spark a discussion whether additional checks should be placed on the `m.room.server_acl` event to be, in my opinion, more consistent with the rest of the access control model.

Start by reviewing the issue's descriptions of m.room.server_acl and m.room.power_levels, focusing on how server ACLs differ from user bans and other administrative actions. Determine whether the specification should require additional power-level checks; done means reaching and documenting a clear decision on that design question.

Written by the indexing model from the issue text.