MSC3757: Restricting who can overwrite a state event #3757

andybalaam · 2022-03-25T17:17:26Z

Rendered

Implementations:

Written by @ara4n , with contributions from @Johennes and @andybalaam .

Shepherd: @AndrewFerr

SCT Stuff:

FCP tickyboxes

No MSC checklist.

Status: "At risk" due to:

Multiple unresolved threads.
Multiple unaddressed non-trivial concerns raised which block FCP.
A non-zero number of SCT members disagree with this proposal's approach.
The above compounded by time: it's been a long while since FCP was proposed, and a long while since threads were opened.

Next steps: the SCT should review the MSC as a group and determine how to proceed. Potential outcomes are FCP-closure, cancellation of FCP, or unblocked forward movement towards merge.

proposals/3757-restricting-who-can-overwrite-a-state-event.md

ShadowJonathan

One nit, else this looks sound.

proposals/3757-restricting-who-can-overwrite-a-state-event.md

Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>

Co-authored-by: Travis Ralston <travisr@matrix.org>

turt2live · 2022-03-31T19:52:23Z

proposals/3757-restricting-who-can-overwrite-a-state-event.md

+them - and they also are awkward for some client implementations to
+manipulate.
+
+## Proposal


My general concern is that we already have JSON available to us, so we should use that. String packing works in areas where we don't have as fine control (voip call candidates, for example), but for something like this we can and should afford fields.

Since the SCT came down on the side of this proposal vs MSC3760 I consider this resolved. Please unresolve if you disagree.

I'm not sure where the conversation about the SCT preferring this over MSC3760 happened, but I'm strongly against the current proposal. String packing is going to cause bugs, having separate fields seems better in every sense.

Hence my concern I've left about insufficient alternatives being explored.

proposals/3757-restricting-who-can-overwrite-a-state-event.md

AndrewFerr · 2024-10-08T18:12:20Z

@mscbot concern Alternatives insufficient explored.

deba3b82..e16482ab re-examines the alternative of the m.peer_unwritable flag.

turt2live · 2024-12-10T19:38:16Z

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).

clokep · 2024-12-10T20:09:26Z

On the Apache voting scale, I'm at a -1.0 for how the MSC is currently written. A stronger rationale for why this is needed now and strong discounting of a top-level ACL structure would change this to a -0.9 (sorry, I'm just not in favour of string packing here).

This is still the crux of this proposal and I'm in agreement with @turt2live that I'm a -1 for the string packing.

AndrewFerr · 2024-12-10T20:16:47Z

Maybe it's worth having a new MSC to explore one of the top-level field alternatives:

clokep · 2024-12-10T21:08:21Z

Maybe it's worth having a new MSC to explore one of the top-level field alternatives:

* [Event ownership flag](https://github.com/matrix-org/matrix-spec-proposals/blob/andybalaam/owner-state-events/proposals/3757-restricting-who-can-overwrite-a-state-event.md?rgh-link-date=2024-12-10T20%3A16%3A47Z#event-ownership-flag)

* [Owning user ID field](https://github.com/matrix-org/matrix-spec-proposals/blob/andybalaam/owner-state-events/proposals/3757-restricting-who-can-overwrite-a-state-event.md?rgh-link-date=2024-12-10T20%3A16%3A47Z#owning-user-id-field)

Maybe MSC3760 or MSC3779 was supposed to be that? (3760 appears to be very similar to this.)

andybalaam · 2024-12-11T16:54:43Z

Maybe MSC3760 or MSC3779 was supposed to be that? (3760 appears to be very similar to this.)

Yes, MSC3760 was an alternative without string-packing. MSC3779 is different: it is intended to allow low-power users to create these state events.

richvdh · 2024-12-17T18:11:46Z

proposals/3757-restricting-who-can-overwrite-a-state-event.md

+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.


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.

I think I was thrown off a bit by the explanation involving currently-valid state keys and thinking that this implied wanting to user-namespace currently state keys. Really the point is simply that, with a maximum length user ID, you need some space to fit something on the end, so yeah, I'd say just keep it simple & double state key length.

richvdh · 2024-12-17T18:15:28Z

proposals/3757-restricting-who-can-overwrite-a-state-event.md

+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.


I'd say there's a strong argument for making this a separate MSC, rather than trying to fix two things at once.

richvdh · 2024-12-17T18:16:36Z

proposals/3757-restricting-who-can-overwrite-a-state-event.md

@@ -0,0 +1,118 @@
+# MSC3757: Restricting who can overwrite a state event.


Revisiting this a few months later (sorry), I still find my suggestion clearer.

richvdh · 2024-12-17T18:20:41Z

@mscbot resolve concern changes to auth rules are unclear

mscbot · 2024-12-17T18:20:44Z

Unknown concern 'concern changes to auth rules are unclear'.

richvdh · 2024-12-17T18:24:44Z

@mscbot resolve changes to auth rules are unclear
@mscbot resolve issue of state event proliferation requires discussion

turt2live · 2024-12-17T20:11:56Z

Concerns-I-have-raised update:

@mscbot resolve Alternatives section is missing some alternatives.
@mscbot resolve Specific alternative of top-level access control is not sufficiently discounted.

Introduction does not sufficiently list benefiting MSCs/features.

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.

Insufficient implementation - Complement tests are required for this MSC.

This still appears to be the case.

AndrewFerr · 2024-12-19T21:08:27Z

Introduction does not sufficiently list benefiting MSCs/features.

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.

2a77266

Insufficient implementation - Complement tests are required for this MSC.

This still appears to be the case.

Is matrix-org/complement#733 not sufficient?

Xiretza · 2025-03-26T17:50:20Z

proposals/3757-restricting-who-can-overwrite-a-state-event.md

+As the spec currently enforces [a size limit of 255 bytes for both user IDs and state keys](
+https://spec.matrix.org/unstable/client-server-api/#size-limits),
+the size limit on state keys is increased to **511 bytes** to allow prefixing any currently-valid
+state key with a maximum-length user ID (and a separator character).
+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.


This part can most charitably be described as an awful hack. There should never be a reason to encode multiple independent values into a single string field inside a structured data format like JSON, let alone then enforcing strict length limits on different parts. No, this is terrible, the section "Multi-component state keys" describes what a real solution would have to look like.

dbkr · 2025-06-24T17:18:43Z

proposals/3757-restricting-who-can-overwrite-a-state-event.md

+terminate the leading user ID was deliberately chosen to be an underscore, as it is not
+allowed in [any form of server name](https://spec.matrix.org/v1.11/appendices/#server-name)
+(either a DNS name or IPv4/6 address, with or without a numeric port specifier) and thus cannot be
+confused as part of the server name of a leading user ID (with one caveat mentioned as a


But above you've said that resolvable domain names with underscores exist: wouldn't this allow the attack you talk about below?

andybalaam added 2 commits March 25, 2022 17:16

Add 'Restricting who can overwrite a state event'

ff5fd48

Rename MSC3757 to its proper number

610f244

andybalaam changed the title ~~Restricting who can overwrite a state event~~ MSC3757: Restricting who can overwrite a state event Mar 25, 2022

ShadowJonathan reviewed Mar 25, 2022

View reviewed changes

proposals/3757-restricting-who-can-overwrite-a-state-event.md Outdated Show resolved Hide resolved

turt2live reviewed Mar 25, 2022

View reviewed changes

proposals/3757-restricting-who-can-overwrite-a-state-event.md Outdated Show resolved Hide resolved

This comment was marked as duplicate.

Sign in to view

MTRNord reviewed Mar 25, 2022

View reviewed changes

proposals/3757-restricting-who-can-overwrite-a-state-event.md Outdated Show resolved Hide resolved

turt2live reviewed Mar 25, 2022

View reviewed changes

proposals/3757-restricting-who-can-overwrite-a-state-event.md Show resolved Hide resolved

anoadragon453 reviewed Mar 30, 2022

View reviewed changes

proposals/3757-restricting-who-can-overwrite-a-state-event.md Outdated Show resolved Hide resolved

proposals/3757-restricting-who-can-overwrite-a-state-event.md Outdated Show resolved Hide resolved

proposals/3757-restricting-who-can-overwrite-a-state-event.md Show resolved Hide resolved

ShadowJonathan approved these changes Mar 30, 2022

View reviewed changes

proposals/3757-restricting-who-can-overwrite-a-state-event.md Show resolved Hide resolved

andybalaam and others added 5 commits March 31, 2022 11:44

Clarify wording of comment

bfde329

Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>

Add unstable room version

344e876

Co-authored-by: Travis Ralston <travisr@matrix.org>

Note that this requires a new room version

ccb7e52

Refer to MSC3760 as an alternative

1ce7e0e

Re-word link to MSC3760

6df6109

turt2live reviewed Mar 31, 2022

View reviewed changes

kegsay reviewed Apr 4, 2022

View reviewed changes

proposals/3757-restricting-who-can-overwrite-a-state-event.md Show resolved Hide resolved

jplatte mentioned this pull request Apr 4, 2022

MSC3760: State sub-keys #3760

Closed

ara4n reviewed Apr 12, 2022

View reviewed changes

proposals/3757-restricting-who-can-overwrite-a-state-event.md Show resolved Hide resolved

uhoreg reviewed Apr 20, 2022

View reviewed changes

proposals/3757-restricting-who-can-overwrite-a-state-event.md Show resolved Hide resolved

Update to m.self to match latest thinking on MSC3672

6e108b3

dkasak reviewed May 5, 2022

View reviewed changes

proposals/3757-restricting-who-can-overwrite-a-state-event.md Outdated Show resolved Hide resolved

AndrewFerr added 3 commits October 8, 2024 13:45

Propose sender-scoped state with ownership flag

8090f69

Fix typo

3a0d095

Mention impact of sender-scoped state on servers

e16482a

AndrewFerr added 2 commits October 9, 2024 11:52

Say how the ownership flag impacts administration

1ddddb6

Fix contradictions for flag alternative

fd87b8a

turt2live requested review from clokep, turt2live, kegsay and richvdh December 10, 2024 19:36

clokep removed their request for review December 10, 2024 20:09

richvdh reviewed Dec 17, 2024

View reviewed changes

turt2live removed their request for review December 17, 2024 20:12

Change intro example from locations to MatrixRTC

2a77266

Xiretza reviewed Mar 26, 2025

View reviewed changes

dbkr reviewed Jun 24, 2025

View reviewed changes

turt2live added voip matrix-2.0 Required for Matrix 2.0 labels Jul 8, 2025

turt2live moved this from Ready for FCP ticks to Proposed-FCP at risk in Spec Core Team Workflow Jul 8, 2025

		@@ -0,0 +1,118 @@
		# MSC3757: Restricting who can overwrite a state event.

MSC3757: Restricting who can overwrite a state event #3757

Are you sure you want to change the base?

MSC3757: Restricting who can overwrite a state event #3757

Uh oh!

Conversation

andybalaam commented Mar 25, 2022 • edited by turt2live Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment was marked as duplicate.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ShadowJonathan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AndrewFerr commented Oct 8, 2024

Uh oh!

turt2live commented Dec 10, 2024

Uh oh!

clokep commented Dec 10, 2024

Uh oh!

AndrewFerr commented Dec 10, 2024

Uh oh!

clokep commented Dec 10, 2024

Uh oh!

andybalaam commented Dec 11, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

richvdh commented Dec 17, 2024

Uh oh!

mscbot commented Dec 17, 2024

Uh oh!

richvdh commented Dec 17, 2024

Uh oh!

turt2live commented Dec 17, 2024

Uh oh!

AndrewFerr commented Dec 19, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

andybalaam commented Mar 25, 2022 •

edited by turt2live

Loading