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 feature is still in beta), but I cannot wait to kill off the public room directory for Matrix.org (which is a total tirefire atm) and replace it with decentralised hierarchies of rooms that the community can moderate and curate like any other content.
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…
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.
Space hierarchies already have a binary social graph effectively in the form of their decentralised ACLs (i.e. PLs etc). You could group MSC2313 (https://github.com/matrix-org/matrix-doc/pull/2313) reputation lists into a space hierarchy though to curate them though... and assign reputation to spaces similarly to rooms via MSC2313 too.
That sounds amazing. Something I’ve been wondering is if matrix supports specifying custom UIs for rooms somehow. For example, could a room have the ui of an issue tracker without it being through an additional program or website?
Yup. We call this "widgets", and it lets you embed arbitrary web UI into a Matrix client. MSC1236 is the base proposal (https://github.com/matrix-org/matrix-doc/issues/1236) which Element implements, and there are a stack of other proposals on top of it which need to be merged into the main spec.
> I cannot wait to kill off the public room directory for Matrix.org
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?
Spaces also allow for pretty nice access controls.
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.
Congratulations on going out of beta! Spaces have many interesting properties indeed. I read that there was some interop between Spaces and Microsoft Teams, but i couldn't find the source code. Could you point me to it?
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?
Wow! I always think these can be somehow generalized: Uber, Craigslist, Facebook Market, ebay. Connecting buyer/seller. Maybe it will be possible to index/search through Matrix and connect people together better?
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 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.
Yup. Multiaccount is desperately needed in Element. Other Matrix clients (FluffyChat, Quaternion, possibly Nheko?) have it already though)... plus you can always cheat and just open Element in multiple browser tabs :)
I got around the single-account limitation on Element by installing a work profile on my Android phone using Shelter[1]. I initially spotted this from HN while we were looking at migrating from Slack to Matrix and I wanted to keep my personal account separate.
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.
Definitely not, I'd still preferr to have proper multi-account support over having to use a work profile on Android (or multiple profiles if using a browser).
yeah, I've done this too - it's pretty simple and effective for getting 2 accounts for anything. though it's a shame that it's only limited to 2, since it's not like all people have only 1 job...
... but it's quite far from actual multi-account support, so I do think that's still necessary :)
I one corporation they used pagers exactly for that emergency situation, some techies just wanted a smartphone timeout at weekends etc (aka don't have to check your phone every 30minutes). But if the pager rings you know it's something serious.
> forbids using matrix as an emergency contact method
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?
This seems to built for people with a lot of rooms/people. I think it's a classic mistake to enable it for all users, and I see it in all kinds of products. Everyone starts out by building something simple, but eventually it's bloated with features that I don't need (I'm sure someone does).
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.
You’re right that spaces aren’t useful if you’re only in one room(!). Just like a mail client doesn’t need to support mail folders if you only ever have one conversation going on. As others have said, we’ll add the option to hide the spacepanel if you want. Also, you may want to just use a much simpler Matrix client (eg https://hydrogen.element.io - the lightest element!) if you’re only in one room.
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.
Hello! Hydrogen sorely needs 2 basic things to make it usable as a daily driver - separate DM one-on-one conversations away from Rooms and add a Dark mode toggle. These two things push me back to app.element.io, must-have not nice-to-have things for me. Thanks for listening.
Thanks for your suggestions. We've just had another look at the upcoming priorities for Hydrogen and I can confirm that both of those things are planned for the not-too-far future! Hard to commit to exact time frames, but you've been heard :)
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.
I don't recall Teams ever being "snappy". It has always felt like a half-broken beta product.
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.
I like when they embed views (e.g. PowerBI) in it, but as soon as you click off it to see a message and click back, it has to reload it all. It's like IE6 - a pre-tabs browsing experience.
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.
This isn't helpful for less technical users but most embedded browsers have an option to open what you're looking at in the real version preserving state. I find this handy to quickly peek at something while conceptually still in the app that opened it, and then go to a real browser if necessary.
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).
Oh I thought it would only do group text chat when it first went live (still in beta).
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).
I think this feature enables a much more discord-like environment, in which case it totally makes sense why they enabled to for everyone.
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.
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-channel) is such an upgrade over everything we used before, to the point I was baffled that the design wasn't more copied by others. (Yeah I know that IRC is somewhat similar, but the differences make all the difference. Anyone being able to make a "server", it having a graphical identity, being able to join it through a link, that you don't register in an arcane way on each one all over again with an unconnected identity, that you get channel history, that it's integrated with voice/video chat channels, and that you're a member of all channels in it are all huge factors in how they shape their social spaces and get used.)
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 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.
I should clarify that I prefer using desktop applications and would rather not have to chat in a browser window (even if the desktop application is technically a web browser internally).
Neither Slack nor any of the Slack clones can figure the most simple of things: tabs.
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.
I think MS Teams is worst about this, because they have so much functionality crammed in the app.
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.
This may be heretical but... I just use Element in my browser. If I need another tab, I open another tab. Did the same thing when I worked at a company that used Slack.
It's not just tabs. I am in so many damn Discord servers and Matrix rooms that I want to be able to view, filter, sort, and modify them in a table. I want to be able to do bulk operations. I want to be able to tag them and group them into hierarchies, with a UI that promotes doing such things, rather than obstructs.
Someone please make a Matrix client that looks like VSCode.
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.
https://cancel.fm/ripcord/ is a client with tabs for Slack and Discord. Unfortunately it does not provide all the functionality of the web interfaces, though.
Also technically you can get banned from Discord for using third-party clients. Some people have used it and gotten away, some people weren't so lucky.
In Element (on desktop at least) spaces act like tabs to order the massive vertical list of chats. On mobile these spaces are hidden in the slide-in menu.
You still need to go through the whole process of creating a Space even if it's just some place in a chat that you want open while you're having a conversation in another chat.
You still have to use the same window to switch between them.
If i read things properly, the spaces concept is not specific to the Element client (available per the underlying matrix protocol)...so technically, any other client could in fact apply a different UI/UX approach to displaying the spaces, such as tabs...again, if i'm understanding things accurately. So, maybe other clients could implement something more to your liking (such as tabs)??
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.
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.
> 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.
Moreover, the Matrix spec process requires that you have proven that a proposal actually works in the wild before it’s merged into the spec. This is a feature, not a bug. Just like browser vendors demonstrate a feature behind a prefix before it makes it into HTML, so do we with Matrix… to avoid a situation where the spec contains vaporware or spec for the sake of spec.
a) Agreed; the fact that spaces aren't in the spec is annoying when trying to stay spec-compliant and not realizing you also have to search through various GitHub issues to be fully informed. Granted, spaces have been one of the most hotly-discussed topic in Matrix development for months, so anyone interested in making anything Matrix related likely would have come across it.
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.
Note that rooms don't "belong to" a space, like discord channels belong to a server. You can create a space to group related rooms together for yourself or your friend group, for example.
I found the Ansible playbook [1] on GitHub extremely easy to use. As long as you know how to configure DNS records and firewalls, the rest is taken care of. This is what I use today to manage my Synapse server.
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.
It's also important to read the docs for that ansible playbook, know what certbot does, setup the nginx proxy accordingly or remove the nginx proxy. Maybe I should have done this on a mint machine.
I wish there was a good Discord:Matrix bridge but I've never been able to get anything useful working nor does it seem like Discord will ever allow something like that on their platform.
Spaces are a superset of tagging. Just create a space (tag) and the rooms that you want to tag to it. If you want it to be just for you keep the space invite-only, if you want to share your "tag" you can.
To elaborate, Element even explicitly asks if you want to do that (even if I understand it correctly, it's the same as a private space without other members)
A week ago, I noticed that Element Desktop was starting to hide "rooms in spaces" from my home screen, which now only contains rooms not in a space.
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.
> 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).
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.
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.
Are there any plans to add granting permissions to roles based on space membership (perhaps spaces which are not room's ancestors in any hierarchy but instead a cousin) instead of gradual power levels? And also sharing those permissions across all rooms in a 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?
Which you click the "Create a Space" button in the sidebar, you get a clear prompt to choose between "Public" and "Private" (and a note that you can change this later in the Space's settings).
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.
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.
> 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.
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.
With Spaces shipped I want to recommend Element for my engineering conference. Unfortunately, Element on mobile is still more complicated than FluffyChat -- compare our install guides [0]. I feel the cost of Element when people e-mail me for tech support.
The fact Fluffy instantly lets you sign-in makes Element lag behind in UX, which matters a whole lot for transient conference goers.
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.
I have suggested integrating with Mumble before, it would be a great way to interact.
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.
No, you can't just hop into a room and be connected via audio sadly. One of the biggest things preventing me from using matrix as a replacement for discord
Cool, cool. I wonder if non-botching of newlines, paragraphs and quotes is anywhere on the roadmap. Apparently that's the hard problem for Element, especially the Android version.
It depends entirely on what you do with it. joining a big room like Matrix HQ (27K users spread over 3000 servers) now takes 700MB of RAM. But smaller rooms should be pretty trivial.
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…