3 ms·

I dislike that distinction a bit. Spaces are just like rooms. You can just create one (that's a personal space), invite some people in (private space), and make

I dislike that distinction a bit. Spaces are just like rooms. You can just create one (that's a personal space), invite some people in (private space), and make it public with a public link (public space). 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.

vaylian 5y ago
> I dislike that distinction a bit. Spaces are just like rooms 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?
- nadc 5y ago
  (Blog post author here). > 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.
- MayeulC 5y ago
  Ah, sorry. I guess it took some time for me to grasp that, and I am now subject to the curse of knowledge. 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.

vaylian 5y ago

> I dislike that distinction a bit. Spaces are just like rooms 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?

nadc 5y ago
(Blog post author here). > 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.
MayeulC 5y ago
Ah, sorry. I guess it took some time for me to grasp that, and I am now subject to the curse of knowledge. 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.