-
-
Notifications
You must be signed in to change notification settings - Fork 101
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
[Brainstorming] More granular access controls/power levels #2012
Comments
I would much rather land Extensible Events than another turing-complete subsystem. matrix-org/matrix-spec-proposals#3842 is the current home for this work. |
I agree with wanting not another pushrules (they are crazy hard to follow and implement imho). However I dont think extensible events solve the limitations of power levels :) I think they actually make it even harder than it already is considering extensible events could contain more than one type of event (subtype?) which means the already not granular powerlevel model cant reach into that when it needs to. Imho we should like we do with the auth rewrite just reach for something off the shelf. Some RBAC system (preferable compatible with oauth since thats what happens on the auth side now anyway. So why use something not already integrated?) Not sure what in terms of RBAC exists but they range in complexity of course too. Modelling that system then in auth event world is a whole different problem then again. |
Did I miss something or decentralised RBAC with no single point of trust hasn't been invented yet? |
I honestly dont know. Rbac is just what is common in oauth World hence I went there here. I didnt go as far as actually checking what exists. Doesnt change however that powerlevels sadly are not up to their job. (possibly also since they imho didnt move with the rest of the spec but feel stuck in 2019) |
I've been thinking about this for a while, but I haven't reached any concrete ideas yet.
I wonder if we could take a page from how push rules work to extend power levels into specific event content?
Idea being, you can match an
m.room.message
event withmsgtype: m.image
and deny it according to auth rules, or similar kinds of things.Any better ideas?
I feel like it would be a good idea to have an intermediary state before we get RBAC.
The text was updated successfully, but these errors were encountered: