The wording in this document makes it sound like the actual spec PR may have different "mechanics" than outlined in this document. Specifically, the phrase, "might look like"

Sorry, that phrasing was really just an artefact of the text being copied from an earlier proposal where things were less certain. Now updated.

I just want to be clear that if the actual way that room versions work ends up being different than outlined in the mechanics section of this document, a new spec proposal will be made before a spec PR is merged, right?

It's likely that, as I implement this, I'll discover things that don't work out as planned. If that happens, I'll update the doc and highlight the changes here.

Room versions are supposed to mark changes in mechanics for both clients and servers, right? But the way the proposal is worded, it seems to say that servers get to set the default version of rooms.

Correct.

Room versions are supposed to mark changes in mechanics for both clients and servers, right?

Yes, it's likely that some changes that might be supported by a room version bump will require client-side changes to support (an example would be: changing the way bans work so that bans are stored in a separate m.room.ban event rather than an m.room.member event. In order to figure out who has been banned from a room, a client would have to look at a different sort of event).

Does this mean that outdated clients will no longer be able to create rooms that they can use on servers that set a default room version other than 1?

Will clients be able to override the default room version when creating rooms (this only partially helps with previous point since many clients may not be aware of room version at all)?

These are interesting questions which I suspect we haven't thought about hard enough.

I think that, for testing future room versions if nothing else, the ability to override the default version is going to be important.

I'm hesitant to have an "I only support v1" flag on createRoom (or the inverse: "I do support v2"), for two reasons:

I think "rooms they can use" overstates the case here. For many changes, there will be no need for clients to be changed at all. For many others, 90% of the functionality of a room will continue to work. That would lead to a lot of rooms being created on old room versions when there is no need.
Obviously, it's not just the client that creates a room that needs to worry about the version of a room. Any other client that belongs to a user who has joined a v2 room needs to behave sanely in the presence of v2 rooms.

An extreme solution to the latter would be to extend the format of /sync so that v2 rooms are listed separately to v1 rooms, so that v2-unaware clients don't see the v2 rooms at all. We'd also need support on the /join API and others so that v2-unaware clients don't end up joining a v1 room by mistake.

Right now, I'm minded to hold fire on this, and make it more of a case-by-case judgement based on exactly what changes are happening: some changes will require significant changes to the C-S API, and others will be invisible to clients, and we should pick a solution accordingly. I'm certainly open to discussion here, though.

Will the spec continue to include sections about old room mechanics even as version 2 gets rolled out? It seems that it should since homeservers at least must implement both version 1 and version 2 room mechanics. Clients for a while probably ought to as well.

Absolutely. I think @turt2live is working on some refactoring of the spec to make this a more tractable thing to do.

In theory, could the version of a room affect how a client interacts with it before they've joined the room? ...

In theory, yes. In practice: it's just a particular case of the more general questions about client interaction above.

Room Versioning #1425

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions