Cool! I’ve recently consolidated all of my Google Chat and WhatsApp friends onto Matrix (via Element) because it’s E2EE. Gchat isn’t and I assume that Meta has a backdoor into WhatsApp conversations. So, those platforms can’t be trusted. Signal doesn’t have a web interface, so that’s a no-go for me. lol Telegram.
Matrix has been great for me and I recommend that everyone else use it!
You're absolutely right. End-to-end encryption protects message content, but WhatsApp still collects metadata, which is incredibly valuable.
Even though they can't read your messages, they know who you talk to, how often, when, and for how long. They also track your device info, IP address (which can reveal your location), network details, and app usage patterns.
And this data isn’t just sitting there—Meta uses it. For example, if you chat with a business on WhatsApp, you might start seeing ads for that business on Instagram or Facebook. They don’t need to read your messages when they can infer so much just from how you use the app.
Disclaimer: Comment translated from Spanish and corrected by Chat GPT.
Self-hosted Matrix with all the bridges is awesome and brings back that Pidgin/Adium life of one chat app for all of my friends. Too bad Apple has an uncanny ability to avoid consequences with iMessage.
It's wonderful that it seems work well for you but my experience in bridging group chats with XMPP or IRC was terrible. Lost messages, bridge crashes, puppet accounts getting randomly broken/duplicated with discarded messages.
From the bridges I've run, only the Telegram bridge is somewhat stable for me but it also has it's warts.
Might be different if you run a strictly personal server for 1:1 conversations but I'd say from an ux perspective the bridges idea largely failed IMHO.
I don't think it's the fault of element/matrix it's a difficult problem and I guess with limited resources they made a lot of progress and made things possible that weren't before but it's not plug and play, at least it wasn't for me.
In general I've found it's also difficult to communicate in group chats if there are two worlds with a slightly different view (missing reactions, some elements of the messenger are not supported like captions, polls and so on...)
Signal doesn't have a web interface, but being able to use a desktop app is OK for me.
The big downside for me is not being able to use it on two devices. All the other services, privacy concerns or not can now do this. It's one reason why I stopped donating to / advocating for signal.
You mean you access all these on Matrix/Element via the bridge? Or you actually mean you convinced all of them to ditch their chat apps and migrate to Matrix, or at least install Element as well in addition to the other ones? It’s a feat if it’s the latter without or without ditching. Is this a very privacy conscious demographic?
Element is the company formed by the team who created Matrix to work on Matrix, almost all of whom are still there; there is no falling out :)
The Matrix Foundation is the non-profit set up by the Matrix team in 2018 to keep Matrix itself independent of Element and other Matrix vendors - to act as a steward of the protocol and a standards body. Originally Element donated almost all of its code on Matrix to the Foundation (e.g. Synapse, the original Matrix server) as permissive Apache-licensed FOSS, assuming that if Matrix was successful, folks would want to fund it.
In practice, by 2023, Matrix was very successful... but it transpired that the vast majority of folks commercially building on the Foundation's Apache licensed code failed to route any funding back to the Foundation (as the hosting body) or to Element (as the primary code contributor), despite many polite requests. As a result, there wasn't enough $ to pay folks at Element to keep working on the core Matrix projects as their day job. So, to keep the lights on, Element stopped donating their work to the Foundation, and changed license to non-permissive AGPLv3 in order to sell AGPL-exceptions to the folks commercialising it. This has helped the situation somewhat (although Element isn't at breakeven yet). Meanwhile, it's left the Foundation focused on governance, the Matrix standards process, trust & safety and hosting core libraries like E2EE and matrix-rust-sdk.
There's no beef between the Foundation and Element over this. In a utopia the projects would certainly have stayed as Apache licensed code in the Foundation - but then again, other standards bodies like W3C or XSF don't publish code these days: it's a phase that a given protocol grows out of once third party organisations get busy building implementations.
Disclaimer: i'm conflicted on this, being project lead/co-founder for Matrix, and then CEO/CTO at Element.
But I think the bigger issue is that any platform that controls the javascript sent to you from a web page, can also backdoor/MITM/inject malicious code at any time without you knowing.
I'll tell you what's right about Telegram: I don't know how they're the only independent app that seems to be able to produce such a well built UI/UX for a chat application in 2025.
I maintain that someone should fork their codebase and bolt on a different backend (Signal, Matrix, whatever). It's right there and it's very, very good.
(Yes, I know it's not as simple as "bolt on a different backend". You know what I mean.)
2. No group chat, even a small one between close friends is end-to-end encrypted.
3. Almost all desktop clients support no end-to-end encryption for 1:1 chats, meaning if you use the desktop client as part of your workflow, you're forced to drop using the end-to-end encrypted secret chats.
4. No cryptographers have ever worked in the company.
5. Horrible teething issues for the protocol:
Telegram hosted a cracking contest back in 2013. Everyone in the industry know they are bullshit, and this was discussed back in 2013 The Fallacy of Cracking Contests (1998) | Hacker News The tldr is, Moxie issued a counter challenge to Telegram where he presented the same goals with already broken primitives like MD5, to break the encryption. Telegram never proved the challenge could be won even under those conditions. (Also again, given that Telegram’s built in backdoor of “people are lazy” exists, the cracking contest was pointless. It doesn’t matter how good the encryption is if the adversary wears you down to hand over the keys).
I set firefox to clear cookies, also using cookies to "strict"
This somehow causes a huge pain to connect to mozilla's matrix instance, and I never understood why. This is a bit ironic since firefox has that feature to clear cookies.
I had to reset password, and do other weird things, I can't remember what exactly.
Putting tracking protection to strict essentially makes Firefox violate certain web standards. Developers aren't going to test against that, and if they are they're probably not going to be able to do much about the problems strict tracking protection causes.
If MAS fixes this, it'll be by accident and it'll probably break in the future. Firefox warns against this kind of breakage if you enable strict tracking protection in the settings. You can't have strict tracking protection + websites doing cross-domain authentication working.
I mean, yeah, tracking prevention features basically completely break cross-domain authentication. There are a surprising number of valid use cases that need cross-domain auth (or make the user experience a lot easier). While there are workarounds these days, sometimes it does require deep changes in how auth works
> There are a surprising number of valid use cases that need cross-domain auth
I am not a web developer, but I would disagree with that.
Either web standards respect privacy or they don't, but I would not sacrifice privacy for anything.
Firefox was right to prevent tracking, it highlights how webstandards are just not good. I something doesn't work properly in a firefox private window, to me it should not exist.
I vaguely remember an old MSC or TWIM or something that described (the possibility of) a new authentication mechanism whereby I could set up either a dummy homeserver or something in .well_known that would allow me to use my own domain but without needing to use my own homeserver for the actual traffic. Sort of like an auth-only homeserver, if you will.
Is that part of MAS? Was that initiative ever fully-baked? Or am I just misremembering?
MAS provides backwards compatibility for the old Matrix auth APIs for existing Matrix clients, so they do not need to be modified to keep working. However, to get the most out of all the new auth features (2FA, MFA, QR login etc. etc.) then clients will need to be upgraded to speak OIDC natively. Element X for instance is already OIDC-native.
If you use e.g., "Sign in with Google" today, you get redirected to your web browser, log in, and get redirected back to the client. This means you can use the saved passwords of your browser, and if already logged in there, you just have to click "continue" instead of logging in again.
With MAS, every login works like that. If you click "sign in", instead of getting redirected to Google, you get redirected to the website of your homeserver, where you can login and authenticate before being redirected back to the client.
The primary benefit of using a standard OIDC flow is that your authentication server can easily add support for passkeys, webauthn, TOTP or captchas, without having to wait for every single client to support these features.
While matrix.org uses MAS for this, providing the same login features as it used to, your organization might want to use Keycloak to connect their homeserver directly to LDAP.
I think you will log into your server, and then the server will offer you to give access to the client. The screenshot right below the line you quote seems to show exactly that.
I guess I can believe that, but it's unclear because there's nothing to tell me what that's a screenshot of. The icon in the screenshot is the Element icon, which is a client, so at first glance I figure it's a screenshot of Element. After reading your comment I can infer that it's actually something else (a website?) showing me the icon of the client that wants access. That makes sense, but it's not obvious just from the screenshot.
One reason I ask about this is I always wonder how it will work for someone writing their own client, perhaps a very basic client (or a bot). Any answer that involves "you will click on X" doesn't apply there. As long as there's a straightforward API based way, that's cool. And I assume there is one here. But my experience has been that such changes aimed at "greater security" often make things more cumbersome for small-time developers.
But we'll see. Certainly a smoother login (and logout!) experience for Matrix would be welcome so hopefully this will be a plus overall.
Read the whole blog, and it directs you further for more details. But this blog does tell you they're moving to oidc. That means you will get all the non password flows oidc supports.
This is a reading comprehension problem more than a blog writing problem
This sounds great for large and corporate servers, but a pain for small self-hosted ones. More configuration and external dependencies. Plus additional confusion for non-techy users on those smaller servers.
I don't think this will be required for other servers any time soon, if ever. Clients are going to have to support logging in the oldschool way indefinitely, especially since most Matrix servers are basically unmaintained.
Discord's ongoing enshittification may create a market opportunity for alternatives in the near future. I'd like to think that Matrix could be a beneficiary of that, but the common-case UX needs to be polished damn well when the time comes if they want to capitalize.
MAS and Next Gen Auth open up the way to things like QR-login (complete with syncing all E2EE state and verification!) which should help enormously with common-case UX.
Eh... Discord's enshittified client is still a hundred times more usable than Element — for all its faults, at least Discord is able to deliver and display messages reliably ("unable to decrypt message", anyone?). And for the more technologically oriented, client mods do a lot to improve the Discord UX.
Element X is supposed to improve things, but it's stuck on Android and iOS for the foreseeable future.
I quickly looked at the MSCs and seems “MAS” and associated MSCs enable OIDC/OAUTH authentication flows (basically integration with your favorite identity provider such as Google or Apple).
I was hoping for matrix homeserver to act as an identity provider as well to give us an alternative to big tech for “identity”.
I suppose I could just setup Ory or other open source IdP, but would have been nice to have an all in one package.
MAS can be used as an OIDC IdP, and in future MAS will be embeddable in Synapse so you can use your homeserver as an IdP in the way you want, all in one package.
That said, MAS is deliberately not a very featureful IdP - it's focused on being the glue between Matrix and OIDC. If you want a more sophisticated IdP then you'll still want to run a dedicated one.
Cool! I’ve recently consolidated all of my Google Chat and WhatsApp friends onto Matrix (via Element) because it’s E2EE. Gchat isn’t and I assume that Meta has a backdoor into WhatsApp conversations. So, those platforms can’t be trusted. Signal doesn’t have a web interface, so that’s a no-go for me. lol Telegram.
Matrix has been great for me and I recommend that everyone else use it!
> I assume that Meta has a backdoor into WhatsApp conversations
They don't need a back door when they control the front door: the app. End-to-end encryption doesn't protect the endpoints.
(In other words, your concern is warranted.)
You're absolutely right. End-to-end encryption protects message content, but WhatsApp still collects metadata, which is incredibly valuable.
Even though they can't read your messages, they know who you talk to, how often, when, and for how long. They also track your device info, IP address (which can reveal your location), network details, and app usage patterns.
And this data isn’t just sitting there—Meta uses it. For example, if you chat with a business on WhatsApp, you might start seeing ads for that business on Instagram or Facebook. They don’t need to read your messages when they can infer so much just from how you use the app.
Disclaimer: Comment translated from Spanish and corrected by Chat GPT.
3 replies →
And the default/largest homeserver, matrix.org, uses cloudflare, so all your data belongs to them as well.
2 replies →
Self-hosted Matrix with all the bridges is awesome and brings back that Pidgin/Adium life of one chat app for all of my friends. Too bad Apple has an uncanny ability to avoid consequences with iMessage.
It's wonderful that it seems work well for you but my experience in bridging group chats with XMPP or IRC was terrible. Lost messages, bridge crashes, puppet accounts getting randomly broken/duplicated with discarded messages.
From the bridges I've run, only the Telegram bridge is somewhat stable for me but it also has it's warts.
Might be different if you run a strictly personal server for 1:1 conversations but I'd say from an ux perspective the bridges idea largely failed IMHO.
I don't think it's the fault of element/matrix it's a difficult problem and I guess with limited resources they made a lot of progress and made things possible that weren't before but it's not plug and play, at least it wasn't for me.
In general I've found it's also difficult to communicate in group chats if there are two worlds with a slightly different view (missing reactions, some elements of the messenger are not supported like captions, polls and so on...)
2 replies →
You should not use it ! Xmpp is the answer with its few issues and matrix requires hell of system resources as well.
Signal doesn't have a web interface, but being able to use a desktop app is OK for me.
The big downside for me is not being able to use it on two devices. All the other services, privacy concerns or not can now do this. It's one reason why I stopped donating to / advocating for signal.
Settings -> linked devices?
https://support.signal.org/hc/en-us/articles/360007320551-Li...
3 replies →
You mean you access all these on Matrix/Element via the bridge? Or you actually mean you convinced all of them to ditch their chat apps and migrate to Matrix, or at least install Element as well in addition to the other ones? It’s a feat if it’s the latter without or without ditching. Is this a very privacy conscious demographic?
For me the issue was contact names tbh. Is that solved? It used to be that the contact name was set by the contact and not by me/my address book.
Wasn't there a big falling out between the Matrix team and Element or am I misremembering what happened?
Element is the company formed by the team who created Matrix to work on Matrix, almost all of whom are still there; there is no falling out :)
The Matrix Foundation is the non-profit set up by the Matrix team in 2018 to keep Matrix itself independent of Element and other Matrix vendors - to act as a steward of the protocol and a standards body. Originally Element donated almost all of its code on Matrix to the Foundation (e.g. Synapse, the original Matrix server) as permissive Apache-licensed FOSS, assuming that if Matrix was successful, folks would want to fund it.
In practice, by 2023, Matrix was very successful... but it transpired that the vast majority of folks commercially building on the Foundation's Apache licensed code failed to route any funding back to the Foundation (as the hosting body) or to Element (as the primary code contributor), despite many polite requests. As a result, there wasn't enough $ to pay folks at Element to keep working on the core Matrix projects as their day job. So, to keep the lights on, Element stopped donating their work to the Foundation, and changed license to non-permissive AGPLv3 in order to sell AGPL-exceptions to the folks commercialising it. This has helped the situation somewhat (although Element isn't at breakeven yet). Meanwhile, it's left the Foundation focused on governance, the Matrix standards process, trust & safety and hosting core libraries like E2EE and matrix-rust-sdk.
There's no beef between the Foundation and Element over this. In a utopia the projects would certainly have stayed as Apache licensed code in the Foundation - but then again, other standards bodies like W3C or XSF don't publish code these days: it's a phase that a given protocol grows out of once third party organisations get busy building implementations.
Disclaimer: i'm conflicted on this, being project lead/co-founder for Matrix, and then CEO/CTO at Element.
16 replies →
There are ways to get web interfaces for Signal.
But I think the bigger issue is that any platform that controls the javascript sent to you from a web page, can also backdoor/MITM/inject malicious code at any time without you knowing.
>lol Telegram
Did I miss something? what's wrong with telegram?
I'll tell you what's right about Telegram: I don't know how they're the only independent app that seems to be able to produce such a well built UI/UX for a chat application in 2025.
I maintain that someone should fork their codebase and bolt on a different backend (Signal, Matrix, whatever). It's right there and it's very, very good.
(Yes, I know it's not as simple as "bolt on a different backend". You know what I mean.)
22 replies →
I assume it's the lack of end-to-end encryption by default on basic features.
Good service btw, but not the best from a privacy point of view.
16 replies →
I don't understand why you're downvoted for this question.
What's wrong with Telegram is the privacy story. It's not end-to-end encrypted, meaning that the server can read the content of your messages.
I hear that Telegram has a great UX, which makes it popular. But in terms of security... it's wanting.
7 replies →
1. It's not end-to-end encrypted by default.
2. No group chat, even a small one between close friends is end-to-end encrypted.
3. Almost all desktop clients support no end-to-end encryption for 1:1 chats, meaning if you use the desktop client as part of your workflow, you're forced to drop using the end-to-end encrypted secret chats.
4. No cryptographers have ever worked in the company.
5. Horrible teething issues for the protocol:
Telegram hosted a cracking contest back in 2013. Everyone in the industry know they are bullshit, and this was discussed back in 2013 The Fallacy of Cracking Contests (1998) | Hacker News The tldr is, Moxie issued a counter challenge to Telegram where he presented the same goals with already broken primitives like MD5, to break the encryption. Telegram never proved the challenge could be won even under those conditions. (Also again, given that Telegram’s built in backdoor of “people are lazy” exists, the cracking contest was pointless. It doesn’t matter how good the encryption is if the adversary wears you down to hand over the keys).
http://unhandledexpression.com:8081/crypto/general/security/...
https://eprint.iacr.org/2015/1177.pdf
https://web.archive.org/web/20160425091011/http://www.alexra...
https://words.filippo.io/dispatches/telegram-ecdh/
https://mtpsym.github.io/
Also this:
https://blog.cryptographyengineering.com/2024/08/25/telegram...
I set firefox to clear cookies, also using cookies to "strict"
This somehow causes a huge pain to connect to mozilla's matrix instance, and I never understood why. This is a bit ironic since firefox has that feature to clear cookies.
I had to reset password, and do other weird things, I can't remember what exactly.
I hope this MAS thing fixes it.
So unusable for people like me who only surf in private mode
Putting tracking protection to strict essentially makes Firefox violate certain web standards. Developers aren't going to test against that, and if they are they're probably not going to be able to do much about the problems strict tracking protection causes.
If MAS fixes this, it'll be by accident and it'll probably break in the future. Firefox warns against this kind of breakage if you enable strict tracking protection in the settings. You can't have strict tracking protection + websites doing cross-domain authentication working.
I mean, yeah, tracking prevention features basically completely break cross-domain authentication. There are a surprising number of valid use cases that need cross-domain auth (or make the user experience a lot easier). While there are workarounds these days, sometimes it does require deep changes in how auth works
> There are a surprising number of valid use cases that need cross-domain auth
I am not a web developer, but I would disagree with that.
Either web standards respect privacy or they don't, but I would not sacrifice privacy for anything.
Firefox was right to prevent tracking, it highlights how webstandards are just not good. I something doesn't work properly in a firefox private window, to me it should not exist.
13 replies →
How do you prevent them from collecting "Interaction Data"?
https://www.mozilla.org/en-US/privacy/firefox/#bookmark-how-...
I vaguely remember an old MSC or TWIM or something that described (the possibility of) a new authentication mechanism whereby I could set up either a dummy homeserver or something in .well_known that would allow me to use my own domain but without needing to use my own homeserver for the actual traffic. Sort of like an auth-only homeserver, if you will.
Is that part of MAS? Was that initiative ever fully-baked? Or am I just misremembering?
That's .well-known based delegation, which was proposed in MSC1708 in Nov 2017: https://github.com/matrix-org/matrix-spec-proposals/blob/old... and merged into the spec in Jan 2019 (prior to Matrix 1.0 in June 2019): https://github.com/matrix-org/matrix-spec/commit/0347e873efc...
So yes, fully-baked and part of Matrix since 1.0!
Next Gen Auth via OIDC is instead a key part of the (upcoming) Matrix 2.0 spec release - see https://areweoidcyet.com and https://github.com/matrix-org/matrix-spec-proposals/pull/386...
Afaik that's not related to this, that was already possible as a domain alias. I think that feature is called a delegation if I remember correctly.
* Is all matrix.org's server-side for this open source, and able to be self-hosted?
* Do all the Matrix clients need to be modified to support this authentication method?
The new authentication server (MAS) is at https://github.com/element-hq/matrix-authentication-service (AGPLv3) and entirely self-hostable - e.g. https://github.com/element-hq/ess-helm for the brand new official helm charts from Element, or https://github.com/element-hq/element-docker-demo for a very quick and dirty docker-compose setup i threw together.
MAS provides backwards compatibility for the old Matrix auth APIs for existing Matrix clients, so they do not need to be modified to keep working. However, to get the most out of all the new auth features (2FA, MFA, QR login etc. etc.) then clients will need to be upgraded to speak OIDC natively. Element X for instance is already OIDC-native.
https://areweoidcyet.com has more details.
1. Yes. Even the public website is open source. The license is AGPLv3: https://github.com/element-hq/synapse
2. Yes.
Love matrix. Improving the onboarding is a great step. I've seen less technical people have issues in that area until now.
Mostly a desktop/web user myself, hoping all that Element X work will trickle down to us.
> No more typing your password in every client you’d like to log in to.
So. . . how will we log in? This post is heavy on vague promises of greatness but light on concrete details of UX.
If you use e.g., "Sign in with Google" today, you get redirected to your web browser, log in, and get redirected back to the client. This means you can use the saved passwords of your browser, and if already logged in there, you just have to click "continue" instead of logging in again.
With MAS, every login works like that. If you click "sign in", instead of getting redirected to Google, you get redirected to the website of your homeserver, where you can login and authenticate before being redirected back to the client.
The primary benefit of using a standard OIDC flow is that your authentication server can easily add support for passkeys, webauthn, TOTP or captchas, without having to wait for every single client to support these features.
While matrix.org uses MAS for this, providing the same login features as it used to, your organization might want to use Keycloak to connect their homeserver directly to LDAP.
The downside is that you need a full browser to authenticate this way.
> So. . . how will we log in?
I think you will log into your server, and then the server will offer you to give access to the client. The screenshot right below the line you quote seems to show exactly that.
I guess I can believe that, but it's unclear because there's nothing to tell me what that's a screenshot of. The icon in the screenshot is the Element icon, which is a client, so at first glance I figure it's a screenshot of Element. After reading your comment I can infer that it's actually something else (a website?) showing me the icon of the client that wants access. That makes sense, but it's not obvious just from the screenshot.
One reason I ask about this is I always wonder how it will work for someone writing their own client, perhaps a very basic client (or a bot). Any answer that involves "you will click on X" doesn't apply there. As long as there's a straightforward API based way, that's cool. And I assume there is one here. But my experience has been that such changes aimed at "greater security" often make things more cumbersome for small-time developers.
But we'll see. Certainly a smoother login (and logout!) experience for Matrix would be welcome so hopefully this will be a plus overall.
1 reply →
Read the whole blog, and it directs you further for more details. But this blog does tell you they're moving to oidc. That means you will get all the non password flows oidc supports.
This is a reading comprehension problem more than a blog writing problem
This sounds great for large and corporate servers, but a pain for small self-hosted ones. More configuration and external dependencies. Plus additional confusion for non-techy users on those smaller servers.
I don't think this will be required for other servers any time soon, if ever. Clients are going to have to support logging in the oldschool way indefinitely, especially since most Matrix servers are basically unmaintained.
You say that, but Element X (Android & iOS) already lacks full support for the oldschool way. It only supports certain flows therein AIUI.
1 reply →
Congrats to Quentin and all the other contributors to this project.
Discord's ongoing enshittification may create a market opportunity for alternatives in the near future. I'd like to think that Matrix could be a beneficiary of that, but the common-case UX needs to be polished damn well when the time comes if they want to capitalize.
MAS and Next Gen Auth open up the way to things like QR-login (complete with syncing all E2EE state and verification!) which should help enormously with common-case UX.
See https://youtu.be/ZiRYdqkzjDU?t=966 for a demo of it from The Matrix Conference in Sept, or https://youtu.be/lkCKhP1jxdk?t=1832 showing it working in on a fresh instance of element-docker-demo at FOSDEM 2025.
Eh... Discord's enshittified client is still a hundred times more usable than Element — for all its faults, at least Discord is able to deliver and display messages reliably ("unable to decrypt message", anyone?). And for the more technologically oriented, client mods do a lot to improve the Discord UX.
Element X is supposed to improve things, but it's stuck on Android and iOS for the foreseeable future.
I haven't seen that message in literal years.
So Matrix is the new XMPP?
Did XMPP ever use these protocols for authentication?
fwiw, there's a XEP for OIDC in XMPP from last year: https://xmpp.org/extensions/xep-0493.html. ATproto is also moving to it as its primary auth mechanism: https://github.com/bluesky-social/atproto/discussions/2656.
I quickly looked at the MSCs and seems “MAS” and associated MSCs enable OIDC/OAUTH authentication flows (basically integration with your favorite identity provider such as Google or Apple).
I was hoping for matrix homeserver to act as an identity provider as well to give us an alternative to big tech for “identity”.
I suppose I could just setup Ory or other open source IdP, but would have been nice to have an all in one package.
MAS can be used as an OIDC IdP, and in future MAS will be embeddable in Synapse so you can use your homeserver as an IdP in the way you want, all in one package.
That said, MAS is deliberately not a very featureful IdP - it's focused on being the glue between Matrix and OIDC. If you want a more sophisticated IdP then you'll still want to run a dedicated one.
Does actually exist matrix servers for warez?
Anybody tried Simplex? - https://simplex.chat/