-
-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider supporting arbitrary state changes when upgrading rooms #427
Comments
Well, someone with enough permission can easily lock out everyone else by making the room invite-only and upgrading it, right? |
That's a bit less of a risk because there'd be other administrators (hopefully) to counteract what that admin did. Because one can't demote someone of the same power level, it'd probably end up being a war of state events until one of the parties gives up. Fixing the power levels during an upgrade (ignoring the same PL restriction) would mean that one could upgrade the room, claim to be the only admin, and successfully take over the room. However, being able to fix the power levels also feels like a desirable feature. |
Some rooms might want to go from
m.federate: true
tom.federate: false
or fix power levels which they cannot otherwise do (everyone is an admin, oops). Similar to/createRoom
, there could be a parameter on the request body to override the state that's going to be set in thew new rooms.The problem with this would be the large avenue for abuse: someone with enough permission could effectively lock out everyone else by simply upgrading the room.
The text was updated successfully, but these errors were encountered: