51–60 of 129 posts
For what it’s worth, the thing I find really exciting about Spaces is that they provide a way to create a decentralised global hierarchical directory structure for realtime data. It’s like a free-for-all global USENET hierarchy that anyone can curate or contribute to, complete with decentralised ACLs. Or like DMOZ but for chatrooms. We haven’t published a “root” space as Matrix.org yet (as the “subspace” hierarchy fe…
That's awesome for teams to focus on just work conversations but unfortunately not enough. We've completely switched our work communication to a self-hosted matrix+element with SSO, so we can be sure our matrix auth is secured the same way our other internal services are. However, some of us also have personal matrix accounts which are offline during work hours and corporate accounts are offline outside of work hours…
I think that is a great idea.
Earlier quoted context omitted.
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 specifie…
Can an existing room be moved to a space ?
Earlier quoted context omitted.
I'm a big fan of Matrix becoming more Discord-like. I've been in many small to medium group chats and internet communities over the last decade. About everyone I know from those jumped over to Discord shortly after it came out, and its structure ("servers" that are easy to create by anyone being the main unit which contains not only channels but a member list, roles, and moderators instead of having those each per-ch…
I fully agree. The Slack model of having a different login per "server" is good for workplaces, but Discord is incredibly good for "communities", hobby groups, and other casual groups. As suggested by another commenter here, a hybrid model would probably be ideal for Matrix, where you could log into different spaces with different accounts if you want, but aren't forced to. I would go one step further and propose tha…
[0]: https://addons.mozilla.org/fr/firefox/addon/multi-account-co...
Earlier quoted context omitted.
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…
> 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?
> 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.
That's awesome for teams to focus on just work conversations but unfortunately not enough. We've completely switched our work communication to a self-hosted matrix+element with SSO, so we can be sure our matrix auth is secured the same way our other internal services are. However, some of us also have personal matrix accounts which are offline during work hours and corporate accounts are offline outside of work hours…
For what it’s worth, the thing I find really exciting about Spaces is that they provide a way to create a decentralised global hierarchical directory structure for realtime data. It’s like a free-for-all global USENET hierarchy that anyone can curate or contribute to, complete with decentralised ACLs. Or like DMOZ but for chatrooms. We haven’t published a “root” space as Matrix.org yet (as the “subspace” hierarchy fe…
Earlier quoted context omitted.
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…
> 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?
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.
I use spaces to organize different bridged services, Whatsapp, Instagram, Telegram, Signal and Matrix itself. As a subset of rooms to organize a team, I think it would make more sense to host a separate matrix instance. But it can be nice to give access to a set of rooms in a public community akin to: - General - Dev Product A - Dev Product B - Watercooler - Sysad
I do this with spaces too. But it occurred to me that I'm essentially abusing spaces to act like client-side folders/groupings of rooms. Can you create a space that's only for "personal" use, if you are not an admin of your home server? Spaces are a great feature, but I think clients will start needing to add grouping/tagging somehow, in addition.
Yes
For what it’s worth, the thing I find really exciting about Spaces is that they provide a way to create a decentralised global hierarchical directory structure for realtime data. It’s like a free-for-all global USENET hierarchy that anyone can curate or contribute to, complete with decentralised ACLs. Or like DMOZ but for chatrooms. We haven’t published a “root” space as Matrix.org yet (as the “subspace” hierarchy fe…
I hadn't thought about the possibility for spaces to replace the room directory, although it will always be needed to some extent.
Spaces could also be useful for moderation/reputation, child rooms (and users) could inherit some score from a space. It should be possible to compute the shortest distance between two spaces from a user's perspective. Even stuff like ignored users could be part of a per-user space used for computing "reputation" points. Kind of a space-based social graph.