Skip to content
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

Open
TheArcaneBrony opened this issue Nov 25, 2024 · 4 comments
Open

[Brainstorming] More granular access controls/power levels #2012

TheArcaneBrony opened this issue Nov 25, 2024 · 4 comments
Labels
improvement An idea/future MSC for the spec

Comments

@TheArcaneBrony
Copy link

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 with msgtype: 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.

@TheArcaneBrony TheArcaneBrony added the improvement An idea/future MSC for the spec label Nov 25, 2024
@turt2live
Copy link
Member

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.

@MTRNord
Copy link
Contributor

MTRNord commented Nov 25, 2024

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.

@KitsuneRal
Copy link
Member

Did I miss something or decentralised RBAC with no single point of trust hasn't been invented yet?

@MTRNord
Copy link
Contributor

MTRNord commented Nov 26, 2024

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement An idea/future MSC for the spec
Projects
None yet
Development

No branches or pull requests

4 participants