MSC4168: Update m.space.* state on room upgrade

[Kladki]

Rendered

Implementations:

• Synapse (partial, just copying m.space.child to the new room): element-hq/synapse@63f28e4
• Continuwuity: https://forgejo.ellis.link/continuwuation/continuwuity/pulls/907

---

SCT Stuff:

FCP tickyboxes

MSC checklist

[tulir]

Implementation requirements:

• Server

[nexy7574]

continuwuity has a complete implementation of this MSC: https://forgejo.ellis.link/continuwuation/continuwuity/pulls/907

[clokep]

Synapse has a partial implementation (it copies m.space.child): element-hq/synapse@63f28e4

[clokep]

MSC3385 seems to mention spaces but doesn't really make a proposal. 🤷

[clokep]

I think you want to keep the old m.space.child events and just add the upgraded one so that upgraded rooms properly appear in the right space? I'd be curious of the algorithm that Element Web uses when you upgrade it.

[Kladki]

The reason I didn't want to keep the old m.space.child event is because otherwise in the space you would see both the old and upgraded room, likely leading to confusion due to them both having the same icon, description, name, etc.

[clokep]

The alternative is that the old room then gets kicked "out" of the space, which I think is more confusing? Element clients don't show rooms which are upgraded if you're also in the upgraded room, I'm unsure how common that is in clients though.

[Kladki]

AFAIK Element is the only client to do this. Personally I haven't seen anyone confused about kicking old rooms out of the space when I have done upgrades, so I'm not sure whether that's true or not.

[Kladki]

Also, I think Element would still display both rooms if you are in neither the old or new room, since it wouldn't be able to know that one was an upgrade of the other.

[MadLittleMods]

The other problem with doing this is it prevents future people from joining if it uses restricted (inherited) m.room.join_rules.

I also created a dedicated spec issue around this problem: matrix-org/matrix-spec#2194

[Kladki]

This can be instead addressed by adding m.room.tombstone to the list of recommended stripped state events.

[Kladki]

Sorry, I meant adding room upgrade details to room summaries/space hierarchies, but the above is something that should probably be done anyways.

[turt2live]

I'd suggest leaving whether to kick the children out of the space to the implementation as an implementation detail for now. It's likely that Synapse will do so, but other servers might not. If we find we need a way to control that behaviour, we can always open another MSC.

[turt2live]

It's unclear to me if we want to be more prescriptive in the room upgrade process: matrix-org/matrix-spec#1906 exists for discussion.

[TheArcaneBrony]

I don't agree that this is a good solution - infact, copying far too much stuff is exactly why I avoid the entire upgrade endpoint in all circumtances, and manage tombstones/creation myself... I would be more interested in making the entire copy events thing opt-in instead (and configurable via passing either a list of event IDs or type/key pairs to replicate, or a DSL to pick and transform items...)

[Kladki]

I think that would be better suited in another MSC (however, this (your) suggestion has it's own issues, e.g. especially the first bullet point here, but all of them apply to some extent).

[turt2live]

MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands.

SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable.

MSC authors: feel free to ask in a thread on your MSC or in the#matrix-spec:matrix.org room for clarification of any of these points.

• Are appropriate implementation(s) specified in the MSC’s PR description?
• Are all MSCs that this MSC depends on already accepted?
• For each new endpoint that is introduced:
  • Have authentication requirements been specified?
  • Have rate-limiting requirements been specified?
  • Have guest access requirements been specified?
  • Are error responses specified?
    • Does each error case have a specified errcode (e.g. M_FORBIDDEN) and HTTP status code?
      • If a new errcode is introduced, is it clear that it is new?
• Will the MSC require a new room version, and if so, has that been made clear?
  • Is the reason for a new room version clearly stated? For example, modifying the set of redacted fields changes how event IDs are calculated, thus requiring a new room version.
• Are backwards-compatibility concerns appropriately addressed?
• Are the endpoint conventions honoured?
  • Do HTTP endpoints use_underscores_like_this?
  • Will the endpoint return unbounded data? If so, has pagination been considered?
  • If the endpoint utilises pagination, is it consistent with the appendices?
• An introduction exists and clearly outlines the problem being solved. Ideally, the first paragraph should be understandable by a non-technical audience.
• All outstanding threads are resolved
  • All feedback is incorporated into the proposal text itself, either as a fix or noted as an alternative
• While the exact sections do not need to be present, the details implied by the proposal template are covered. Namely:
  • Introduction
  • Proposal text
  • Potential issues
  • Alternatives
  • Dependencies
• Stable identifiers are used throughout the proposal, except for the unstable prefix section
  • Unstable prefixes consider the awkward accepted-but-not-merged state
  • Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
• Changes have applicable Sign Off from all authors/editors/contributors
• There is a dedicated "Security Considerations" section which detail any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.". See RFC3552 for things to think about, but in particular pay attention to the OWASP Top Ten.

[turt2live]

@mscbot fcp merge
@mscbot concern TravisR - Decide to either always update children of spaces, never update, or leave it as an implementation detail (my preferred choice)

[mscbot]

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

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

Concerns:

• TravisR - Decide to either always update children of spaces, never update, or leave it as an implementation detail (my preferred choice)

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.

[anoadragon453]

Note that rooms can also be upgraded by sending an m.room.tombstone into the room. We shouldn't exclude copying over state events in this case, just because the user didn't use /upgrade.

[MadLittleMods]

👍 For more context on this point, there is a recent case in Synapse where we don't handle this kind of thing.

[clokep]

I don't think that's an 'upgrade' necessarily though? I'm not sure servers should be doing special logic in that case.

You might send a tombstone to redirect to a different room or "close" it.

[turt2live]

We historically have not considered manually sending tombstones as "upgrades" in the protocol. The spec wants callers to perform upgrades using the endpoint, not by sending events manually.

[MadLittleMods]

There is some nuance here.

The whole problem is that from the remote homeservers perspective, it doesn't matter whether you've used the /upgrade endpoint or not. It just looks like a m.room.tombstone was put in the room either way.

In the case I mentioned around push rules and where I think @anoadragon453's point is spawning from, I think it does make sense to copy push rules over whenever the homeserver notices the room was upgraded (m.room.tombstone and new room has a predecessor). Copying push rules is something that can only be done by the local homeserver for the user. And it doesn't make sense to handle this for remote rooms but not local rooms. This kind of discussion is probably why that clarification probably deserves it's own MSC.

(same with copying over local aliases and room tags) -- Anything that the local homeserver has to do.

Whereas in this case, a local homeserver doesn't need to take any action about space state in the room when it notices a m.room.tombstone. All of the action is from the person doing the "upgrade" (or sending the state) and can manually transfer state as they see fit.

In shorter words, I don't think we should copy over m.space.child or m.space.parent when a m.room.tombstone event is sent.