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.
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
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?
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.
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.
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.
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 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.
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.
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.
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.
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...
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 :)
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).
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?
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.
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'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.
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
If there was a way to deploy there and make a snapshot of it that could be cloned to my own server, change DNS settings (to point the domain to my own server and re-grab the ssl certs) and be good to go.. I'd jump on that.
especially with the addons setups offered, that could be nice.
I love the idea, but I have tried this three times and failed each time.
Sure I was learning docker and ansible at the time, and I did get a little bit of 'tech suggestions' from those in the know.. (enable less things to start)
It seemed to install a lot of things and get close.. it could be because I was trying debian 10 when it was made for debian 9 or whatnot..
I just need to mention that as much as it may be an all easy solution for some, it does not always work and turned out to be a big time waster for me three times (although I'll chalk up learning some docker and ansible as not being time spent that I consider wasted) - it did delay me getting a matrix / element setup running.
I think nginx is doing some things different in latest debian as well that effed up some of the tutorials and chat support.
but it's been some months, maybe it works fine now on latest debian without issues, but my experience has shown it to be very finicky.
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.
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.
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.
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.
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.
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.
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.
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.
I had that problem a couple versions ago.. turns out one table in the postgres DB, I think 'devices..' something got be like 50 GB and I could never get it widdled down even with manual vacuums and such,
I think the newer version of matrix handles cleaning that table better, but I'd need to login a check, it's been a while.
Given that the DB gets so big I had to bit the bullet and move from spinning HDs to SSDs on my latest install. Make a big difference at the beginning of course, the DB had not ballooned yet.
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.
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.
175 comments
[ 3.2 ms ] story [ 230 ms ] threadI 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).
https://mitogen.networkgenomics.com/ansible_detailed.html
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
nginx or caddy or something?
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
especially with the addons setups offered, that could be nice.
Sure I was learning docker and ansible at the time, and I did get a little bit of 'tech suggestions' from those in the know.. (enable less things to start)
It seemed to install a lot of things and get close.. it could be because I was trying debian 10 when it was made for debian 9 or whatnot..
I just need to mention that as much as it may be an all easy solution for some, it does not always work and turned out to be a big time waster for me three times (although I'll chalk up learning some docker and ansible as not being time spent that I consider wasted) - it did delay me getting a matrix / element setup running.
I think nginx is doing some things different in latest debian as well that effed up some of the tutorials and chat support.
but it's been some months, maybe it works fine now on latest debian without issues, but my experience has shown it to be very finicky.
- 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...
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.
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?
Obviously, needless dicklike comments can only help the project and its users.
I think the newer version of matrix handles cleaning that table better, but I'd need to login a check, it's been a while.
Given that the DB gets so big I had to bit the bullet and move from spinning HDs to SSDs on my latest install. Make a big difference at the beginning of course, the DB had not ballooned yet.
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