Allow upgrading Spaces

[Mikaela]

Your use case

What would you like to do?

I would like to be able to upgrade spaces.

Why would you like to do it?

I would like to upgrade spaces from version 6 to version 7 in order to get knocking support (which however is blocked on element-hq/element-web#18655) as a simple abuse mitigation method or version 9 in order to have subspace membership dependent on a top space or to a future room version which will surely bring something nice in the future.

How would you like to achieve it?

Considering spaces don't appear as rooms, I think I would like to have a button in advanced settings next to or below opening developer tools.

Have you considered any alternatives?

I cannot think of any alternatives.

Additional context

I was unable to find to find a prior issue, while I am certain I am not alone thinking of upgrading spaces.

[t3chguy]

The issue with upgrading spaces is the room upgrade API might not copy over the room_type field from the m.room.create event, I think Synapse has been updated to fix this but without a way for the client to know if their server will do the right thing, this should also be added to the spec so other implementations don't upgrade a space into a boring plain old room.

[Mikaela]

Is there a spec issue about this that I could follow?

I have another scenario of a community that spawns X rooms and has so far been inviting everyone to rooms manually and we would possibly like to have a space requiring being in our current main room while other rooms would depend either being in that, the updated version or the space where join rules would point to in long term.

[t3chguy]

Nope, I don't believe anyone has made one yet.

[novocaine]

As noted on element-hq/element-web#19564 - Element Android currently does this for you so you can set a space as restricted. Can't we do the same?

[t3chguy]

The issue is there's no way for a client to know if the server will have the correct behaviour, older Synapse versions and presumably non-Synapse HSes will not correctly copy the room type field over, thus bricking the Space into a Room in an irreversible manner.

[Mikaela]

As "my" users break the flow of/by joining a room before attempting to join the Space, my rooms currently require membership in Space which requires membership in a room. To remedy this, I would need the upcoming join rule knock_restricted (matrix-org/matrix-spec-proposals#3787), but this means I will need to upgrade Spaces again.

Thus I would like to ask if this issue has been thought of recently or if there is an easier way of upgrading a Space (even if by means of another client) than having to hack around in style of element-hq/element-web#19841 and manually /devtools permissions correctly to allow the older version of the Space join in addition to the rooms in it having to allow both versions of the Space.

I imagine it will take some months for matrix-org/matrix-spec-proposals#3604 to both get merged to spec and be implemented by Synapses and non-Synapses without even thinking about the time it will take for a significant portition of users to upgrade them.

[Mikaela]

Does this issue include rewriting m.join_rules in rooms that I am to replace the current room/Space ID with the new/post-upgrade room/Space ID?

Does this also include adding the old room/Space ID to m.room.join_rules if the current Space is restricted?

[t3chguy]

@Mikaela the internals of what a room (/space) upgrade actually do are up the spec & server, the client just hits the /upgrade API.

https://spec.matrix.org/v1.2/client-server-api/#post_matrixclientv3roomsroomidupgrade

[anoadragon453]

Heads up that the MSC making it mandatory for homeservers to carry over room versions on room upgrade has now been accepted: matrix-org/matrix-spec-proposals#3818

However it will be some time before this lands in a stable version of the spec.

[Mikaela]

And spec version 1.4 including that MSC was just released.

[t3chguy]

https://spec.matrix.org/v1.4/client-server-api/#server-behaviour-16

[heyakyra]

Could the workaround be documented somewhere?

[Mikaela]

Could the workaround be documented somewhere?

Which workaround and element-hq/element-web#19841 (comment) where would you like to see it documented?

[t3chguy]

https://spec.matrix.org/v1.4/client-server-api/#server-behaviour-16 still does not unfortunately copy space children over during an upgrade, and lacking a bulk state API and typical rate limits upgrading medium-large spaces is still infeasible.

[anoadragon453]

@t3chguy even if m.space.child were added to that list, would Element be comfortable with exposing an upgrade option? That list is only a list of recommendations for homeservers.

It's worth pointing out that Synapse today does copy over m.space.child state events on room upgrade, even though it's not in the recommended list by the spec.

[anoadragon453]

matrix-org/matrix-spec-proposals#3901 also calls for copying over all state from the previous room other than per-user state and what it defines as "obsolete" state. That would also indirectly solve the blocking issue here.

[t3chguy]

would Element be comfortable with exposing an upgrade option?

That'd be a question for the product team unfortunately, its something we must be consistent about between the various Element product platforms

[anoadragon453]

cc @vector-im/product

Would Element (Web/iOS/Android) be comfortable with exposing a menu option to upgrade a Space without confirmation from the homeserver implementation that child rooms from the space will actually be copied over to the upgraded Space? Synapse v1.43+ will copy over these child rooms, but the spec does not require homeserver implementations to do so, so others (conduit, dendrite, etc.) may not.

If your homeserver doesn't support it, then when you upgrade a Space, all of the rooms you had in that Space will no longer be in there, and you'll have to add them again manually. Currently clients have no way to check whether or not this will happen before upgrading a Space.

[pmaier1]

From a product POV, upgrading room versions should actually not be exposed to the user but happen automatically. As we cannot do this at the moment for a couple of reasons and do not have plans to improve this in the near future, we agree that Spaces should be consistent with rooms in terms of versions and upgrading those as (to my understanding) you're stuck otherwise.

[anoadragon453]

From my understanding, this is now in the Design Team's court to put forward a design for an "Upgrade Space" flow on Element mobile and Web/Desktop.