MSC3757: Restricting who can overwrite a state event #3757
Conversation
andybalaam
changed the title
turt2live
added
requires-room-version
This comment was marked as duplicate.
This comment was marked as duplicate.
Co-authored-by: Andrew Morgan <[email protected]>
Co-authored-by: Travis Ralston <[email protected]>
|
That concern has already been raised. |
|
That concern has already been raised. |
|
|
This proposal requires re-review from several SCT members and adjacent folks. The priority is a bit unclear to me, but that is a different problem (see room). |
This is still the crux of this proposal and I'm in agreement with @turt2live that I'm a -1 for the string packing. |
|
Maybe it's worth having a new MSC to explore one of the top-level field alternatives: |
Maybe MSC3760 or MSC3779 was supposed to be that? (3760 appears to be very similar to this.) |
| The size of a state key suffix after a leading user ID and the separator character is limited to | ||
| **255 bytes** so that any such suffix may follow any user ID without the complete state key | ||
| ever surpassing the total state key size limit. | ||
| Similarly, the size of a state key without a leading user ID is limited to **255 bytes** so that any | ||
| state key without a leading user ID may be given one without ever surpassing the total size limit. |
There was a problem hiding this comment.
Is this conversion between prefixed and unprefixed state keys a real requirement? It seems to lead to a lot of complexity.
If we're doing this, I'd be inclined to just increase max state key length to (say) 512 bytes, and be done with it.
| Users with a higher power level than a state event's original sender may overwrite the event | ||
| despite their user ID not matching the one in event's `state_key`. This fixes an abuse | ||
| vector where a user can immutably graffiti the state within a room | ||
| by sending state events whose `state_key` is their user ID. |
There was a problem hiding this comment.
I'd say there's a strong argument for making this a separate MSC, rather than trying to fix two things at once.
| @@ -0,0 +1,118 @@ | |||
| # MSC3757: Restricting who can overwrite a state event. | |||
There was a problem hiding this comment.
Revisiting this a few months later (sorry), I still find my suggestion clearer.
|
@mscbot resolve concern changes to auth rules are unclear |
|
Unknown concern 'concern changes to auth rules are unclear'. |
|
Concerns-I-have-raised update: @mscbot resolve Alternatives section is missing some alternatives.
The introduction currently relies on location sharing to drive it, which is a deprioritized feature at the spec level. I highly suggest adding the VoIP impact to the introduction to naturally drive this MSC up the list.
This still appears to be the case. |
Is matrix-org/complement#733 not sufficient? |
Rendered
Implementations:
Written by @ara4n , with contributions from @Johennes and @andybalaam .
Shepherd: @AndrewFerr
FCP tickyboxes