I realize the implications of "What happens if you get Matrix.org account banned?" but that's next week problem.
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).
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.
> 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?
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.
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.
1. https://github.com/spantaleev/matrix-docker-ansible-deploy
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).
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 feel overwhelmed at the number of options there are in this ansible thing. Now I definitely don't want to try it either way.
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
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.
Disclaimer: I'm Aine of etke.cc
- 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 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.
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.
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.
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.
https://support.google.com/youtube/answer/171780?hl=en#zippy...
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.
Feels like all of those things should have been the focus of 1.0, no?
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...
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.
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.
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?
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.
For now the magic is happening in the background, SDKs etc.
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
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
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?
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 :)
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).
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.
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
Huge for me. I run my own IdP, mailserver and it’s one less self hosted service that I need to manage credentials for
it got implemented in Dendrite, but hasn't made it into Synapse (or the spec) yet.
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".
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!
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.
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.
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
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.
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).
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.
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.
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).
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.
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.
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.
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 )
I don't think it is ready for prime time.
Why would someone use a walled-garden instead of a protocol ?
It's a very similar feeling for Bluesky.
I find it very difficult to get good solid information on actually using Matrix in the ways I use Discord.
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.
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.
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).
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.
>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.
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.
[0] https://github.com/Discord-Client-Encyclopedia-Management/Di...
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.
What a strange place we live in , who needs .sex ? brothels ?
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.
Ended up going on signal.
it seems both Dendrite (go) and Conduit (rust) are STILL not in a state for prime time.