MSC3757: Restricting who can overwrite a state event

[andybalaam]

Rendered

Implementations:

• Support MSC3757: Restricting who can overwrite a state event element-hq/synapse#17513
• rtc: Handle non-MXID call member event state keys matrix-rust-sdk#3836
• Loosen type of call member event state keys ruma/ruma#1885
• Add tests for MSC3757 complement#733

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

Shepherd: @AndrewFerr

---

SCT Stuff:

FCP closure tickyboxes

MSC checklist

[ShadowJonathan]

One nit, else this looks sound.

[turt2live]

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.

[andybalaam]

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

[clokep]

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.

[fkwp]

I think there’s general agreement that string packing is not a great long-term idea. This is not only a topic in the context of this MSC but also in the context of MSC4143.

The reason it’s being considered is that it’s an pragmatic change — lightweight for SDK maintainers to adopt and gives already (amongst others) the nice feature of pragmatic name-spacing which is a powerful property.

In contrast a big-bang change is disruptive and complex. Probably leading to a situation where nobody currently has time to implement it.

Hence, I am proposing deliver value without disruption (=using string packing) over disruptive and complex

[Xiretza]

Despite frequent appearances to the contrary, matrix is intended to be a production-quality protocol, not some finished-over-a-weekend demo. You don't do "pragmatic" hacks in such a project, especially not for a new feature. If the feature requires "complex and disruptive" changes, so be it - this PR has been sitting around for three and a half years now, it can wait a couple more until those changes are worked out.

[richvdh]

Right now, I am minded that the problems with this proposal (fundamentally: it's a hack that we don't want to have to support in the long term) outweigh the advantages of landing it swiftly.

[Xiretza]

Is "attempts to pack structured data into a JSON string" not a valid concern in the opinion of the SCT?

[turt2live]

Please use threads for conversation, as otherwise there's a 95% chance we'll never see it.

The string packing concern is tracked as alternatives not being sufficiently explored, per https://github.com/matrix-org/matrix-spec-proposals/pull/3757/files#r2192809774

[dkasak]

To be honest, it's not clear to me that MatrixRTC call events should be state events. Call state is very ephemeral information, while room state is generally meant for longer-lived state, like room configuration.

Areas where room state did end up being used for quicker evolving information are precisely those that showcase many problems with such an approach: the need to retain stricter ownership over a subset of state events; the need to allow less privileged users to send state events, which brings about state spam concerns; the large volume of events calling for a mechanism to delete state, which turns out to be an almost impossible feat. Not to mention that state events in today's Matrix are unencrypted. It all screams bad fit to me.

I realise this is coming a bit late to the party given when MatrixRTC implementations are already running in the wild. But given that this is used as the sole example of a requirement for this MSC and there is widespread dissatisfaction with string packing, I think it needs to be raised.

[kegsay]

I second this. State events is the wrong place for this data, and by putting it in this wrong place we are creating a rod for our own back. String packing is, in the words of other people, a horrible hack. Does it work? Undeniably yes. Do we want to bake this into the protocol permanently? No. This is precisely the job of the SCT to block this kind of thing imo.

Now this does beg the question: what is the right place then? I've banged on internally that there isn't really a right place for this kind of data currently, and have been spending my downtime slowly crafting a proposal for an alternative. Effectively, all we want is:

• Custom EDUs which can be sent by clients
• persistent EDUs which guarantee delivery of the latest value sent on a per-room, per-user basis.

Thus sending a state event only you can modify becomes a persistent EDU (quite an oxymoron given the E stands for Ephemeral!) with whatever custom type/content you want.

The main driver for this MSC afaict is MatrixRTC so we can even drop the "custom" part for now and only have fixed known EDUs for now to reduce the scope and risk of the changes.

I'd be much happier to thumbs up a persistent EDU proposal than shoehorn in owned state events.

[richvdh]

State events is the wrong place for this data

Agreed.

Apart from the ephemerality of the data, another thing that makes it different to room state is that there is never any real reason to do state resolution. We only ever care about the "current" state, and (unlike regular state) there is a single server that can and should be trusted to be authoritative.

[kegsay]

I'd be much happier to thumbs up a persistent EDU proposal than shoehorn in owned state events.

#4354 is this.

[MadLittleMods]

Related conversation in the Improving the security of the federation protocol Matrix Conference 2025 talk by @kegsay. Some general notes:

• State is for when you need conflict resolution
  • For setting the m.room.name, there can only be one m.room.name so you need conflict resolution
  • We should factor out things that don't need to be in state. Stay in your lane traffic (CALM theorem) like profile information (and MatrixRTC) should not be in state because it doesn't need conflict resolution
• Would be good to get guidelines in the spec for when to use state vs the newly proposed sticky events vs to-device messages and EDU's to prevent people from abusing them in the future.

[turt2live]

This MSC is blocked on conversations around possibly using non-state-events for VoIP becoming resolved.

[turt2live]

The SCT has determined that this MSC will not be accepted, and is (currently) favouring approaches like MSC4354 instead.

@mscbot fcp cancel
@mscbot fcp close

[mscbot]

Team member @turt2live has proposed to close this. The next step is review by the rest of the tagged people:

• @clokep
• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @tulir
• @erikjohnston
• @KitsuneRal

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[MadLittleMods]

Suggested change

	there noneless exist resolvable domain names that contain underscores.
	there nonetheless exist resolvable domain names that contain underscores.

[mscbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[mscbot]

The final comment period, with a disposition to close, as per the review above, is now complete.