I used to host a homeserver for myself up until very recently, but during their most recent conference, some folks decided to conduct a harassment campaign where they repeatedly posted CSAM in the Synapse Admins channel. Synapse didn't really offer me any built-in tools to preempt that sort of behavior - you can't even block domains. I found a third party moderation bot but it didn't look quick or easy to set up.
Being exposed personally to that sort of thing was bad enough but making sure it wasn't persisted in backups and my S3 buckets was way more trouble than it was worth, so I shut the service down and nuked the whole thing. I was mostly hanging out in public channels and using bridges; I only had one small group of IRL friends that I talked to on it and they practically leapt at the opportunity when I suggested moving the group chat to a different platform.
I see that "Trust & Safety" is on their list of things to tackle next, so perhaps I'll check it out when they announce Matrix 3.0.
Content only gets stored on your local server if a local user downloads it by viewing it before the message or the original content gets deleted. Separately, you can block abusive servers manually if needed (e.g. https://element-hq.github.io/synapse/latest/usage/configurat...).
For instance, this is better than email, where if someone sends you email with abusive attachments, it'll end up hitting your mail spool and likely your imap server whatever.
That said, agreed that moderation and anti-abuse tooling is fragmented currently, and we're working away on improving it. Recently a lot of time got taken on authenticated media (to make it much harder to distribute abusive content): https://matrix.org/blog/2024/06/26/sunsetting-unauthenticate... but the top priority for The Matrix.org Foundation is to improve the anti-abuse situation (by securing funding for more folks to work on it).
Earlier I was writing about how its an issue in federated system , but now I have come to realisation that this is an issue in any encrypted system (even discord can have csam but it can detect it)
and to be honest , thus becomes a compromise , encrypted but you have the risk of csam or unencrypted , but to be really honest , I think considering edward's snowden blow on the nsa , I think I am much more safer in the encrypted land
here was my original post which I was writing
csam is an issue in federated systems (whether its p2p or non p2p) (source I read once on HN that some friend had created in the 1990's a sort of thing similar to chitchatter.im , only to it spread out of word and then came the csam)
I realize you're probably using this discussion about the Synapse Admins chat as a springboard to talk about encryption in general, but for anybody unfamiliar with Matrix rooms: encryption is optional, and wasn't a factor in the issue.
The Synapse Admins channel discussed by GP and GGP is not encrypted at all, and its messages are publicly accessible to anyone[1]. This means that various detection scripts could be run on messages at any time by the server, including when receiving them, and before propagating them to their database.
yes encryption is optional , and its generally not recommended in big groups but for me and my friend in a very basic group , encryption was causing problem in matrix and basically no problem in signal
for some people , encryption is a must because you never know what the govt. thinks is right or wrong and simply giving the govt. power to surveillance is quite powerful to govt. because then they can tweak that info into metaphorically speaking whatever they like.
there are entire communities based on this idea
For example r/privacy , https://discuss.privacyguides.net/ on which you rather have discussion on which protocol is more "encrypted" and "decentralized" in some sense to the extreme (like recent was simplex vs cwtch )
Very exciting! I'm particularly pleased to see the invisible encryption stuff mentioned.
One of the biggest pain points I had when setting up a self-hosted Matrix instance and getting all my devices signed in was the crypto stuff. At least in the client I use, Element, I was bombarded with tons of popups with vague "Upgrade your encryption!" prompts upon logging in the first time. The copywriting on the "Security & Privacy" page was less than helpful in illuminating what I was actually "upgrading" or setting up, since specific technical terms (e.g. recovery key/security phrase/security key) were all used more or less interchangeably. If that kind of confusion can be reduced or swept under the rug for end-users, it'd be a huge improvement on user experience.
Yup. One of the biggest learnings of E2EE in Matrix is that the complexity is 95% user experience. However, in Element X, we've been determined to get it right - although there is still some temporary UX in there while full-blown Invisible Crypto is still rolling out (as it requires a breaking change to stop encrypting/decrypting with unsigned devices - the equivalent to a browser refusing to talk TLS to self-signed certs).
Standardized terminology is an awesome step. I'd love to see some of standardized file format for setting up the right keys on different devices. In the past I'd had annoying issues getting all the messages to decrypt on multiple devices, especially if I wasn't using the same client every device. Honestly though I suspect I was doing something wrong.
there's already a standardised export format for message keys (although EX doesn't let you load/save it yet, mainly because online backup already solves most use cases): https://spec.matrix.org/v1.12/client-server-api/#key-export-.... If you enable backup on your clients then EX at least will merge the missing keys to/from the backup. Meanwhile, the original problem of missing keys were probably unfortunately just due to bugs - although as per https://matrix.org/blog/2024/10/29/matrix-2.0-is-here/#4-inv... we've done a huge amount of work to improve this now, and they should be really unusual now (at least when due to bugs, rather than permissions or data loss or similar).
Separately, talking of standardised key formats: one of the team did a skunkworks hack last Friday to experiment with a standardized file-format for user public keys - a kind of basic key transparency ledger for Matrix, to help with bulk-verification within orgs.
If you want to host a homeserver but feel overwhelmed about the amount of services you'll have to host (especially if you want to have bridges to other services), check out matrix-docker-ansible-deploy [1]. It's pretty much a set and forget experience with reproducible deployment, and the documentation walks through any decision you need to make.
Ironically i just spent all weekend writing a new "quick start" guide for Matrix 2.0 deployments using docker-compose (so you literally just set some env variables, `docker compose up` and that's it; no ansible involved). I just shifted to the debugging phase, but once it's ready, it might be even easier than matrix-docker-ansible-deploy as a super-fast way to get started :)
Having more deployment options and quick-start guides is always great!
That said, the Ansible playbook provides various benefits that you cannot currently get with any other Matrix deployment method. For one, it seems to be the only deployment method that supports hundreds of Matrix and related services which all tie together nicely.
Getting started quickly and easily is an important part, but is not the end. Most people will sooner or later need "that extra service" (bridge, bot, etc.) and it's always a hassle to get it added to a "quick & dirty" deployment.
Using the Ansible playbook, enabling an extra service is usually one extra line of configuration and you're up & running with a deployment that has been battle-tested and improved by hundreds/ thousands of others. You're not alone debugging a hand-made "Synapse worker configuration" or "Matrix Authentication Service" integration - there are many others iterating on the same exact setup.
Another compelling reason to go with the playbook is maintaining your deployment over time - handling major Postgres version upgrades, backups, uninstalling old/deprecated services (to replace them with newer alternatives), etc.
Yes, Ansible can be slow and clunky (and the YAML format is definitely annoying), but it seems like a reasonable tradeoff that provides plenty of benefits.
I'd say the primary benefit of ansible is it makes you document everything. It's easy to simply set and forget with tools like docker compose, but then when you need to change something again, you have to recall what you did originally and fix that.
yup, although i'm hoping that a self-contained docker-compose repo that you don't need to edit will help with that (rather than it being a homespun docker-compose setup, which i agree can rapidly become unmanageable).
ansible just feels a bit slow & cumbersome for simpler setups, so i'm using envsubst for basic templating to see how it feels. It's perhaps telling that something like Rocket.Chat just has `docker-compose up` too: https://docs.rocket.chat/v1/docs/deploy-with-docker-docker-c... and it's annoying that Matrix doesn't have something that simple (especially given Matrix 2.0 has more moving parts serverside: auth + voip server).
For me the benefit of the ansible playbook is that it installs not only synapse and element web but also a ton of bridges and other services like the chatgpt bot. It handles the configuration of those etc.
yup, totally - and the quick-start thing i'm playing with (just got it working!) is not a replacement for that at all. it's just literally providing a solution for people who want to type `docker compose up` and have something immediately working, but without all the bells and whistles.
can you give it a codename that's not impossible to remember if you do add such a docker? something that is likely I'll be able to remember it in a couple of months?
I'm Aine of etke.cc, and yes, we can ease your pain by managing the server part of the matrix on your behalf, be it on-premises or hosted in the cloud by us.
Alternatively, you can just get your server managed by https://etke.cc - the developers of the MDAD paybook - and not worry about the server part at all
I'm sorry to hear that you got overwhelmed and gave up on Matrix!
Below, I'll try to explain why it can overwhelming and how one might navigate things better.
While the Ansible playbook's documentation is huge (which can be both good and bad), one does not necessarily need to read through everything to get started.
The playbook's documentation tries to guide you through the required steps to get started and always tries to suggest "skipping ahead" and staying with the recommended defaults. It does mention additional services, but branching off into reading about esoteric additional features from the very beginning is not necessary.
It's better to follow the steps and start with the basics. You can add additional services and tweak the existing ones later on at any time.
That said:
- just like a production-ready email system is complicated to deploy, so is Matrix (even with the Ansible playbook). Some learning and planning is necessary. Important decisions (with regard to domain names, etc.) need to be made upfront
- the playbook's documentation may benefit from a new and dedicated "quick-start guide" which would not even mention most or any of the additional services. This could help people get started quicker, instead of making them give up due to analysis paralysis
As for the latter, there are various articles (blog posts) online where people guide you through using the playbook (they act as a "quick start guide"). A downside to those is that some may be out of date and/or skip through steps which may turn out to be important later.
The playbook's documentation is extensive, because it not only aims to get you running, but to also instill knowledge as to how things work so that you're more capable of managing the deployment later on. It's a bit like the Arch Linux Wiki in this regard - it gives you more to read (and walls of text can be scary), but is also there for you for when you need help.
> Why would someone use a walled-garden instead of a protocol ?
Because it actually works. I've tried countless of times to use Matrix with different groups of people and every single time there comes a point after a few days where one of the participant can't read messages from another, or can't send messages anymore, etc. And that's was even the case with computer literate people (computer scientists or developers).
So yes, I see your point and in a world where Matrix actually does work and is simple to self-host, your point would be entirely valid. Sadly in real life, setting up a Mattermost instance is easy and it just works, while Matrix, even without the hassle of self-hosting, doesn't.
>Why would someone use a walled-garden instead of a protocol ?
>It's a very similar feeling for Bluesky.
Is this actual wondering on your part, or are you just rhetorically framing these as questions, as a means to express frustration? I mean, it's extremely easy to come up with an answer: they are much better-known platforms, have much larger user bases, and provide simpler and quicker initial access. That's all there is to it. In the case of Bluesky, though, you have to take into account the political stances surrounding how the platform is viewed as well.
> I mean, it's extremely easy to come up with an answer: they are much better-known platforms, have much larger user bases, and provide simpler and quicker initial access.
Can you share your sources for the "much larger user bases" ? It's hard to get the figures, I just googled them for 5 minutes and got contradictory results. Some pages say 30 million daily active users (DAU) for discord, some say 150. Slack seems to be at 30 million.
For Matrix, the official site says "The open network has grown from 80.3M to 115M addressable users." but there was only "250 DAU" in january for matrix.org, the public instance. The French gov's deployment of Matrix says 0,3 million DAU. https://element.io/case-studies/tchap
Could you please recommend a guide for how to set up something like a Slack/Discord replacement with Matrix? Do I understand correctly that this will be self-hosted?
I find it very difficult to get good solid information on actually using Matrix in the ways I use Discord.
I'm with you. but matrix is failing adoption for the same-ish reason as PGP.
You create an account from scratch, means using two (three) centralized services. matrix.org. vertex.org. (and the third is possible your email provider which would be either gmail.com or icloud.com)
Then you get a password, recovery keys, recovery passphrase, session keys. And have to know what to do with them all.
Not sure how it improved on v2, but recently i had friends doing literal PhD on cryptography code having to create a new account because they forgot to save one of those keys when replacing phones.
The reality is that worst case, it should feel like a laptop (username, password (unless using SSO) + recovery key) or a cryptocurrency wallet.
With the v2 crypto, you typically don't have to remember anything - you just scan a QR code to log in.
If you've logged out all of your devices then yes, you need username + password (unless using SSO), and then if you want to recover your encrypted history you need the recovery key.
It's true that the UX historically was awful, but on Element X i believe we've got it right (and Element Web/Desktop will shortly follow).
Self-hosting is possible but optional. You can create rooms/spaces on matrix.org or any other matrix server of your choice. If you want control over your data, you may want to self-host, but if you consider Slack or Discord to be acceptable for your use cases, you can probably use a standard Matrix server without any issues.
You can create a "space" that's pretty close to a Discord server. Spaces include rooms ("channels") or even other spaces. This means you could set up a "Friends of pixelpoet" space with a bunch of channels like on Discord, but also a "pixelpoet Corp" server with in it spaces for "General", "Project Jabberwocky", "HR", and "Janitorial staff", each with their own rooms and ACLs inside of it.
How I would approach your setup: I would create a new space, then create a few rooms in that space (your #general, #games, #offtopic, etc). I'd also maybe add a "video room", which works a bit like Discord's audio/video channels, though not many clients support those yet (I think they're in beta?).
Then, go to the "space home" (as Element calls it), and make sure to check every channel, and set the "mark as recommended" flag, so that people joining the space will be guided to join all of the channels as well. It's possible to join a space but not join all channels, which can be useful for some but is probably pretty awkward for most. People that don't join all channels still can join after the fact, but you probably want everyone in every room by default.
For larger servers, you want need to configure ACLs before letting people in. Do note that unlike on Discord, settings change for a Space do not apply to rooms that are included in it automatically; you may need to manually alter ACLs for every room or find a bot to do it for you. If it's just a space friends or coworkers, you hopefully don't need to bother, though.
Then, to get other people into your "server", invite them to the space, or share a generated link. Just right click the space and pick "invite".
If you like the Discord UX, you might want to try Cinny, a Matrix web client that's pretty much a Discord clone in terms of design. It doesn't support everything Element supports, but it's good enough that I'd be willing to recommend it to others if they're not the ones setting up the server.
For data safety, you can leverage Matrix's encryption feature to end-to-end-encrypt everything even if you're storing your space on another server. This can have some annoying side effects (like people losing access to their old messages when they forget their recovery password, because, well, they're encrypted) and using the feature securely requires a) verifying other people and b) verifying every device you log into with another device or by entering a backup key. This is harder than in other messengers but it's also a more secure design. Could be useful if you don't entirely trust Matrix.org, could also be useful for setting up channels for sharing sensitive documents, but it's probably best for general usability to disable encryption at first. I enable encryption everywhere, but I don't think encryption/decryption is trouble-free enough that I'd be able to convince my friends to fully enable it in chat rooms as well.
I'm not sure I'd call Discord a walled garden. Officially, it is a walled garden, sure, but there's a huge variety of different clients you can use [0]. Not every client supports every feature but Matrix clients are no different in this aspect. The API Discord's official client uses is fairly well-documented, too [1].
It's a walled garden in the way that matter most, which is that if the things inside the wall get back, you can't take your account/social graph and go outside the garden.
It's generally difficult to make people move away from well-established platforms. Would Matrix be a walled garden if it was the leading communications platform?
Exporting all your account data is very easy with Discord, and you can even export entire servers with bots. Doesn't seem like they make it particularly difficult to move away from their platform.
I've had Element X installed for a while -- couldn't use it for a while after EMS shut down their small instances and I started self-hosting, but it works with my self-hosted Synapse now.
The only problem is that it's got too many paper cuts. I can live without Spaces, even though I use them on Desktop. But notification channels are a harder sell, and missing avatars on notifications is just annoying. Neither are exactly core features, but notifications are the most common way I interact with Element on mobile and for me, the improvements (and there are many) aren't worth the downsides.
> But notification channels are a harder sell, and missing avatars on notifications is just annoying.
huh. on Element X iOS, the notif support is genuinely great - you get avatars and groupings and reliable notifs on e2ee msgs. the only thing is missing is quick-reply (which has been blocked behind full multi-process support in matrix-rust-sdk, hopefully coming soon).
I'd assumed that Element X Android would be the same; if not, it's an omission and will get fixed.
> I'd assumed that Element X Android would be the same; if not, it's an omission and will get fixed.
Aren't you Element's CTO? I feel like you shouldn't need to make assumptions into how the app works, you should just know (even if you're not personally daily driving it). If not you, is anyone in charge of ensuring that the project's vision and goals are met?
yup, i'm the CTO, and I don't have notifs enabled on Android and so hadn't checked - I daily-drive iOS. The folks "in charge of ensuring the project's vision and goals are met" are the ones running the Element X team - sorry that I haven't memorised the full feature parity matrix :) Sounds like https://github.com/element-hq/element-x-android/issues/1547 is the bug for you to upvote & subscribe to.
I’m in south east Asia and I have a lot of friends using matrix but the whole is unbearably slow to me. Most of the time it takes more than 10 seconds to sync and messages don’t go through. I’d be happy to look at the infra to see what’s happening though. It’s also what breaks my notifications on iOS.
Element X has a few notification issues on Android (I use it daily): you don't get quick reply (which can be fixed by adding conversation shortcuts in Android), and you get a notification for every single message. Element X doesn't stack up the notifications, so if someone floods you 20 lines of text in less than 10 seconds, your phone will vibrate 20 times in under 10 seconds. It's quite annoying.
I treat Element X as an alpha client. Half the features I use aren't implemented and I get signed out every few weeks. The parts that do work, work very well, but the parts that don't are
After the last update, I can't seem to log in anymore, which is a first. Fluffychat is my go-to on mobile these days. It supports Material You, which I like, and does things like notification channels well. It still has the occasional bug and I get the feeling it's consuming more power, but it's the best Android client I know of in terms of features versus stability.
From what I've read, most of the Element X work seems to have been put into iOS, because Android has had a few app rewrites over the years already but the iOS version was still based on some very old code base.
Does this change anything for notifications? I've had to pause using Matrix (self-hosted Synapse plus Schidichat for Android after Element had the same issues) to talk to my friends because we routinely get shit like:
- Message is sent to the server but nobody else's phone gets notified about it for minutes / hours
- Message just can't be sent to the server even though the sending phone has Internet and a desktop web client on the same account works great
If the problems were caused by issues in the old Element Android (or Schildichat) app then yes - the Element X rewrite will likely fix it. It supports UnifiedPush, so if you're self-hosting a push gateway it should nicely integrate (as does Schildichat Next).
If the problem was in your push infrastructure, then the new app won't fix anything - however, UnifiedPush should be reliable these days (especially if you host your own instance; some of the shared ones are overloaded and/or deliberately throttle Matrix push). FCM obviously should be reliable too.
I have the opposite problem with Element Desktop. I hear messages coming in on my phone but it takes up to 10 seconds before they appear on the web client. Really annoying.
Off topic but I love the YouTube player interface. Instead of loading it by default (and adding invasive Google tracking to the page), you get the option to opt in. Very nice.
I tried navigating to youtube-nocookie.com and got an http cert error, so that doesn't seem like an option.
The support page you linked to talks about "Privacy Enhanced Mode". The language there does not sound like it really protects privacy.
> The Privacy Enhanced Mode of the YouTube embedded player prevents the use of views of embedded YouTube content from influencing the viewer’s browsing experience on YouTube.
So they're not promising not to track users. They're saying they won't use their tracking to personalize anything.
I just opened Element X, tried to decline some spammy invite - "sorry, unknown error occured". Tried opening backup section in settings - "sorry, unknown error occured".
what server is this on? (as these sound like serverside issues). please can you submit debug logs so we can take a look? needless to say, this shouldn't be happening.
I join from the official matrix.org server.
It also federates to Gnome server and maybe some others, but they never synced properly so I never used it.
Congratulations to the Matrix team. I look forward to trying out everything this release offers and seeing how I can implement in the organizations I work with.
Are there any plan for improving the desktop version of Element? E.g. by porting Element X to the desktop. Or should I look for other Matrix clients? I feel the Element team with their limited resources sadly cannot keep Element Desktop in the shape it needs to be to be a great client.
Yup. On macOS you can use the iOS build of EX already today (i daily drive it, and it’s very usable). Meanwhile, I built an unreleased prototype of a possible EX Desktop which uses Tauri + matrix-rust-sdk (codenamed aurora) - weirdly enough it feels almost identical to Element X iOS, which makes sense given all the heavy lifting in EX is matrix-rust-sdk.
Separately to the aurora experiment, the Element Web/Desktop codebase itself is starting to move to a MVVM model to support swapping out the underlying SDK (e.g. for a WASMified matrix-rust-sdk) and avoid an Element X Mobile style rewrite. That said, making matrix-rust-sdk work on WASM is not trivial (especially if you want to avoid maintaining two different FFI layers for wasm-bindgen and uniffi).
Another track is that matrix-js-sdk is also sprouting Simplified Sliding Sync support - I even demoed it in the Matrix 2.0 talk: https://youtu.be/ZiRYdqkzjDU?t=617. And it already has Next Gen Auth and Element Call support. So there's also a chance that "Element X Web/Desktop" just ends up being an evolution of the current codebase - I guess this is the default path right now.
Finally, there are other clients built on matrix-rust-sdk - e.g. GNOME Fractal is shaping up to be an excellent fully native GTK4 Rust desktop client, and given it shares the same engine as Element X, is suspiciously similar in terms of capabilities and perf (although I can't remember if they've enabled sliding sync yet). https://gitlab.gnome.org/World/fractal
Any plans for a mac catalyst version of element x?
I recall Rust was a blocker for that a few years back, but after I fixed Rust’s mac catalyst support to enable fat builds of matrix rust sdk for it, it turned out there was another blocking library.
the UIKit app has weird scaling and doesn’t have the nice macOS translucent sidebar/toolbar etc
So I did a catalyst build of EX a while back (which is where https://github.com/rust-lang/rust/issues/106021 came from) - but rather anticlimactically the end result looked almost identical to the normal iOS app when running under macOS; I don't remember the sidebar/toolbar looking particularly better, and that was my main reason for doing the build in the first place (to get a flexibly resizable left toolbar). The main advantage seemed to be that it would run on Intel.
If things have improved I'd love to know, and then perhaps we'll have another shot at it. Are there any good comparison screenshots of the two approaches (with a toy app, i guess) anywhere?
I think the benefit is more that you get access to AppKit APIs. This lets you integrate with the OS the way users expect.
For example wrt scaling, Apple’s Mac Catalyst guide says:
> When you first create your Mac app using Mac Catalyst, Xcode defaults to the “Scale Interface to Match iPad” setting, or iPad idiom. With this setting, the system ensures that your Mac app appears consistent with the macOS display environment without requiring significant changes to the app’s layout. However, text and graphics may appear slightly less detailed because iPadOS views and text scale down to 77% in macOS when you use the iPad idiom. For example, the system scales text that uses the iPadOS baseline font size of 17pt down to 13pt in macOS.
So you gotta change that setting, and then use whatever SwiftUI components (or straight up AppKit APIs) allow for that native look :)
I agree that an amazing Desktop client would be great, and that most likely there's a need to prioritize where efforts go at the moment.
For now, maybe check out Ferdium. AFAICT, it's just a wrapper app for web clients, but even this might solve some shortcomings of the official desktop app (e.g., cleaner usage of multiple profiles).
Is Synapse still the only Matrix server implementation that is not in beta? The matrix.org site seems to suggest as much, but I don't know how up to date that is.
yes, unfortunately. Dendrite almost got out of beta, but (very frustratingly) we didn’t have the $ to keep developing Synapse and Dendrite fulltime - so we consolidated on Synapse, given it was already mature and deployed everywhere, and are focused on rewriting the hot paths of Synapse in rust and generally improving Synapse’s perf and scalability rather than maintaining both go and python servers.
Meanwhile Dendrite is getting maintained best effort by the former team as time allows.
Finally, the other main area of server dev right now is Conduit (conduit.rs) - a pure rust impl targeting small selfhosted servers. Conduit itself has slowed down recently but there are two very active forks: Conduwuit and Grapevine. All three are beta however.
It's unfortunate that dendrite is on life support. I've been using it for a long time to contact family in countries with high censorship.
I want to migrate to conduit or a fork of it but can't find any docs on how to do that. Would rather not spin up a server from scratch as breaking existing accounts would mean a complete loss of contact with some people that would need assistance to even sign up.
Of course, I'm not switching just for the sake of it. I've had a ton of bugs with dendrite suddenly taking up gigabytes of memory when federating (turned the feature off) and somewhat random crashes
yup. it's gutting that nobody has put $ behind the bar to support it. the entirety of Reddit chat is/was built on Dendrite, but they (and many others) chose not to put money behind it, unfortunately.
Its room based. Each room is synced between all servers used by participating members. But if you have a room with only people from 1 server, that metadata stays on that server.
Is it possible to configure this so that the metadata remains on the server by restricting access to only those users who are not members of any other servers?
It's not about being a member of a room on another server, but the homeserver of the account itself, of all the members of the room, must be local to that same server as the one that created the room in the first place.
I don't think there's a setting for "only allow people from X server", but you can make the room private and only invite people from that particular server.
P2P Matrix is a dialect of Matrix where the server runs inside the client itself - see arewep2pyet.com for details. In other words, there are no servers (other than optional store-and-forward relays). It's insanely cool - you can see a demo at https://www.youtube.com/watch?v=eUPJ9zFV5IE&t=2192s. It's also unfunded and on hiatus until someone provides some $ so we can work on it again.
Right now, normal Matrix is a client-server model: you can't send messages from a client without it talking to a server (and then to another server, and then to another client). MatrixRTC VoIP and Video calls in Matrix 2.0 also go via server (for now), in order to support multiple participants and firewall traversal.
Obviously, both messages and calls are end-to-end-encrypted (other than in public chatrooms), which makes it less important that they go via a server today.
I'm sure there is p2p funding available on the sidelines. Give us an actual opportunity to privately sponsor it.
I am sure you have heard the dismay of people who would like to sponsor Firefox but only really have the option to finance the Mozilla Foundation, who put the money elsewhere? Some similar feelings here.
Unlike the Mozilla Foundation, if someone came to Element (or the Matrix Foundation) with a large bag of $ and asked for it to specifically fund P2P, then a conversation could definitely be had.
That is not enough, it is not certain, and it makes people more hesitant to spend money. I agree with another comment that mentions BTC and XMR, but it must go directly to P2P, or alternatively, people should have the option to choose specifically how their money is used.
The main issue here is uncertainty. If I contribute funds, what guarantee do I have that the money will actually go toward supporting Element P2P? This uncertainty is a major barrier for many.
Just put up Bitcoin and Monero addresses already? You/we can't possibly expect to rely on traditional centralized funding to chip in for for decentralizing the control and power over communication...? We want to fund this.
I guess the question was how to fund progress on P2P specifically. Everything you listed most likely will not go anywhere near P2P. If it were so, it would be be unfunded in the first place.
What a stupid statement! They certainly have money and decided to not invest into P2P. And now they make it seem like the reason that it is unfunded is because of outside factors. Whoever wrote this should be fired...
Is it possible with Matrix to run your own server but let Matrix.org handle authentication? I always thought for many that's probably best of both worlds.
What benefits does this have? You'll still have to have a server running and you lose control of your account, if I'm understanding what you mean (letting matrix.org handle accounts).
User friction. My problem is this: I'm in a bunch of Discord Server/Guilds but watching Discord Inc., it's clear that they are ZIRP powered and it might come crashing down in massive fireball. However, if users have 5 separate logins, they are not going to convert over.
I realize the implications of "What happens if you get Matrix.org account banned?" but that's next week problem.
It’s federated anyway, similar to email. One account can take you anywhere, so if you make your own "guild" the users could just directly participate from matrix.org (or any other home(server))
I'm a big fan of Matrix, but I'm embarrassed to recommend it to my friends until Element X supports audio calls... It's been months since the leading-edge release, and I don't know what to think: there's Element Call, however it's neither supported by Element X nor real alternative to legacy peer-to-peer audio calls.
Element X natively integrates Element Call for voip/video calls - this is one of the core things of this week's release. If you hit the video call button, it'll start off with video muted, and it should behave like a voice call (although there are a few bugs in the integration still, hence it being marked beta - especially on iOS, where CallKit + WebRTC stopped working in iOS 18. We're trying to work with Apple on it.)
I don't want to turn off the camera in the video calls; I wish to have normal audio-only calls like in any other app like Whatsapp where there's a "Phone" button that starts a call.
Excellent. This is basically my only use for Matrix because encrypted video chats, 1-to-1, and now many-to-many (YES!) are the only thing Matrix does better than IRC. I started using Matrix video chat to talk to family during the early pandemic and sort of got used to it.
I've been on-and-off hosting for a while and I avoided synapse because it seemed to rely on a lot of different services and python packaging is hell. Seems like dendrite is dying (which I did not know until now), conduit and siblings are very much beta and not close to being stable.
If I read this correctly there is just one server worth actually using (synapse) and two client libraries (matrix-rust-sdk and matrix-js-sdk, both maintained by the same org/people).
At the same time most of the bridges to other protocols (which was one huge selling point of matrix) are either broken, outdated, alpha (and by that I mean really, really alpha) or beta (usually in a stagnant state or alpha-ish).
One of the goals (perhaps the primary?) of matrix was to build a protocol that is supported by multiple servers, clients and bridges but that does not seem to have been realized.
I just listened to the keynote on matrix 2.0 and...
I used to be a huge proponent of matrix, but I really feel like the potential has not been lived up to.
There are loads of SDKs which work well - as well as matrix-rust-sdk and matrix-js-sdk there's also excellent fully-featured indie libraries for Dart, Kotlin, C++, Go, Python (and many other others which don't have full parity).
You're right that Dendrite is currently stalled, but it's not a reflection on the protocol, but just the reality that writing and maintaining two servers simultaneously is expensive. Meanwhile most of the good stuff in Dendrite has already made it back into Synapse. Bridge development has also stalled for the same reason (exacerbated with hostility from those being bridged) - but then 3rd party bridges like heisenbridge are doing fine.
On the other hand, conduit/conduwuit/grapevine look to be bubbling away at an impressive rate (entirely independently of Element), even if they're currently beta.
So, I don't think the potential has been lost - instead, the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent rather than being spread too thin, which is a major improvement over the past, imo. Meanwhile the broader community is busy hacking away too.
> Meanwhile most of the good stuff in Dendrite has already made it back into Synapse
But that still means there is only one actual trusted server implementation, right? I thought the point of dendrite was to be able to prove that MSCs were implementable independently before they became part of the spec. It seems like the actual spec is just whatever MSC synapse has implemented.
> Bridge development has also stalled for the same reason (exacerbated with hostility from those being bridged)
Some open protocols like XMPP (which would seem like a natural fit) do not have stable bridges. Other open protocols like email are quite limited in that they require you to act as a full service provider (actual email server instead of a bridge between an email account and matrix). Others like SMS have no stable implementation. Those are just the ones that cannot be hostile to bridging. Many of the bridges to proprietary services listed on the site have not had any activity for 2+ years (which in itself is not bad but if they interface with a moving target or changing protocol it probably is).
Is the "One chat protocol to bridge them all" goal abandoned?
> the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent
I'd love to see that. I'd especially love to see it stabilize and simplify enough that we have a multitude of servers, clients and bridges that are stable and useful. I'm just not seeing it right now.
> But that still means there is only one actual trusted server implementation, right?
Nope? Dendrite works. It's just stuck in beta for now due to lack of manpower.
> I thought the point of dendrite was to be able to prove that MSCs were implementable independently before they became part of the spec. It seems like the actual spec is just whatever MSC synapse has implemented.
The spec is not "whatever MSC synapse has implemented". The spec is... the spec, and the compliance test suites (sytest, complement) which go with it. Currently we require one implementation of MSCs to prove their validity before landing in the spec - and that could be in synapse, dendrite, conduit or wherever.
Just because the core team only has $ to actively progress a single server implementation right now doesn't devalue the spec at all. If anything it makes 3rd party implementations like the Conduits even more important, in terms of showing that the spec isn't coupled to the Synapse implementation.
> Is the "One chat protocol to bridge them all" goal abandoned?
Right now the goal is "have a decentralised open chat protocol whose apps can outperform mainstream centralised products". Bridging is secondary (for now, although Beeper is obviously focused on it).
> > the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent
> I'd love to see that. I'd especially love to see it stabilize and simplify enough that we have a multitude of servers, clients and bridges that are stable and useful.
The two are mutually exclusive. We can't simultaneously focus on getting a small number of implementations excellent... while also working on a multitude of implementations. Instead, we can make sure that the implementations that the core team works on at Element are great, solve problems, simplify things and unlock everyone else to be able to build better ones too - which is precisely what we're doing.
I’m maintaining a Matrix TUI and I haven’t updated it in forever because I keep saying I’m going to wait for the next stable Rust SDK… but I just keep waiting. Anyone know if that is planned, because without a stable release, packaging is a bit of a pain.
hm - i think it's just because they've been frantically building and haven't time to release. looks like 0.7.1 was the most recent release in Jan; will give them a prod. sorry.
how are you measuring perf? sync should be instant with sliding sync no matter how small the server is. are you talking about time to join big rooms? or resources used for participating in big rooms?
Previously, it seemed the sliding sync required a Postgres-backed Synapse installation. Does the Matrix 2.0 version of Synapse provide a seamless upgrade path for those using the default Sqlite installation?
Yes. the sliding sync proxy shim is gone; Synapse now uses its native database for sliding sync, same as the old sync API - so it works with both postgres & sqlite.
I've been looking forward for almost a decade now for Matrix (and the client ecosystem) to mature enough that it isn't so hard to get people less tech-savvy to give it a honest spin.
Here's hoping this is a milestone as good as it sounds. I'm particularly curious about the improvements in encrypted conferences, which is... A pretty darn hard to do. Even more so with Matrix's "constrains".
Glad it‘s getting more attention now. It’s quite a step towards Matrix experiences being just as good as traditional proprietary ones (though hopefully by far not the last one).
What's the upgrade process and the state of implementations for self-hosted services? The current service is beyond terrible, big hopes for Matrix 2.0.
A little too late for my team, we switched two weeks ago from Element to Zulip and the difference in communication is night and day. Features such as mentions, notifications and threads (topics in Zulip) are vastly more stable and consistent.
Does synapse support this at the moment? I can't quite tell from the writing here if/how you can run things that support this - my guess was no because it mentions improvements to the js SDK are required and there's no warning on the synapse repo. Or is that just that these features are opt-in?
Synapse now has native support for sliding sync (the new "instant sync" Matrix 2.0 API, implemented in Element X and other rust-sdk clients like iamb - Element Web has it in labs).
The other bits of Matrix 2.0 require new moving parts: matrix-authentication-service to support next-gen auth (although this will eventually get optionally embedded inside Synapse), and livekit for VoIP. Finally, invisible crypto is purely spec & client-side improvements.
As per https://news.ycombinator.com/item?id=42034324 i'm currently frantically writing a compose.yml to show how they plug together, while kicking myself for not having arranged one sooner...
That's fantastic thanks - the sliding sync part addresses an issue a client I've got would be facing at some point. I'll have to check out the details of that.
Updated to the new version of Synapse to try Element X, but went back to the regular app due to the lack of features, particularly the image resolution prompt when sending media.
That's ended up becoming a global setting, which merged a few days ago (https://github.com/element-hq/element-x-ios/pull/3467) so hasn't been released yet. We're catching up on features as rapidly as possible - meanwhile i'm surprised that the advantages of the new app donn't completely blow away the old one.
Does it have serverless P2P like Jami yet? If not, it seems like it's not ready yet.
Without true P2P every individual user still has single points of failure.
It's less disruptive if one server bans you, since people have been known to be banned for absolutely nothing, so there's some value, but not enough that I'd actively pursue switching, unlike with Jami and similar, unless I planned on doing things that make bans more likely.
They're making really good progress though in general!
they haven’t had formal independent review yet, but we will get them audited. there are relatively few changes in practice though other than fixing bugs, removing confusing UX and adding the beginnings of TOFU. Off the top of my head it’s only TOFU which would need new review.
i hope after the transition is done, there will be a focus on multiplatform e2e search, attachment tab improvements (it's fine for < 10 attachments in a chat, but not a 1000), optimized notification system so friends stop bug me with it, and of course custom emojis
Still no concepts about P2P file transfers. Disappointing. The RFCs exist and just need to be discussed. People to implement that stuff are there and ready to go.
I used to host a homeserver for myself up until very recently, but during their most recent conference, some folks decided to conduct a harassment campaign where they repeatedly posted CSAM in the Synapse Admins channel. Synapse didn't really offer me any built-in tools to preempt that sort of behavior - you can't even block domains. I found a third party moderation bot but it didn't look quick or easy to set up.
Being exposed personally to that sort of thing was bad enough but making sure it wasn't persisted in backups and my S3 buckets was way more trouble than it was worth, so I shut the service down and nuked the whole thing. I was mostly hanging out in public channels and using bridges; I only had one small group of IRL friends that I talked to on it and they practically leapt at the opportunity when I suggested moving the group chat to a different platform.
I see that "Trust & Safety" is on their list of things to tackle next, so perhaps I'll check it out when they announce Matrix 3.0.
That's terrible. I used to host a home server many years ago, though it was mainly serving as a matrix bridge.
Because of that I still idle in the synapse admins channel, though I have it muted and haven't opened it for years.
It makes me worry that csam from the muted channel could be sitting on my hard drive somewhere.
Content only gets stored on your local server if a local user downloads it by viewing it before the message or the original content gets deleted. Separately, you can block abusive servers manually if needed (e.g. https://element-hq.github.io/synapse/latest/usage/configurat...).
For instance, this is better than email, where if someone sends you email with abusive attachments, it'll end up hitting your mail spool and likely your imap server whatever.
That said, agreed that moderation and anti-abuse tooling is fragmented currently, and we're working away on improving it. Recently a lot of time got taken on authenticated media (to make it much harder to distribute abusive content): https://matrix.org/blog/2024/06/26/sunsetting-unauthenticate... but the top priority for The Matrix.org Foundation is to improve the anti-abuse situation (by securing funding for more folks to work on it).
Yeah it's a good point about email.
To be clear I'm not currently hosting my own homeserver, these days I just use matrix.org.
Hope to self host again once I can find some time.
Earlier I was writing about how its an issue in federated system , but now I have come to realisation that this is an issue in any encrypted system (even discord can have csam but it can detect it)
and to be honest , thus becomes a compromise , encrypted but you have the risk of csam or unencrypted , but to be really honest , I think considering edward's snowden blow on the nsa , I think I am much more safer in the encrypted land
here was my original post which I was writing
csam is an issue in federated systems (whether its p2p or non p2p) (source I read once on HN that some friend had created in the 1990's a sort of thing similar to chitchatter.im , only to it spread out of word and then came the csam)
it happens on matrix as well.
I realize you're probably using this discussion about the Synapse Admins chat as a springboard to talk about encryption in general, but for anybody unfamiliar with Matrix rooms: encryption is optional, and wasn't a factor in the issue.
The Synapse Admins channel discussed by GP and GGP is not encrypted at all, and its messages are publicly accessible to anyone[1]. This means that various detection scripts could be run on messages at any time by the server, including when receiving them, and before propagating them to their database.
[1]: https://app.element.io/#/room/#synapse:matrix.org
yes encryption is optional , and its generally not recommended in big groups but for me and my friend in a very basic group , encryption was causing problem in matrix and basically no problem in signal
for some people , encryption is a must because you never know what the govt. thinks is right or wrong and simply giving the govt. power to surveillance is quite powerful to govt. because then they can tweak that info into metaphorically speaking whatever they like.
there are entire communities based on this idea
For example r/privacy , https://discuss.privacyguides.net/ on which you rather have discussion on which protocol is more "encrypted" and "decentralized" in some sense to the extreme (like recent was simplex vs cwtch )
Very exciting! I'm particularly pleased to see the invisible encryption stuff mentioned.
One of the biggest pain points I had when setting up a self-hosted Matrix instance and getting all my devices signed in was the crypto stuff. At least in the client I use, Element, I was bombarded with tons of popups with vague "Upgrade your encryption!" prompts upon logging in the first time. The copywriting on the "Security & Privacy" page was less than helpful in illuminating what I was actually "upgrading" or setting up, since specific technical terms (e.g. recovery key/security phrase/security key) were all used more or less interchangeably. If that kind of confusion can be reduced or swept under the rug for end-users, it'd be a huge improvement on user experience.
Yup. One of the biggest learnings of E2EE in Matrix is that the complexity is 95% user experience. However, in Element X, we've been determined to get it right - although there is still some temporary UX in there while full-blown Invisible Crypto is still rolling out (as it requires a breaking change to stop encrypting/decrypting with unsigned devices - the equivalent to a browser refusing to talk TLS to self-signed certs).
If you haven't seen MSC4161 (https://github.com/matrix-org/matrix-spec-proposals/blob/and...) i highly recommend it as evidence of how we've made a serious effort to fix the terminology and copy - not just for Element X but across all Matrix clients.
Standardized terminology is an awesome step. I'd love to see some of standardized file format for setting up the right keys on different devices. In the past I'd had annoying issues getting all the messages to decrypt on multiple devices, especially if I wasn't using the same client every device. Honestly though I suspect I was doing something wrong.
there's already a standardised export format for message keys (although EX doesn't let you load/save it yet, mainly because online backup already solves most use cases): https://spec.matrix.org/v1.12/client-server-api/#key-export-.... If you enable backup on your clients then EX at least will merge the missing keys to/from the backup. Meanwhile, the original problem of missing keys were probably unfortunately just due to bugs - although as per https://matrix.org/blog/2024/10/29/matrix-2.0-is-here/#4-inv... we've done a huge amount of work to improve this now, and they should be really unusual now (at least when due to bugs, rather than permissions or data loss or similar).
Separately, talking of standardised key formats: one of the team did a skunkworks hack last Friday to experiment with a standardized file-format for user public keys - a kind of basic key transparency ledger for Matrix, to help with bulk-verification within orgs.
If you want to host a homeserver but feel overwhelmed about the amount of services you'll have to host (especially if you want to have bridges to other services), check out matrix-docker-ansible-deploy [1]. It's pretty much a set and forget experience with reproducible deployment, and the documentation walks through any decision you need to make.
1. https://github.com/spantaleev/matrix-docker-ansible-deploy
Ironically i just spent all weekend writing a new "quick start" guide for Matrix 2.0 deployments using docker-compose (so you literally just set some env variables, `docker compose up` and that's it; no ansible involved). I just shifted to the debugging phase, but once it's ready, it might be even easier than matrix-docker-ansible-deploy as a super-fast way to get started :)
Having more deployment options and quick-start guides is always great!
That said, the Ansible playbook provides various benefits that you cannot currently get with any other Matrix deployment method. For one, it seems to be the only deployment method that supports hundreds of Matrix and related services which all tie together nicely.
Getting started quickly and easily is an important part, but is not the end. Most people will sooner or later need "that extra service" (bridge, bot, etc.) and it's always a hassle to get it added to a "quick & dirty" deployment.
Using the Ansible playbook, enabling an extra service is usually one extra line of configuration and you're up & running with a deployment that has been battle-tested and improved by hundreds/ thousands of others. You're not alone debugging a hand-made "Synapse worker configuration" or "Matrix Authentication Service" integration - there are many others iterating on the same exact setup.
Another compelling reason to go with the playbook is maintaining your deployment over time - handling major Postgres version upgrades, backups, uninstalling old/deprecated services (to replace them with newer alternatives), etc.
Yes, Ansible can be slow and clunky (and the YAML format is definitely annoying), but it seems like a reasonable tradeoff that provides plenty of benefits.
Disclaimer: I'm the author of the matrix-docker-ansible-deploy (https://github.com/spantaleev/matrix-docker-ansible-deploy) playbook
I'd say the primary benefit of ansible is it makes you document everything. It's easy to simply set and forget with tools like docker compose, but then when you need to change something again, you have to recall what you did originally and fix that.
yup, although i'm hoping that a self-contained docker-compose repo that you don't need to edit will help with that (rather than it being a homespun docker-compose setup, which i agree can rapidly become unmanageable).
ansible just feels a bit slow & cumbersome for simpler setups, so i'm using envsubst for basic templating to see how it feels. It's perhaps telling that something like Rocket.Chat just has `docker-compose up` too: https://docs.rocket.chat/v1/docs/deploy-with-docker-docker-c... and it's annoying that Matrix doesn't have something that simple (especially given Matrix 2.0 has more moving parts serverside: auth + voip server).
Not directly related, but I feel that any references to Ansible being slow should be accompanied by a mention of the amazing Mitogen.
https://mitogen.networkgenomics.com/ansible_detailed.html
For me the benefit of the ansible playbook is that it installs not only synapse and element web but also a ton of bridges and other services like the chatgpt bot. It handles the configuration of those etc.
yup, totally - and the quick-start thing i'm playing with (just got it working!) is not a replacement for that at all. it's just literally providing a solution for people who want to type `docker compose up` and have something immediately working, but without all the bells and whistles.
Thank you for your work! Once that's done I'd love for Elest.io to add support for that. They already support running a custom Element instance.
can you give it a codename that's not impossible to remember if you do add such a docker? something that is likely I'll be able to remember it in a couple of months?
repo's currently called element-quick-start (given i'm doing it with my Element hat on to showcase EW+EX+EC as much as the Matrix 2.0 backend)
But it's not yet publicly available anywhere?
Please share the code here
well, yes - just let me finish writing it first ;P
I haven't tried them, but I've seen https://etke.cc/ suggested for dealing with a group who will "host" the server.
at the same time, we are developing MDAD playbook, referenced in https://news.ycombinator.com/item?id=42034100
I'm Aine of etke.cc, and yes, we can ease your pain by managing the server part of the matrix on your behalf, be it on-premises or hosted in the cloud by us.
Alternatively, you can just get your server managed by https://etke.cc - the developers of the MDAD paybook - and not worry about the server part at all
Disclaimer: I'm Aine of etke.cc
> If you want to host a homeserver but feel overwhelmed
I feel overwhelmed at the number of options there are in this ansible thing. Now I definitely don't want to try it either way.
I'm sorry to hear that you got overwhelmed and gave up on Matrix! Below, I'll try to explain why it can overwhelming and how one might navigate things better.
While the Ansible playbook's documentation is huge (which can be both good and bad), one does not necessarily need to read through everything to get started.
The playbook's documentation tries to guide you through the required steps to get started and always tries to suggest "skipping ahead" and staying with the recommended defaults. It does mention additional services, but branching off into reading about esoteric additional features from the very beginning is not necessary.
It's better to follow the steps and start with the basics. You can add additional services and tweak the existing ones later on at any time.
That said:
- just like a production-ready email system is complicated to deploy, so is Matrix (even with the Ansible playbook). Some learning and planning is necessary. Important decisions (with regard to domain names, etc.) need to be made upfront
- the playbook's documentation may benefit from a new and dedicated "quick-start guide" which would not even mention most or any of the additional services. This could help people get started quicker, instead of making them give up due to analysis paralysis
As for the latter, there are various articles (blog posts) online where people guide you through using the playbook (they act as a "quick start guide"). A downside to those is that some may be out of date and/or skip through steps which may turn out to be important later.
The playbook's documentation is extensive, because it not only aims to get you running, but to also instill knowledge as to how things work so that you're more capable of managing the deployment later on. It's a bit like the Arch Linux Wiki in this regard - it gives you more to read (and walls of text can be scary), but is also there for you for when you need help.
Disclaimer: I'm the author of the matrix-docker-ansible-deploy (https://github.com/spantaleev/matrix-docker-ansible-deploy) playbook
Now that I use matrix.org extensively for friends and work, I see invitations to slack, discord and mattermost communities as a strange thing.
Why would someone use a walled-garden instead of a protocol ?
It's a very similar feeling for Bluesky.
> Why would someone use a walled-garden instead of a protocol ?
Because it actually works. I've tried countless of times to use Matrix with different groups of people and every single time there comes a point after a few days where one of the participant can't read messages from another, or can't send messages anymore, etc. And that's was even the case with computer literate people (computer scientists or developers).
So yes, I see your point and in a world where Matrix actually does work and is simple to self-host, your point would be entirely valid. Sadly in real life, setting up a Mattermost instance is easy and it just works, while Matrix, even without the hassle of self-hosting, doesn't.
I was sending a message to my friend on matrix and it didn't work , I tried quite hard.
Ended up going on signal.
>Why would someone use a walled-garden instead of a protocol ?
>It's a very similar feeling for Bluesky.
Is this actual wondering on your part, or are you just rhetorically framing these as questions, as a means to express frustration? I mean, it's extremely easy to come up with an answer: they are much better-known platforms, have much larger user bases, and provide simpler and quicker initial access. That's all there is to it. In the case of Bluesky, though, you have to take into account the political stances surrounding how the platform is viewed as well.
> I mean, it's extremely easy to come up with an answer: they are much better-known platforms, have much larger user bases, and provide simpler and quicker initial access.
Can you share your sources for the "much larger user bases" ? It's hard to get the figures, I just googled them for 5 minutes and got contradictory results. Some pages say 30 million daily active users (DAU) for discord, some say 150. Slack seems to be at 30 million.
For Matrix, the official site says "The open network has grown from 80.3M to 115M addressable users." but there was only "250 DAU" in january for matrix.org, the public instance. The French gov's deployment of Matrix says 0,3 million DAU. https://element.io/case-studies/tchap
According to this page, lots of NATO agencies are already using Element https://element.io/blog/nato-ni2ce-messenger-utilises-the-po.... This other page lists several other deployments https://element.io/blog/element-is-combusting-with-excitemen....
It's hard to get the number of DAU users of a decentralized network, I couldn't get any for Mattermost.
Could you please recommend a guide for how to set up something like a Slack/Discord replacement with Matrix? Do I understand correctly that this will be self-hosted?
I find it very difficult to get good solid information on actually using Matrix in the ways I use Discord.
No, just create a space on the web version of element.io.
Unless your data should be on your server, in this case yes you have to launch your own instance.
Once you're logged in, there is a "+" sign on the left. Create a public or private space and then add channels to it.
I'm with you. but matrix is failing adoption for the same-ish reason as PGP.
You create an account from scratch, means using two (three) centralized services. matrix.org. vertex.org. (and the third is possible your email provider which would be either gmail.com or icloud.com)
Then you get a password, recovery keys, recovery passphrase, session keys. And have to know what to do with them all.
Not sure how it improved on v2, but recently i had friends doing literal PhD on cryptography code having to create a new account because they forgot to save one of those keys when replacing phones.
The reality is that worst case, it should feel like a laptop (username, password (unless using SSO) + recovery key) or a cryptocurrency wallet.
With the v2 crypto, you typically don't have to remember anything - you just scan a QR code to log in.
If you've logged out all of your devices then yes, you need username + password (unless using SSO), and then if you want to recover your encrypted history you need the recovery key.
It's true that the UX historically was awful, but on Element X i believe we've got it right (and Element Web/Desktop will shortly follow).
Self-hosting is possible but optional. You can create rooms/spaces on matrix.org or any other matrix server of your choice. If you want control over your data, you may want to self-host, but if you consider Slack or Discord to be acceptable for your use cases, you can probably use a standard Matrix server without any issues.
You can create a "space" that's pretty close to a Discord server. Spaces include rooms ("channels") or even other spaces. This means you could set up a "Friends of pixelpoet" space with a bunch of channels like on Discord, but also a "pixelpoet Corp" server with in it spaces for "General", "Project Jabberwocky", "HR", and "Janitorial staff", each with their own rooms and ACLs inside of it.
How I would approach your setup: I would create a new space, then create a few rooms in that space (your #general, #games, #offtopic, etc). I'd also maybe add a "video room", which works a bit like Discord's audio/video channels, though not many clients support those yet (I think they're in beta?).
Then, go to the "space home" (as Element calls it), and make sure to check every channel, and set the "mark as recommended" flag, so that people joining the space will be guided to join all of the channels as well. It's possible to join a space but not join all channels, which can be useful for some but is probably pretty awkward for most. People that don't join all channels still can join after the fact, but you probably want everyone in every room by default.
For larger servers, you want need to configure ACLs before letting people in. Do note that unlike on Discord, settings change for a Space do not apply to rooms that are included in it automatically; you may need to manually alter ACLs for every room or find a bot to do it for you. If it's just a space friends or coworkers, you hopefully don't need to bother, though.
Then, to get other people into your "server", invite them to the space, or share a generated link. Just right click the space and pick "invite".
If you like the Discord UX, you might want to try Cinny, a Matrix web client that's pretty much a Discord clone in terms of design. It doesn't support everything Element supports, but it's good enough that I'd be willing to recommend it to others if they're not the ones setting up the server.
For data safety, you can leverage Matrix's encryption feature to end-to-end-encrypt everything even if you're storing your space on another server. This can have some annoying side effects (like people losing access to their old messages when they forget their recovery password, because, well, they're encrypted) and using the feature securely requires a) verifying other people and b) verifying every device you log into with another device or by entering a backup key. This is harder than in other messengers but it's also a more secure design. Could be useful if you don't entirely trust Matrix.org, could also be useful for setting up channels for sharing sensitive documents, but it's probably best for general usability to disable encryption at first. I enable encryption everywhere, but I don't think encryption/decryption is trouble-free enough that I'd be able to convince my friends to fully enable it in chat rooms as well.
I'm not sure I'd call Discord a walled garden. Officially, it is a walled garden, sure, but there's a huge variety of different clients you can use [0]. Not every client supports every feature but Matrix clients are no different in this aspect. The API Discord's official client uses is fairly well-documented, too [1].
[0] https://github.com/Discord-Client-Encyclopedia-Management/Di...
[1] https://docs.discord.sex/
It's a walled garden in the way that matter most, which is that if the things inside the wall get back, you can't take your account/social graph and go outside the garden.
It's generally difficult to make people move away from well-established platforms. Would Matrix be a walled garden if it was the leading communications platform?
Exporting all your account data is very easy with Discord, and you can even export entire servers with bots. Doesn't seem like they make it particularly difficult to move away from their platform.
today I learned about .sex as in .com etc.
What a strange place we live in , who needs .sex ? brothels ?
Porn sites obviously.
How is Bluesky a walled garden?
Haha no, the contrary : Bluesky is not, it's based on a protocol, ATProto, like Element is based on Matrix.
Ahh okay :) sorry for the misunderstanding, haha!
I've had Element X installed for a while -- couldn't use it for a while after EMS shut down their small instances and I started self-hosting, but it works with my self-hosted Synapse now.
The only problem is that it's got too many paper cuts. I can live without Spaces, even though I use them on Desktop. But notification channels are a harder sell, and missing avatars on notifications is just annoying. Neither are exactly core features, but notifications are the most common way I interact with Element on mobile and for me, the improvements (and there are many) aren't worth the downsides.
> But notification channels are a harder sell, and missing avatars on notifications is just annoying.
huh. on Element X iOS, the notif support is genuinely great - you get avatars and groupings and reliable notifs on e2ee msgs. the only thing is missing is quick-reply (which has been blocked behind full multi-process support in matrix-rust-sdk, hopefully coming soon).
I'd assumed that Element X Android would be the same; if not, it's an omission and will get fixed.
> I'd assumed that Element X Android would be the same; if not, it's an omission and will get fixed.
Aren't you Element's CTO? I feel like you shouldn't need to make assumptions into how the app works, you should just know (even if you're not personally daily driving it). If not you, is anyone in charge of ensuring that the project's vision and goals are met?
yup, i'm the CTO, and I don't have notifs enabled on Android and so hadn't checked - I daily-drive iOS. The folks "in charge of ensuring the project's vision and goals are met" are the ones running the Element X team - sorry that I haven't memorised the full feature parity matrix :) Sounds like https://github.com/element-hq/element-x-android/issues/1547 is the bug for you to upvote & subscribe to.
I’m in south east Asia and I have a lot of friends using matrix but the whole is unbearably slow to me. Most of the time it takes more than 10 seconds to sync and messages don’t go through. I’d be happy to look at the infra to see what’s happening though. It’s also what breaks my notifications on iOS.
Are you using matrix.org? Maybe you could try a server closer to you?
Element X has a few notification issues on Android (I use it daily): you don't get quick reply (which can be fixed by adding conversation shortcuts in Android), and you get a notification for every single message. Element X doesn't stack up the notifications, so if someone floods you 20 lines of text in less than 10 seconds, your phone will vibrate 20 times in under 10 seconds. It's quite annoying.
I treat Element X as an alpha client. Half the features I use aren't implemented and I get signed out every few weeks. The parts that do work, work very well, but the parts that don't are
After the last update, I can't seem to log in anymore, which is a first. Fluffychat is my go-to on mobile these days. It supports Material You, which I like, and does things like notification channels well. It still has the occasional bug and I get the feeling it's consuming more power, but it's the best Android client I know of in terms of features versus stability.
From what I've read, most of the Element X work seems to have been put into iOS, because Android has had a few app rewrites over the years already but the iOS version was still based on some very old code base.
Does this change anything for notifications? I've had to pause using Matrix (self-hosted Synapse plus Schidichat for Android after Element had the same issues) to talk to my friends because we routinely get shit like:
- Message is sent to the server but nobody else's phone gets notified about it for minutes / hours
- Message just can't be sent to the server even though the sending phone has Internet and a desktop web client on the same account works great
If the problems were caused by issues in the old Element Android (or Schildichat) app then yes - the Element X rewrite will likely fix it. It supports UnifiedPush, so if you're self-hosting a push gateway it should nicely integrate (as does Schildichat Next).
If the problem was in your push infrastructure, then the new app won't fix anything - however, UnifiedPush should be reliable these days (especially if you host your own instance; some of the shared ones are overloaded and/or deliberately throttle Matrix push). FCM obviously should be reliable too.
I have the opposite problem with Element Desktop. I hear messages coming in on my phone but it takes up to 10 seconds before they appear on the web client. Really annoying.
Off topic but I love the YouTube player interface. Instead of loading it by default (and adding invasive Google tracking to the page), you get the option to opt in. Very nice.
hosting such videos on YouTube alternatives (even federated once) would be even better. I.e Blender has a peertube instance video.blender.org
Not really. this can be avoided entirely by embedding with youtube-nocookie.com instead of this weird dance and youtube.com.
https://support.google.com/youtube/answer/171780?hl=en#zippy...
I tried navigating to youtube-nocookie.com and got an http cert error, so that doesn't seem like an option.
The support page you linked to talks about "Privacy Enhanced Mode". The language there does not sound like it really protects privacy.
> The Privacy Enhanced Mode of the YouTube embedded player prevents the use of views of embedded YouTube content from influencing the viewer’s browsing experience on YouTube.
So they're not promising not to track users. They're saying they won't use their tracking to personalize anything.
I just opened Element X, tried to decline some spammy invite - "sorry, unknown error occured". Tried opening backup section in settings - "sorry, unknown error occured".
I don't think it is ready for prime time.
Had the same experience. The invite came from a server that was possibly down because of spam reports. I guessed the error came from that.
what server is this on? (as these sound like serverside issues). please can you submit debug logs so we can take a look? needless to say, this shouldn't be happening.
I join from the official matrix.org server. It also federates to Gnome server and maybe some others, but they never synced properly so I never used it.
Previously (42 points) https://news.ycombinator.com/item?id=41987113
Yes, I reposted since that didn't seem to catch typical amount of attention.
Congratulations to the Matrix team. I look forward to trying out everything this release offers and seeing how I can implement in the organizations I work with.
Are there any plan for improving the desktop version of Element? E.g. by porting Element X to the desktop. Or should I look for other Matrix clients? I feel the Element team with their limited resources sadly cannot keep Element Desktop in the shape it needs to be to be a great client.
Yup. On macOS you can use the iOS build of EX already today (i daily drive it, and it’s very usable). Meanwhile, I built an unreleased prototype of a possible EX Desktop which uses Tauri + matrix-rust-sdk (codenamed aurora) - weirdly enough it feels almost identical to Element X iOS, which makes sense given all the heavy lifting in EX is matrix-rust-sdk.
Separately to the aurora experiment, the Element Web/Desktop codebase itself is starting to move to a MVVM model to support swapping out the underlying SDK (e.g. for a WASMified matrix-rust-sdk) and avoid an Element X Mobile style rewrite. That said, making matrix-rust-sdk work on WASM is not trivial (especially if you want to avoid maintaining two different FFI layers for wasm-bindgen and uniffi).
Another track is that matrix-js-sdk is also sprouting Simplified Sliding Sync support - I even demoed it in the Matrix 2.0 talk: https://youtu.be/ZiRYdqkzjDU?t=617. And it already has Next Gen Auth and Element Call support. So there's also a chance that "Element X Web/Desktop" just ends up being an evolution of the current codebase - I guess this is the default path right now.
Finally, there are other clients built on matrix-rust-sdk - e.g. GNOME Fractal is shaping up to be an excellent fully native GTK4 Rust desktop client, and given it shares the same engine as Element X, is suspiciously similar in terms of capabilities and perf (although I can't remember if they've enabled sliding sync yet). https://gitlab.gnome.org/World/fractal
Any plans for a mac catalyst version of element x?
I recall Rust was a blocker for that a few years back, but after I fixed Rust’s mac catalyst support to enable fat builds of matrix rust sdk for it, it turned out there was another blocking library.
the UIKit app has weird scaling and doesn’t have the nice macOS translucent sidebar/toolbar etc
So I did a catalyst build of EX a while back (which is where https://github.com/rust-lang/rust/issues/106021 came from) - but rather anticlimactically the end result looked almost identical to the normal iOS app when running under macOS; I don't remember the sidebar/toolbar looking particularly better, and that was my main reason for doing the build in the first place (to get a flexibly resizable left toolbar). The main advantage seemed to be that it would run on Intel.
If things have improved I'd love to know, and then perhaps we'll have another shot at it. Are there any good comparison screenshots of the two approaches (with a toy app, i guess) anywhere?
I think the benefit is more that you get access to AppKit APIs. This lets you integrate with the OS the way users expect.
For example wrt scaling, Apple’s Mac Catalyst guide says:
> When you first create your Mac app using Mac Catalyst, Xcode defaults to the “Scale Interface to Match iPad” setting, or iPad idiom. With this setting, the system ensures that your Mac app appears consistent with the macOS display environment without requiring significant changes to the app’s layout. However, text and graphics may appear slightly less detailed because iPadOS views and text scale down to 77% in macOS when you use the iPad idiom. For example, the system scales text that uses the iPadOS baseline font size of 17pt down to 13pt in macOS.
So you gotta change that setting, and then use whatever SwiftUI components (or straight up AppKit APIs) allow for that native look :)
I agree that an amazing Desktop client would be great, and that most likely there's a need to prioritize where efforts go at the moment.
For now, maybe check out Ferdium. AFAICT, it's just a wrapper app for web clients, but even this might solve some shortcomings of the official desktop app (e.g., cleaner usage of multiple profiles).
Eventually attentions will turn to Element Web/Desktop.
For now the magic is happening in the background, SDKs etc.
Browser version works well?
No idea, I do not use it. I generally do not like using browser versions of e.g. IM clients.
I wrote an easy to follow guide for hosting matrix a while back: https://hcrypt.net/synapse.html
Is Synapse still the only Matrix server implementation that is not in beta? The matrix.org site seems to suggest as much, but I don't know how up to date that is.
yes, unfortunately. Dendrite almost got out of beta, but (very frustratingly) we didn’t have the $ to keep developing Synapse and Dendrite fulltime - so we consolidated on Synapse, given it was already mature and deployed everywhere, and are focused on rewriting the hot paths of Synapse in rust and generally improving Synapse’s perf and scalability rather than maintaining both go and python servers.
Meanwhile Dendrite is getting maintained best effort by the former team as time allows.
Finally, the other main area of server dev right now is Conduit (conduit.rs) - a pure rust impl targeting small selfhosted servers. Conduit itself has slowed down recently but there are two very active forks: Conduwuit and Grapevine. All three are beta however.
It's unfortunate that dendrite is on life support. I've been using it for a long time to contact family in countries with high censorship.
I want to migrate to conduit or a fork of it but can't find any docs on how to do that. Would rather not spin up a server from scratch as breaking existing accounts would mean a complete loss of contact with some people that would need assistance to even sign up.
Of course, I'm not switching just for the sake of it. I've had a ton of bugs with dendrite suddenly taking up gigabytes of memory when federating (turned the feature off) and somewhat random crashes
yup. it's gutting that nobody has put $ behind the bar to support it. the entirety of Reddit chat is/was built on Dendrite, but they (and many others) chose not to put money behind it, unfortunately.
Does Matrix still sync all metadata with all connected federated instances?
Its room based. Each room is synced between all servers used by participating members. But if you have a room with only people from 1 server, that metadata stays on that server.
Is it possible to configure this so that the metadata remains on the server by restricting access to only those users who are not members of any other servers?
While creating a room, you can choose to "Block anyone not part of your server from ever joining this room".
This does not mean that people on many other servers or rooms are not allowed though, which I presume is what the metadata sync is about.
You can disallow users from joining based on their homeserver or only allow local (on your homeserver) users, so the answer is yes.
It's not about being a member of a room on another server, but the homeserver of the account itself, of all the members of the room, must be local to that same server as the one that created the room in the first place.
I don't think there's a setting for "only allow people from X server", but you can make the room private and only invite people from that particular server.
> Could it be the glorious return of P2P Matrix (if it was funded)?
I forgot how it works right now, but I certainly would hope so in case of private messages (incl. P2P encrypted audio and video calls).
P2P Matrix is a dialect of Matrix where the server runs inside the client itself - see arewep2pyet.com for details. In other words, there are no servers (other than optional store-and-forward relays). It's insanely cool - you can see a demo at https://www.youtube.com/watch?v=eUPJ9zFV5IE&t=2192s. It's also unfunded and on hiatus until someone provides some $ so we can work on it again.
Right now, normal Matrix is a client-server model: you can't send messages from a client without it talking to a server (and then to another server, and then to another client). MatrixRTC VoIP and Video calls in Matrix 2.0 also go via server (for now), in order to support multiple participants and firewall traversal.
Obviously, both messages and calls are end-to-end-encrypted (other than in public chatrooms), which makes it less important that they go via a server today.
I'm sure there is p2p funding available on the sidelines. Give us an actual opportunity to privately sponsor it.
I am sure you have heard the dismay of people who would like to sponsor Firefox but only really have the option to finance the Mozilla Foundation, who put the money elsewhere? Some similar feelings here.
Unlike the Mozilla Foundation, if someone came to Element (or the Matrix Foundation) with a large bag of $ and asked for it to specifically fund P2P, then a conversation could definitely be had.
That is not enough, it is not certain, and it makes people more hesitant to spend money. I agree with another comment that mentions BTC and XMR, but it must go directly to P2P, or alternatively, people should have the option to choose specifically how their money is used.
The main issue here is uncertainty. If I contribute funds, what guarantee do I have that the money will actually go toward supporting Element P2P? This uncertainty is a major barrier for many.
Just put up Bitcoin and Monero addresses already? You/we can't possibly expect to rely on traditional centralized funding to chip in for for decentralizing the control and power over communication...? We want to fund this.
Worth trying something akin to a kickstarter?
Why wouldn't you use Jami instead of Matrix if you are interested in a p2p solution?
Thank you for your answer.
> It's also unfunded and on hiatus until someone provides some $ so we can work on it again
What are the available ways for someone to provide funding?
https://matrix.org/membership/ is how best to support - or buy stuff from organisations who support the Foundation. P2P Matrix requires a 3-4 person team to progress constructively (rather than limping along on a shoestring), which means $$$K/y over and above the current funding targets: https://matrix.org/blog/2024/01/2024-roadmap-and-fundraiser/
I guess the question was how to fund progress on P2P specifically. Everything you listed most likely will not go anywhere near P2P. If it were so, it would be be unfunded in the first place.
What a stupid statement! They certainly have money and decided to not invest into P2P. And now they make it seem like the reason that it is unfunded is because of outside factors. Whoever wrote this should be fired...
Related: Matrix 2.0: The Future of Matrix --> https://news.ycombinator.com/item?id=37599510
Is it possible with Matrix to run your own server but let Matrix.org handle authentication? I always thought for many that's probably best of both worlds.
What benefits does this have? You'll still have to have a server running and you lose control of your account, if I'm understanding what you mean (letting matrix.org handle accounts).
User friction. My problem is this: I'm in a bunch of Discord Server/Guilds but watching Discord Inc., it's clear that they are ZIRP powered and it might come crashing down in massive fireball. However, if users have 5 separate logins, they are not going to convert over.
I realize the implications of "What happens if you get Matrix.org account banned?" but that's next week problem.
It’s federated anyway, similar to email. One account can take you anywhere, so if you make your own "guild" the users could just directly participate from matrix.org (or any other home(server))
I'm a big fan of Matrix, but I'm embarrassed to recommend it to my friends until Element X supports audio calls... It's been months since the leading-edge release, and I don't know what to think: there's Element Call, however it's neither supported by Element X nor real alternative to legacy peer-to-peer audio calls.
Element X doesn't even support Threads or Spaces still, the two things that are absolutely required to organize discussions.
Element X natively integrates Element Call for voip/video calls - this is one of the core things of this week's release. If you hit the video call button, it'll start off with video muted, and it should behave like a voice call (although there are a few bugs in the integration still, hence it being marked beta - especially on iOS, where CallKit + WebRTC stopped working in iOS 18. We're trying to work with Apple on it.)
Unfortunately, that is not the case yet on Element X android (0.7.2 from google playstore). Microphone starts off as muted which is an inconvenience.
Don't know about Element X, but Element supports voice calls very well.
It does but it's also a battery drain on Android :-( Element X works much better.
What do you mean by audio calls? I haven't used Element X yet, but judging from the store screenshots you can turn off the camera in video calls.
I don't want to turn off the camera in the video calls; I wish to have normal audio-only calls like in any other app like Whatsapp where there's a "Phone" button that starts a call.
>Native Matrix Encrypted Multiparty VoIP/Video (aka MatrixRTC, MSC4143)
Excellent. This is basically my only use for Matrix because encrypted video chats, 1-to-1, and now many-to-many (YES!) are the only thing Matrix does better than IRC. I started using Matrix video chat to talk to family during the early pandemic and sort of got used to it.
I've been on-and-off hosting for a while and I avoided synapse because it seemed to rely on a lot of different services and python packaging is hell. Seems like dendrite is dying (which I did not know until now), conduit and siblings are very much beta and not close to being stable.
If I read this correctly there is just one server worth actually using (synapse) and two client libraries (matrix-rust-sdk and matrix-js-sdk, both maintained by the same org/people).
At the same time most of the bridges to other protocols (which was one huge selling point of matrix) are either broken, outdated, alpha (and by that I mean really, really alpha) or beta (usually in a stagnant state or alpha-ish).
One of the goals (perhaps the primary?) of matrix was to build a protocol that is supported by multiple servers, clients and bridges but that does not seem to have been realized.
I just listened to the keynote on matrix 2.0 and...
I used to be a huge proponent of matrix, but I really feel like the potential has not been lived up to.
There are loads of SDKs which work well - as well as matrix-rust-sdk and matrix-js-sdk there's also excellent fully-featured indie libraries for Dart, Kotlin, C++, Go, Python (and many other others which don't have full parity).
You're right that Dendrite is currently stalled, but it's not a reflection on the protocol, but just the reality that writing and maintaining two servers simultaneously is expensive. Meanwhile most of the good stuff in Dendrite has already made it back into Synapse. Bridge development has also stalled for the same reason (exacerbated with hostility from those being bridged) - but then 3rd party bridges like heisenbridge are doing fine.
On the other hand, conduit/conduwuit/grapevine look to be bubbling away at an impressive rate (entirely independently of Element), even if they're currently beta.
So, I don't think the potential has been lost - instead, the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent rather than being spread too thin, which is a major improvement over the past, imo. Meanwhile the broader community is busy hacking away too.
> Meanwhile most of the good stuff in Dendrite has already made it back into Synapse
But that still means there is only one actual trusted server implementation, right? I thought the point of dendrite was to be able to prove that MSCs were implementable independently before they became part of the spec. It seems like the actual spec is just whatever MSC synapse has implemented.
> Bridge development has also stalled for the same reason (exacerbated with hostility from those being bridged)
Some open protocols like XMPP (which would seem like a natural fit) do not have stable bridges. Other open protocols like email are quite limited in that they require you to act as a full service provider (actual email server instead of a bridge between an email account and matrix). Others like SMS have no stable implementation. Those are just the ones that cannot be hostile to bridging. Many of the bridges to proprietary services listed on the site have not had any activity for 2+ years (which in itself is not bad but if they interface with a moving target or changing protocol it probably is).
Is the "One chat protocol to bridge them all" goal abandoned?
> the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent
I'd love to see that. I'd especially love to see it stabilize and simplify enough that we have a multitude of servers, clients and bridges that are stable and useful. I'm just not seeing it right now.
Thank you for taking the time to reply
> But that still means there is only one actual trusted server implementation, right?
Nope? Dendrite works. It's just stuck in beta for now due to lack of manpower.
> I thought the point of dendrite was to be able to prove that MSCs were implementable independently before they became part of the spec. It seems like the actual spec is just whatever MSC synapse has implemented.
The spec is not "whatever MSC synapse has implemented". The spec is... the spec, and the compliance test suites (sytest, complement) which go with it. Currently we require one implementation of MSCs to prove their validity before landing in the spec - and that could be in synapse, dendrite, conduit or wherever.
Just because the core team only has $ to actively progress a single server implementation right now doesn't devalue the spec at all. If anything it makes 3rd party implementations like the Conduits even more important, in terms of showing that the spec isn't coupled to the Synapse implementation.
> Is the "One chat protocol to bridge them all" goal abandoned?
Right now the goal is "have a decentralised open chat protocol whose apps can outperform mainstream centralised products". Bridging is secondary (for now, although Beeper is obviously focused on it).
> > the core team has ended up focusing our energy on a smaller set of projects while making sure we get a small set of things really excellent
> I'd love to see that. I'd especially love to see it stabilize and simplify enough that we have a multitude of servers, clients and bridges that are stable and useful.
The two are mutually exclusive. We can't simultaneously focus on getting a small number of implementations excellent... while also working on a multitude of implementations. Instead, we can make sure that the implementations that the core team works on at Element are great, solve problems, simplify things and unlock everyone else to be able to build better ones too - which is precisely what we're doing.
Their main, and default client, still doesn't support multiple accounts. It's been years
They are very much aware of that missing feature, but there are currently other things that have higher priority.
I never assumed they weren't. We disagree about how high a priority it should be.
Workaround for now: just install multiple client apps. Annoying of course, but it'll let you get work done... plus, fluffycats !
I’m maintaining a Matrix TUI and I haven’t updated it in forever because I keep saying I’m going to wait for the next stable Rust SDK… but I just keep waiting. Anyone know if that is planned, because without a stable release, packaging is a bit of a pain.
hm - i think it's just because they've been frantically building and haven't time to release. looks like 0.7.1 was the most recent release in Jan; will give them a prod. sorry.
Ah yes, that makes sense. Thanks!
I'm concerned about the performance for small hosts, which I tried and gave up.
it seems both Dendrite (go) and Conduit (rust) are STILL not in a state for prime time.
how are you measuring perf? sync should be instant with sliding sync no matter how small the server is. are you talking about time to join big rooms? or resources used for participating in big rooms?
Previously, it seemed the sliding sync required a Postgres-backed Synapse installation. Does the Matrix 2.0 version of Synapse provide a seamless upgrade path for those using the default Sqlite installation?
Yes. the sliding sync proxy shim is gone; Synapse now uses its native database for sliding sync, same as the old sync API - so it works with both postgres & sqlite.
By the way, Sqlite should only to be used when testing, not when actually deploying a system that interacts with other systems. https://element-hq.github.io/synapse/latest/setup/installati... says as much.
I've been looking forward for almost a decade now for Matrix (and the client ecosystem) to mature enough that it isn't so hard to get people less tech-savvy to give it a honest spin.
Here's hoping this is a milestone as good as it sounds. I'm particularly curious about the improvements in encrypted conferences, which is... A pretty darn hard to do. Even more so with Matrix's "constrains".
> Next Generation Auth (aka Native OIDC, MSC3861)
Huge for me. I run my own IdP, mailserver and it’s one less self hosted service that I need to manage credentials for
oidc was already possible before and was very easy to setup. this change seems to be more about the internals of matrix auth.
Previously discussed here: https://news.ycombinator.com/item?id=41987113
Glad it‘s getting more attention now. It’s quite a step towards Matrix experiences being just as good as traditional proprietary ones (though hopefully by far not the last one).
What's the upgrade process and the state of implementations for self-hosted services? The current service is beyond terrible, big hopes for Matrix 2.0.
A little too late for my team, we switched two weeks ago from Element to Zulip and the difference in communication is night and day. Features such as mentions, notifications and threads (topics in Zulip) are vastly more stable and consistent.
Does synapse support this at the moment? I can't quite tell from the writing here if/how you can run things that support this - my guess was no because it mentions improvements to the js SDK are required and there's no warning on the synapse repo. Or is that just that these features are opt-in?
Synapse now has native support for sliding sync (the new "instant sync" Matrix 2.0 API, implemented in Element X and other rust-sdk clients like iamb - Element Web has it in labs).
The other bits of Matrix 2.0 require new moving parts: matrix-authentication-service to support next-gen auth (although this will eventually get optionally embedded inside Synapse), and livekit for VoIP. Finally, invisible crypto is purely spec & client-side improvements.
As per https://news.ycombinator.com/item?id=42034324 i'm currently frantically writing a compose.yml to show how they plug together, while kicking myself for not having arranged one sooner...
That's fantastic thanks - the sliding sync part addresses an issue a client I've got would be facing at some point. I'll have to check out the details of that.
Is it already possible to join rooms without revealing your global address like in XMPP?
that's pseudo IDs; MSC4014 (https://github.com/matrix-org/matrix-spec-proposals/blob/keg...).
it got implemented in Dendrite, but hasn't made it into Synapse (or the spec) yet.
Updated to the new version of Synapse to try Element X, but went back to the regular app due to the lack of features, particularly the image resolution prompt when sending media.
That's ended up becoming a global setting, which merged a few days ago (https://github.com/element-hq/element-x-ios/pull/3467) so hasn't been released yet. We're catching up on features as rapidly as possible - meanwhile i'm surprised that the advantages of the new app donn't completely blow away the old one.
Does it have serverless P2P like Jami yet? If not, it seems like it's not ready yet.
Without true P2P every individual user still has single points of failure.
It's less disruptive if one server bans you, since people have been known to be banned for absolutely nothing, so there's some value, but not enough that I'd actively pursue switching, unlike with Jami and similar, unless I planned on doing things that make bans more likely.
They're making really good progress though in general!
Have the new security and encryption features received review?
they haven’t had formal independent review yet, but we will get them audited. there are relatively few changes in practice though other than fixing bugs, removing confusing UX and adding the beginnings of TOFU. Off the top of my head it’s only TOFU which would need new review.
i hope after the transition is done, there will be a focus on multiplatform e2e search, attachment tab improvements (it's fine for < 10 attachments in a chat, but not a 1000), optimized notification system so friends stop bug me with it, and of course custom emojis
Does it help with laggy Element?
Yes, it will help with some of those issues.
Honestly laggines of Element on Android forced me to use Signal more frequently.
Still no concepts about P2P file transfers. Disappointing. The RFCs exist and just need to be discussed. People to implement that stuff are there and ready to go.
Disappointed this ain't about linear algebra
> now focusing on making Matrix fast, usable and mainstream-ready with Matrix 2.0
Feels like all of those things should have been the focus of 1.0, no?
nah, 1.0 was getting it out of beta and making it work at all. 2.0 has been all about making it work fast and mainstream-ready. https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast