You may also want to look into MSC2946: Spaces Summary (https://github.com/matrix-org/matrix-doc/pull/2946) and MSC3083: Restricting room membership based on membership in other rooms (https://github.com/matrix-org/matrix-doc/pull/3083).
These will manifest in a published version of the spec when we next cut one of those (soon!). We're also working on a new design / platform for the spec docs at https://spec.matrix.org/ which is where it should appear.
a) Stuff like this gets released in the wild without being part of the spec making it effectively impossible for any non-element client to support at release time
b) Any room that gets added to a server that supports spaces is no longer accessible to anyone whose homeserver isn't running the non-spec-compliant protocol from an unreleased version of synapse, because the default room version is 9 and synapse's latest release doesn't know wtf that means
It's really annoying that something that is supposed to be the pinnacle of interoperability and federation breaks compatibility like this.
b) Not true; spaces don't require room version 9. IIRC the only space-related feature that needs a room upgrade is "restricted rooms", ie. the ability to make a room accessible only to members of another room/space.
While I understand where you're coming from, it's just not the case in this instance:
Cinny, a one-man project, landed support for Spaces several weeks ago. FluffyChat, which wrote its own complete Matrix SDK in-house, supports Spaces. Nheko, which also rolled its own stack of client libraries, supports Spaces.
If your client of choice does not support Spaces, it very likely will soon.
> Any room that gets added to a server that supports spaces is no longer accessible to anyone whose homeserver isn't running the non-spec-compliant protocol from an unreleased version of synapse, because the default room version is 9 and synapse's latest release doesn't know wtf that means
I believe you're unfortunately mistaken on a few points here. We really did put a lot of care and consideration into how we rolled this out, and I'm sorry that we've somehow failed you. In particular:
1. "the non-spec-compliant protocol": Spaces followed the normal, public process for spec change proposals documented at https://spec.matrix.org/unstable/proposals/. The related MSCs have merged, and thus Spaces have been accepted as part of the Matrix Spec. They've not yet been incorporated into a versioned release of the Spec, but the MSCs are there, enumerated, and ready for implementation.
2. "an unreleased version of synapse": Actually, the past eight releases of Synapse have supported Spaces by default.
3. "the default room version is 9": The default room version is still 6, which is universally supported across the publicly visible federation as seen from matrix.org. Room version 9 is only used when a client explicitly requests the creation of a "restricted" room (a room which is private, but joinable by members of a given space).
4. "synapse's latest release doesn't know wtf that means": The past two releases of Synapse understand version 9 rooms, and only the latest release instructs clients that they should use version 9 when creating restricted rooms. We monitored the upgrade rates of servers publicly visible to matrix.org to ensure that the majority the population was on a version of Synapse which supported Room Version 9 before we cut a Synapse release which informed clients that they were allowed to create v9 rooms.
But v9 rooms are a red herring: Spaces can contain rooms of any version, and clients still default to creating v6 rooms except when explicitly asked to create a "restricted" room. It's simply not the case that a room getting "added to a server that supports spaces" means it's "no longer accessible" to anyone. Adding a room to a Space does not change the room's version, or any state within it. Rooms are only upgraded to v9 through direct, intentional action on the part of the room's owner to switch the room to a "restricted" access model. At which point, yes, your homeserver needs to understand that, which current Synapse releases do.
Where I'm coming from is getting dumped out of a room that switched to spaces, and the room's server's admin telling me they got an error message that my homeserver does not support that room version, and my homeserver's admin saying they're on afatk the latest stable release of synapse, and then checking the spec and finding no mention of that room version at all. This is an absolutely trash user experience and certainly colored my response. As it is, I can't speak in said room and the room admin doesn't know how to fix that and neither do I.
The problematic room's server's admin must have been misinformed in this case, that's where I have the info about v9 being the default.
Synapse 1.42 and 1.43 both support Room Version 9, and should be available pretty much everywhere. Do you know what distro your homeserver admin is running? Looks like FreeBSD and Ubuntu might be lagging, but Arch, Debian, Docker, Fedora, openSUSE, etc. all look fine. If you're on Ubuntu, we maintain our own repository with debs for the currently supported Debian and Ubuntu releases: https://matrix-org.github.io/synapse/v1.43/setup/installatio...
I talked to the room admin and apparently when they create a new room (latest synapse, latest element) it gets set to v9 by default and they can't do anything about it.
let
newerPkgs = import (builtins.fetchGit {
name = "release-21.05-pkgs";
url = "https://github.com/NixOS/nixpkgs/";
ref = "refs/heads/release-21.05";
rev = "8d6407e5a442e5e2fc50c3ca36411b6995afbc17";
}) {};
in
and then reference newerPkgs.matrix-synapse in their environment.systemPackages?I may have the syntax slightly wrong, but something like that.
Edit: Ah, except Synapse is a service, so things get a little more complicated. https://nixos.wiki/wiki/FAQ/Pinning_Nixpkgs has some pointers.