A graphic that shows the hierarchy/differences of all the possible spaces/groups/rooms would be nice. Because as I understand it these are 3 different things and there are different variants of each.

Groups ("Communities") are a legacy, underspecified extension to the Matrix protocol; it's best to ignore them as they will go away soon. Spaces are the properly specced replacement for Groups.

From a user perspective, Spaces are containers which can hold an arbitrary number of Rooms or other Spaces. Like Rooms, Spaces can be public, private (invite only), or "restricted" (only joinable by members of another specified Room or Space).

At a technical level, Spaces are actually implemented as Rooms.

In Matrix, Rooms maintain state. Spaces are just rooms whose state indicates that they should be treated as a space ("type": "m.space" on the m.room.create event), and which have pointers to other rooms/spaces which it considers as children (m.space.child events). This means that a single Room can exist in many Spaces, as membership points from the space to its children, rather than in the opposite direction.

Where can I find the Space specifications? I don't see it in the main documentation (https://matrix.org/docs/spec/), and "matrix spaces specification" in a search engine does not return anything relevant.

In this case, the parent spec change for Spaces was MSC1772: Matrix spaces (https://github.com/matrix-org/matrix-doc/pull/1772).

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.

I'm really frustrated that:

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.

> effectively impossible for any non-element client to support at release time

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.

Thanks for explaining this to me. I really appreciate it!

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.

Gah, I'm so sorry that happened to you. I'm glad the error message worked so at least the room owner was aware that you weren't able to move into the new room.

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...

Apparently they're on 1.34, on the latest-but-one nixos stable, and can't upgrade to latest nixos stable because of an unrelated openldap issue. That's not on you.

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

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.