Spaces launch in Element
element.io
element.io
Add in voice/video rooms, async comms (messageboards, forums, mailing lists, newsgroups), decentralised metaverse worlds like thirdroom (https://youtu.be/e26UJRCGfGk?t=2263) and then you end up with a skeleton for a whole open universe of interoperable communication.
Next up: decentralised search for discovery as well as decentralised hierarchies…
This is how Element embeds Jitsi today, and was extensively used for FOSDEM 2021 (https://matrix.org/blog/2021/02/15/how-we-hosted-fosdem-2021...). We're currently adding "full-screen" widgets too, though, as well as "inline widgets" (for polls etc).
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.
I didn't realize that Spaces would finally allow for this! The public room directory is a horrible user experience today and really turns people off. I'm so glad that your team recognizes that too!
So is the idea that each Matrix server can have their own root Space that they direct people to? Kinda like an "instance timeline" in Mastodon?
So that you can prevent most cases of bots just collecting all history. And because you can nest spaces, it also allows basically ad hoc organizing.
For example, on a open source project you could have a top space for it itself, then subspaces for contributors, users, code reviewers and such. In the code reviewers space you could then have one where confidental issues can be discussed.
Related: i've read most of the specs API but like all specs in decentralized RFC ecosystems (W3C, XSF, MSC) but i find it hard to understand what version of what document is currently implemented. Is there a document summarizing all APIs/concerns for this feature, and/or a document specifically intended for interoperability with other networks/protocols?
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 which forbids using matrix as an emergency contact method. It would be great to either ability to sign into multiple accounts or an ability to sign into a single space using account other than the default one.
Works surprisingly well for my use-case (keep work stuff separate on Element) and even allows me to disconnect completely from work by simply turning off the profile.
[1]: https://github.com/PeterCxy/Shelter
Edit: added note about using Android
... but it's quite far from actual multi-account support, so I do think that's still necessary :)
It's either obtrusive to the UI, or completely hidden.
Stack accounts at the OS level, or close to it.
Your advice to run a separate browser tab is by far the best — even if on mobile.
I think that is a great idea.
I think it's good policy that your work communication tools are unavailable outside of work hours. It's actually mandated by worker protection laws in many countries (France included).
But if your work contract specifies you have compensation for staying reachable on an emergency basis, why not have a dedicated emergency channel where both personal and work accounts are subscribed?
Personally, I use matrix every day. However, it's only for a single room. With this new feature, I lost 70 "pixels" (or 140 actual pixels) of horizontal space.
Like it or not, discord has taken the market for a lot of younger software projects and geeky communities. If we could get them to use foss matrix instead that’d be a huge win.
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 that you should be able to have multiple Element windows open, so you can have your "work" space or spaces in one window, and your other spaces in another window.
[0]: https://addons.mozilla.org/fr/firefox/addon/multi-account-co...
[0] https://getferdi.com/ [1] https://help.getferdi.com/services/multiple-accounts
In general, Spaces reduce bloat though - they speed up the app by reducing the amount of data the app has to juggle as you filter based on a given space, and they stop your UI and brain being clogged up with irrelevant rooms.
It started as a Slack knock-off. Not a great one, the UI is too low density and the multi tenant support sucks unlike Slack's. But it was relatively snappy. And free for O365 users. But lately they've been adding many apps, Wikis, all these fancy meeting modes that make it seem like everyone is in a theatre and many more fluffy things.
Now the app is so slow it takes more than a minute to start up. It often crashes with stupid error messages "Oops! Something went wrong!" that give zero indication of what actually happened.
At the same time MS is heavily pushing companies to adopt it but they're devaluing the product as they go by making it some kind of Swiss army knife with all the trimmings.
They're now realising the performance issue and moving away from Electron towards Edge webview but I think what it really needs is a proper architectural review. They've been too focused on beating the market adding new features and its core functions have suffered.
The one thing I liked about it was the balance of "threaded conversation" and "chat" that it promoted with its UI, which was good for the data science team I was on at the time. Of course nowadays I would suggest using Zulip for the same purpose.
On some mobile apps (Gmail, Discord, Telegram, etc. On Android, never used a modern iOS device to know the situation over there) there are embedded browsers enabled by default, but they are not very persistent and have no actual browsing UI.
My mom was buying something from a link she got from a friend, and was unable to complete the transaction because she had to open another Telegram conversation to get the payment details (hey don't judge non-techy people's organization skills!), but of course going back means leaving the browser-view, so once she had the details at hand she couldn't go back to the store to finish the purchase.
That would be "fine" if there were a consistent UX to "no, i really mean to open this on my browser app, not on an embedded view" or if embedded views were opt-in, but as it stands, it is one of the classic attempts at "simplifying" things that actually makes the whole ecosystem more complex and obscure.
More like a Webex Teams knock-off, as MS went after the Unified Communications space (group chat + video meetings, though they still lack contact center and hybrid meeting hardware).
But it could be that voice/video calls were blocked by our IT because at that time WebEx was our approved tool (not WebEx Teams, just the regular scheduled meeting tool).
Instead they all insist on having just one window with a 10-kilometer long list of rooms/chats/channels on the left that you have to switch between in a single window.
This becomes especially frustrating when you have several active chats going on at the same time, or when you want to retain some info on the screen while answering in a separate chat/channel.
You still have to use the same window to switch between them.
These are not tabs.
I constantly find myself switching between the Calendar view / channel view when planning a meeting, or between channels when referencing a PDF shared in the "Files" section of a different channel. Super annoying.
The editor of the current file is the current opened room, and tabs to switch between rooms. The explorer shows rooms as files and spaces as folders that can be expanded/collapsed. Also support for keyboard shortcuts like CMD+P to quickly open a room.
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.
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
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.
Element has hosted instances for 10$/month and discord bridges for 20$/month?
Does anyone else run hosted matrix instances with bridges? I might pay 10$/month for that.
Or, are there AMI instances for that? I couldn’t find any.
Also Oracle Cloud offers free ARM instances with 4 CPU cores and 24 GB of RAM, more than enough to run a very speedy Synapse server.
[1]: https://github.com/spantaleev/matrix-docker-ansible-deploy
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
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
That's exactly one of the intended purposes!
I really don't like how Element Android has you separately pick which space to view (in the sidebar), and whether to look at DMs or rooms (in the bottom bar). Now I often end up picking the KDE space, but only showing DMs, which results in an empty view (because I've only joined KDE-related chats, not KDE-related DMs).
I think I'd prefer a list of spaces where I can set rules for what goes where. For example, I want to create a space called "Contacts", where I first manually pin my "self-room" for note-taking and test messages to the top, then ask Element to add all DMs I'm in, ordered by "most recent" or manual order. Then I want a space called KDE where I place specific KDE-related rooms inside. Then have a space called "Rooms" with the leftover non-KDE rooms.
In the process, I'd remove the Android client's bottom DM/room selector (unsure what to do with the notification tab), replace it with 2 "default spaces" in the left sidebar (one for DMs and the other for rooms, but with user-customizable rules), and let user-created spaces coexist alongside the two default spaces.
The end result would work something like a hybrid of Telegram's automatic rules, Discord's single DM namespace followed by a server list, and Matrix's current spaces system. Unfortunately, it seems Element has officially released the Spaces feature, ignoring (or not even seeing) my feedback a week ago in the Matrix HQ room. I don't know if they're still accepting changes to how spaces operate.
Yes, switching between a DM in one space and a room in another takes at least one tap too many. Hopefully this paragraph in the article expresses the intention to work on this:
> Clearer interfaces: To make Spaces, Rooms, People, Direct Messages, Favourites and your conversation history easy to find over time, every time.
To change this behavior, enable "Show all rooms in Home" under Settings > Appearance
The information architecture of Spaces as presented in Element isn't perfect, and is at the top of the list of improvements we'd like to make as we iterate on the feature.
Releasing out of beta doesn't mean we intend to stop iterating on Spaces - it simply means we think the feature brings enough value to share it with everyone and open it up to the whole user base for feedback.
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.
The fact Fluffy instantly lets you sign-in makes Element lag behind in UX, which matters a whole lot for transient conference goers.
It's actually a native app. It's mostly Objective C, but increasingly written in Swift. https://github.com/vector-im/element-ios
There is clearly room for improvement, but apparently they just hired a handful of new iOS developers to work on it. Good things should be coming soon.
But Matrix is an open protocol that everyone can improve. The Specifications Change Proposals are open to everyone willing to formalise the change they want, get it reviewed, and implement it so it works in practice.
And there is a Matrix Spec Change going in the direction of Discord-like voice chat rooms! (https://github.com/matrix-org/matrix-doc/blob/matthew/group-..., and in particular https://github.com/matrix-org/matrix-doc/blob/matthew/group-...)
Add a "info.mumble.servers" or "info.mumble.channels" state event, some magic on murmur's side to authenticate using Matrix, and roll with it in your own Matrix client. Pinned messages with mumble:// URIs could be used as a fallback.
One of the issues is that upstream mumble lacks support for websockets, so web clients are impossible. Otherwise, it sounds quite promising.
I even suggested something along these lines, but haven't had time to cook up a prototype: https://github.com/mumble-voip/mumble/issues/1813#issuecomme... (there seems to have been some back-and-forth on that idea since then).
I guess this is good too.