Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
MSC3757: Restricting who can overwrite a state event #3757
base: main
Are you sure you want to change the base?
MSC3757: Restricting who can overwrite a state event #3757
Changes from all commits
ff5fd48
610f244
bfde329
344e876
ccb7e52
1ce7e0e
6df6109
6e108b3
bd4176f
e352a1d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To overwrite another user's state event, must your power level exceed the event type's PL, or the PL of the user who owns the event?
i.e. should this be reworded to the following:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of the event type's power level i.e. we're not changing anything here except expanding the existing exception where a user can create a state event beyond their power level if they use a specific state key.
Could the wording be improved to clarify this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't mentioned anywhere, at least not explicitly. If the only intended change to the auth rules is the change to step 8, then the preceding step still says to reject if the sender's PL is less than the event type’s required power level.
For the exception to hold, step 7 could simply be removed, meaning the PL restriction would be applied by the proposed change to rule 8.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, no -- that would remove PL restrictions for non-state events.
How about replacing steps 7 and 8 with this:
sender
’s power level, and the event does not have astate_key
matching thesender
optionally followed by a substring prefixed with_
, reject.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hang on, I was getting confused with #3779 - sorry for the confusion!
I think this MSC restricts who can overwrite certain state events, and I agree that the wording as it is now doesn't make sense, because it actually allows everyone to overwrite, because we won't reach rule 8 without first passing rule 7 which already checks power level.
I think I just prefer #3779 over this one, and if I understand right, we don't need both.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
String-based matching still feels like a bandaid solution for a larger problem. The problem statement is reasonable (beacons, calls, and integrations all want an ability to narrow power levels), however there are non-state events where it'd be worth having a similar access mechanism (namely for edits).
At the point where we're considering string-packing, a top level field on the event works just as well and is more extensible, capable, and presentable than a packed string. It can be populated with query parameters to the
PUT /state
orPUT /send
calls, and servers are easily able to retrieve information from the event. Further, since we're modifying the auth rules to accomplish this, there is no material difference to the implementation effort of the proposal itself.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering if a top level field implies that state_key and access mechanism are independent.
If this is what is proposed I have the concern that this would allow blocking of state keys by not allowing to write to them anymore. (I think I saw this being brought up somewhere else as well. cannot find it right now)
But the concept of merging key + access level makes a lot of sense to me since it would behave more like a namespace than an add-on permission system. And I think the idea of namespaces (kind of like inverse domains where each user owns the domain starting with their username) is a very good fit for a key value based state like the room state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(edited out to avoid confusion)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, the above was wrong - I was mixing this up with #3779 which I think replaces this, and which I prefer.