> [Spaces] come in three main flavours:
This is what I still find confusing about spaces. How do I create each of these 3 different flavours? Is there a default flavour? Do I have to upgrade a personal space into a private/public space?
This is what I still find confusing about spaces. How do I create each of these 3 different flavours? Is there a default flavour? Do I have to upgrade a personal space into a private/public space?
Personal Spaces are just a special case of a Private Space where you haven't invited anyone else. It's worth calling out this use case separately, as we've otherwise seen users assume that Spaces were only for shared hierarchies, when in fact anyone can create a Space and put whatever rooms they want in it to create a personal system of organization, even if those rooms are already in other Spaces.
If you want to turn your Personal Space into a shared Private space, you can invite people via the button on the Space's summary page. If you want to open it up to the Public, that's in the settings menu accessed from the same page.
The distinction is artificial. I mostly want public or private spaces to regroup existing rooms, so the "private" space that wants to force me to create new rooms (in element) is a bad fit.
I also think it's a bit early to come out of beta without peeking: you have to be joined to subspaces as well so that sub-rooms are sorted.
Because you understand rooms at a different conceptual level than me. And that by itself is a good thing. But the rest of us still needs more explanations/analogies.
The thing that is still missing for me: How can spaces/rooms contain other rooms? For example, could someone create a sub-room of #matrix:matrix.org?
> Because you understand rooms at a different conceptual level than me. And that by itself is a good thing. But the rest of us still needs more explanations/analogies.
Yep, you hit the nail on the head.
On the Matrix/spec side, we ensured Spaces are generically useful and flexible enough to organise rooms. However, in testing and research we found users have specific goals in mind when organising conversations, which the Element UX speaks to.
It's not dissimilar to where Direct Messages are today. Early thinking behind DMs in Matrix was that they're just rooms with few participants. In practise, there's a bunch of other semantics (e.g. room name/avatar exclusively informed by the other users profile, continual re-discovery of existing conversations when creating new ones, etc) which need to be met for them to be intuitively usable by more people.
I maintain that for technical-minded people like me, knowing a bit of behind-the-scenes can help a lot with understanding (it did with git).
> How can spaces/rooms contain other rooms?
They don't per se. It's a list of rooms that's part of the room state. The room doesn't contain anything else than pointers to other rooms, like a linked list. And then other room-related stuff, like an avatar,name,memberlist,ban list, etc.
-------
For the technical explanation: what's a room in Matrix? The basic functionality is to store some data. There's three different kind of data: ephemeral (online/offline "presence" state, typing notifications...), persistent (part of the history: join, leave, message, attachment, etc), and state (room name, avatar, member list, etc). You can define your own custom data.
The added value is replicating that data across servers (that includes re-syncing after history diverges, like a CRDT), and checking it against some rules (somebody cannot join if they've not been invited and the room is private, or read history).
So spaces are just rooms, which indicate a special type ("m.space") in their state/creation event. Also in that state, they contain addresses of other rooms. Some of these rooms can be spaces as well.
--------
I'm not sure about a layman's perspective, but for me it always clicked that:
- rooms are just places where you can chat with other people
- you can be alone in the room, in which case stuff you write there is for yourself only
- you can later share that room with someone else
- or make it publicly accessible, maybe also discoverable by publishing it in the room directory
That permission model is quite intuitive IMO. If you create a google doc, it's the same. I often create rooms, set the avatar and permissions before inviting people over or making it public.