Matrix.org Will Migrate to MAS
matrix.org
matrix.org
Matrix has been great for me and I recommend that everyone else use it!
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...)
Didn't knew about this one. Thanks I'm looking into it!
Did I miss something? what's wrong with telegram?
Good service btw, but not the best from a privacy point of view.
The difference is Moxie isn't an amateur when it comes to cryptographic design. Wikipedia actually lists him as a cryptographer. The company has also employed an actual mathematician/cryptographer, Trevor Perrin.
Meanwhile, Telegram employed the CEO's brother who's a geometrician, which is not the same. You wouldn't hire a dentist to perform brain surgery even though both studied medicine.
Signal protocol's double ratchet is considered best practice by pretty much every competent cryptographer.
MTProto's main issues are not the teething issues of the yester-years. It's the fact every chat is sent to the server that can then read the messages. Telegram only has E2EE in internet debates about it's non-existent E2EE in practice.
> MTProto's main issues are not the teething issues of the yester-years. It's the fact every chat is sent to the server that can then read the messages. Telegram only has E2EE in internet debates about it's non-existent E2EE in practice.
Telegram does in fact have E2EE available in the form of Secret Chats, so that's just an incorrect statement from you.
Regardless, that wasn't what I was rebutting. If anyone is going to have a reasonable debate about Telegram's problems, at least do so reasonably, without resorting to well-worn and facile language invented by the person who has the most to gain from its use. Moxie is not at all innocent in any of this and I'm glad he's no longer involved with Signal, which I use every day.
Its clear which is an actually private chat app. Defaults matter
But if you turn that on, other features turn off.
Yes, but surely you realize a competent cryptographer wouldn't have implemented a backdoor looking design in the first place?
>Telegram does in fact have E2EE available in the form of Secret Chats, so that's just an incorrect statement from you.
No it's 100% correct and you just made my point for me.
1. Secret chats are not used by default, meaning most of users don't even know about it.
2. Secret chats are not available for group chats, not even small ones that have reasonable expectation for privacy.
3. Secret chats are not available for desktop chats, so you can not really use them seamlessly. I've spent six hours in front of my computer today. My phone is 30cm from my left hand. And I absolutely can't be arsed to pick it up every time my friend would send me a secret chat. Telegram's backdoor works exactly this way. They know I'm lazy. They make it my fault. Whereas with Signal, I can just alt-tab into the chats and reply there.
When I said Telegram only has E2EE in internet debates, that means people like you who love to point out it's technically there, but who also fail to understand what it takes for such feature to be even used on a daily basis.
>facile language invented by the person who has the most to gain from its use.
I've been criticizing Telegram for over a decade now. You trying to make it sound like it's Moxie who's the devil pulling all the strings and making my arguments for me, makes you look like an astroturfer employed by Telegram: https://tsf.telegram.org/
But you are being dishonest when you make an incorrect statement like this. Don't do that.
EDIT:
> makes you look like an astroturfer employed by Telegram: https://tsf.telegram.org/
I just read the linked page through: this is a request for volunteers to answer support questions for Telegram. How did you make the mental leap from a request for support volunteers to recruitment ad for astroturfers?
https://tsf.telegram.org/manuals/e2ee-simple#are-cloud-chats...
Talks about "unique distributed architecture" which I have debunked here
https://security.stackexchange.com/a/243172
When people parrot those lies, they're being useful idiots, which Russia has used for ages https://en.wikipedia.org/wiki/Useful_idiot Durov is trained in information warfare and propaganda https://www.nytimes.com/2014/12/03/technology/once-celebrate... He knows what he's doing.
What I asked you to do was to stop misrepresenting your own bizarre theories as fact and stop linking microblog posts and blog posts describing vulnerabilities of a completely rewritten protocol that have nothing to do with its current. That is dishonest and not a reasonable basis for any argument.
There are many ways of honestly portraying the problems of Telegram without resorting to false inventions, such as its immense problem of spam and ads and the fact that E2EE is not available across all devices and for group chats.
Linking to vulnerabilities in a protocol that hasn't been used for 8 years and misrepresenting that fact by omission is simply unethical.
Attack my arguments with reasonable, evidence-based arguments. Do not make personal attacks. That is in the HN rules.
You've presented falsehoods and unfounded conspiracy theories. I've called you out on them. I expect better from any human being on Hacker News and I will continue to, whatever the topic.
It's a good service and in some cases it can compete with Matrix, Signal, etc, but most direct chats and all groups have no privacy from Telegram (and anyone with access to their servers).
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.)
Precisely because they don't spend so much effort for privacy. If your server can read all your messages, it's suddenly easier to provide great features. For instance, GMail can add your next hotel stay to your calendar automatically because it has access to your emails. That's great UX, but poor privacy.
I don't think Telegram's UX is tied to their permissive privacy, but they do seem to start with UX then do what's needed to support it. That does give them an edge. (Instagram has terrible privacy and actively mines information from chat and their UX is only passably good.)
My point is that it's generally harder to add those features in a privacy-preserving way. GMail couldn't do it if it couldn't read the content of the emails, period. It doesn't mean that there is no way to have nice features in a privacy-preserving way. I just said it's harder (sometimes impossible).
> I don't think Telegram's UX is tied to their permissive privacy
Not exclusively, but it is obviously a lot easier! Take a web client: if the server has access to the data, your client can just fetch it. If the server doesn't even know about the existence of the group, that's harder. Why do you think only the "secret chats" are E2EE in Telegram (and those don't support groups)?
> then do what's needed to support it
What do they do to support privacy? They don't have E2EE except in the secret chats! That hasn't changed in a decade!
> Instagram has terrible privacy and actively mines information from chat and their UX is only passably good
This keeps getting further from what I said :). Of course, it's possible to do worse than Telegram!
What on earth makes you think that the same engineers responsible for fluid and smooth UI/UX are the ones who’d ever influence the cryptography/privacy/security? Whether or not the chats are encrypted has zero to do with this.
Telegram has almost universally smooth scrolling, things work well across platforms, it’s native pretty much everywhere with low memory usage and mostly platform specific behaviors. Signal half asses this, and Element is… shoddy, at best, in comparison.
Making a smooth app isn't that hard. Inventing the cryptographic protocols to enable group management without server-side control, and proving their security is the hard part. Something Telegram's developers haven't the faintest idea of how to do.
No, dude. Come on - you really think that plays a role in how smooth a listview renders? Or whether it follows the correct tab focus order? I don't think I could be more clear about what I'm saying in my last comment. Their client side app is incredibly smooth and well built. Signal, Element, etc do not stack up.
> Making a smooth app isn't that hard.
Yes, it surprisingly is. Multiple chat apps in 2025 still fail at this.
> Inventing the cryptographic protocols to enable group management without server-side control, and proving their security is the hard part. Something Telegram's developers haven't the faintest idea of how to do.
This isn't even in the realm of what my point was.
That's not a feature. Stickers is a feature. Calls are a feature. Messages are a feature. Group chats are a feature. Group video calls are a feature. Link thumbnails are a feature. Forwarding messages is a feature.
>Their client side app is incredibly smooth and well built.
Yes, and the Trojan horse was so beautiful John Oliver would totally have hit on it.
Telegram UI is fine, I'll give you that. But it was created at the expense of designing the app private. Move fast yolo security isn't the justification.
They'd have to re-design the protocol from scratch to make it E2EE by default. Hell, you can't even get feature parity with secret chats. E.g., stickers do not work.
Signal might not have every bell and whistle like pinned messages, but when it eventually does, I will know it's done with proper privacy design.
I get that your point is to bore exclusively in the UI/UX with, admiring the forest from the trees. I'm saying the true beauty is with the ridiculously seamless and easy to use end-to-end encryption for everything Signal provides. Both phone app, and all desktop apps stay in sync, all 1:1 chats are E2EE and they are available on all platforms, unlike Telegram where they're limited to phone only. All group chats are E2EE and they're available on all platform, unlike Telegram that doesn't have E2EE for group chats. All chats are E2EE by default, unlike Telegram where no chat is E2EE.
Privacy and security are integral part of every feature. Everything else is a footgun. Arguing about how well the footgun is polished, doesn't make it any less of a footgun.
Signal has over time polished its secure features.
Telegram isn't in the process of securing it's polished turd of a protocol.
K, and? Every comment I've typed in this thread was surrounding how these things are implemented on the rendering layer. Whether or how those are encrypted is of no relation to my point. Badgering on about it more won't help you make a point.
> Signal might not have every bell and whistle like pinned messages, but when it eventually does, [...] > I'm saying the true beauty is with the ridiculously seamless and easy to use end-to-end encryption for everything Signal provides.
You seem to be under the impression that I am knocking Signal as a client, and I'm not. It is my primary messenger.
I just expect better of them and I do not believe for one moment that they couldn't have the UI/UX of Telegram. You are more than welcome to get all tied up in the crypto/privacy/security arguments - I have never argued those because they are (a) boringly obvious points and (b) not the fucking point of my comment chain.
Privacy and security have jack shit to do with how well an engineer implements rendering code, full stop. Telegram does it better and Signal/Element/etc need to do better.
It really depends. People discuss and communicate in public channels like IRC or Discord.
A large chunk of chatting is shitposting with anonymous identity.
Secure chat is only needed in some scenarios.
My calls and texts used to be about me agreeing with my buddies when to hang out. They weren't nearly as private as me keeping in touch with buddies I rarely see IRL, online.
Also, there was a period of transition. Had I known the MSN messenger was completely unencrypted, in that everyone, not just Microsoft, could listen in, I might have felt my privacy violated. I sure as hell feel that in hindsight.
Also feels like missed opportunities :D.
Did you even read my comment? I gave an example of how privacy directly impacts UX: GMail couldn't automatically add your events to your calendar if it could not read the content of your emails. I never talked about engineers, just the technical reality. If you don't have it, you can't read it. That seemed absolutely obvious to me: the best UX for a car would be one that doesn't need a source of energy, fits in my pockets and instantly teleports me anywhere I want. Go ask your engineers to make a car that allows that perfect UX, and see how they react.
Telegram has no E2EE except for the secret chats. Last time I checked, the secret chats were not synchronized between devices (i.e. the privacy has an obvious impact on the UX).
So no, I don't think it was an odd comment. It just feels like you don't know how it works technically.
I'm not even sure you read mine.
> It just feels like you don't know how it works technically.
You're disregarding what I've said and trying to have a different discussion. Please pay attention.
I am not discussing - nor do I consider it relevant to my point - privacy/security/etc contexts for Telegram's client side applications. Whether or not it's encrypted has zero to do with how smooth and well built a chat UI is. I am commenting on the frontend client side engineering and how Telegram has, hands down, the best implementation. Other apps need to catch up.
Ok, let's talk with concrete examples.
1. Say you open the Signal Desktop app: either you don't get the history of the messages, or you need to wait a fairly long time for them to arrive. With Telegram, you get the whole history immediately. Does that count as "smooth and unrelated to encryption" to you?
2. Say you send a message to a group on Telegram and on Signal/Element. On Telegram you see that the message was received noticeably faster than on the others. Does that count as "smooth and unrelated to encryption" to you?
3. Let's talk about GIFs and stickers: I'm sure Telegram has many more than e.g. Signal. Is that something you consider when you say Telegram has a better implementation and it is unrelated to the privacy concerns?
4. Telegram has bots that enable a lot of feature. Does that count?
You're telling me that for the stuff that isn't impacted by privacy concerns, Telegram is better. You seem very sure of that, and maybe that's right. But can you give concrete examples? Because until now, what I've been reading from you is that the UI/UX is not impacted by the privacy, and this is obviously wrong.
So let me ask this: would you agree that at least some UI/UX is impacted by the privacy concerns?
I also frankly don't even get what you're trying to say with point 1, because Signal loads messages instantly for me on Desktop. There's zero delay. The UI/UX of the scrolling and chat display is the problem.
> what I've been reading from you is that the UI/UX is not impacted by the privacy, and this is obviously wrong
It is not obviously wrong, and you've done nothing but attempt to loop the conversation back to some level of privacy/encryption/etc. These things do not matter in this conversation, full stop.
This (my thread, not the greater thread we're in) is a design and frontend implementation discussion, not a privacy/security discussion. If that is not clear to you, I don't know what to say anymore.
Well, you're answering to my thread, if we go like this. Where I said that one reason the UX is better in Telegram is that they don't care about privacy.
> Every single point that you want to try here has nothing to do with implementing a smooth scrolling, buttery UI/UX of a chat application.
Then we fundamentally disagree on what UX means. If it takes 2 days to receive a message because a human has to check that it is not spam, wouldn't you say that it's bad UX? Or is "scrolling" the only thing that you put into "UI/UX"? Do you actually know what UI/UX is?
> It is not obviously wrong, and you've done nothing but attempt to loop the conversation back to some level of privacy/encryption/etc.
Because that's my goddamn point from the beginning on. Privacy has an impact on UX (which means "user experience", by the way), period.
> If that is not clear to you, I don't know what to say anymore.
Same here. You don't seem to understand how privacy works technically, and you don't seem to understand what UI/UX means.
Except we were not going like that, because my thread is tangential to yours, and is all I was discussing.
> Because that's my goddamn point from the beginning on. Privacy has an impact on UX (which means "user experience", by the way), period.
No, it has no impact on whether or not the frontend interface is implemented well. "Virtualized Listviews 101, or how to implement them well" is a course you might consider taking.
> Same here. You don't seem to understand how privacy works technically, and you don't seem to understand what UI/UX means.
I've been pretty transparent with the point of my comment chain, and I've more than enough time on the implementation end of both of these topics. I've asked you repeatedly to stop going off on tangents unrelated to my point (i.e, rendering/frontend UI/etc). If you don't want to do so, that's fine - I certainly can't make you. I just don't need to waste the time arguing with you either.
Have a good day man.
The largest UX hit is when launching a client after it's been powered off for a while.
Telegram uses a symmetric session key. The client can with SINGLE AES-IGE decryption operation decrypt a massive packet containing every message received to every non-secret chat.
Signal uses Diffie-Hellman ratchet or SCIMP ratchet for every received message. That means there's X25519 and AES-CBC involved for every message. It is not, and will never be as fast as Telegram's insecure approach.
Thus the security design will absolutely affect the smoothness of the experience.
But Signal has blazing fast search function since it's local only. Telegram's search functionality freezes when you go over the server's chat history cache limit, to try to find years old posts.
>The UI/UX of the scrolling and chat display is the problem.
My desktop computer loads messages from my Signal history as fast as I can scroll my mouse.
My cheap smart phone loads messages from my Signal history as fast as I can swipe my fingers.
You can solve this with faster hardware.
I'm aware.
That said, if Signal is able to render mostly fine in their current desktop app, then I've no reason to believe that the speed of decrypting messages is a blocker to optimizing the UI layer. Glossy-ness is a factor in why people still use shit like Telegram. Signal has no blocker to implementing it.
This has been my entire point for pretty much every comment in this chain.
> My desktop computer loads messages from my Signal history as fast as I can scroll my mouse. > My cheap smart phone loads messages from my Signal history as fast as I can swipe my fingers. > You can solve this with faster hardware.
Or they could write better UI/UX/frontend-specific code. That layer isn't rocket science.
I sincerely hope you get there, but it's really hard to believe it at the moment. You're not even at feature parity with the app (Element vs Element X) you're replacing, and it's been out for a bit now.
i.e, you have significant user experience related features that keep people using Element (open graph previews, just to name one).
Meanwhile, Element One will support it shortly - the missing piece was MAS in production, which is now happening on matrix.org as per the OP.
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.
It's a bit like if we analysed the E2EE guarantees of email over and over again. Every year, multitudes of people would publish a post explaining how email is "badly encrypted". Well, email is not E2EE, period. If you want E2EE, use a system that has E2EE.
1) Didn't say it was "Heavily encrypted" on its front page.
2) Didn't claim it was more private than WhatsApp which is always end-to-end encrypted with Signal protocol.
3) Didn't claim secret chats were somehow adequate.
They have f'd up in the past, and since they still employ the same incompetent nepo-hirings, they will continue to f up in the future.
Until they own their mistakes and E2EE everything, like they should have done in the first place, I will keep pointing out their incompetence, past and present.
You do not get to rewrite their history by telling people to shut up.
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/
Also this:
https://blog.cryptographyengineering.com/2024/08/25/telegram...
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.
There are reasons to do this, for example if you believe that private industry adopting some technology is good and you want to make that happen.
But people keep seeming surprised by the fact that these donations aren't reciprocated (or at least people don't seem to plan for them to never be reciprocated). It sounds to me like the AGPL license was more consistent with their goals.
The point of permissive licenses is to grant the ability to exclude people from the enjoying the benefit of improvements.
I.e. they're not for creating public goods. They're grants for making it easier to create excludable goods.
I find this comment to be incredibly disingenuous, and just plain false.
Excluding people would only be done if someone took a permissive license and then re-licensed it to something more closed... you've entirely made up a malicious assumption about what people do with the software. And you're even assuming people ARE doing something like this with the software.
A permissive license simply lets you do just about anything you want with it. Some will agree this is more "free". But, freedom TO vs freedom FROM is a common argument.
Apple, as far as I know, doesn't release the FreeBSD fork they use in Mac OS.
Companies generally use a ton of permissively licensed software and don't release forks of it under any license because the entire point of the license is that you can take the code, make modifications, and you have no obligations to give anything back when doing so.
There was an attempt to rebrand "free software" -- meaning software focused on user freedom -- as "open source" -- referring to software permissively licensed for use by corporations. This was the point of the OSI. [0]
> The “open source” label was created at a strategy session held on February 3rd, 1998 in Palo Alto, California, shortly after the announcement of the release of the Netscape source code....The conferees believed the pragmatic, business-case grounds that had motivated Netscape to release their code illustrated a valuable way to engage with potential software users and developers, and convince them to create and improve source code by participating in an engaged community. The conferees also believed that it would be useful to have a single label that identified this approach and distinguished it from the philosophically- and politically-focused label “free software.” Brainstorming for this new label eventually converged on the term “open source”, originally suggested by Christine Peterson.
So literally a decision by a committee of industry folks to play down the idea of freedoms or giving back and focus instead on the business case.
So they killed the ethical argument that favored copyleft licenses in favor of the business argument that favored permissive ones.
Now people are saying "hey it's unfair that you're not giving back." Fair enough, but that's an ethical argument. That's what the OSI was trying to get rid of.
The OSI approach has its place. We wouldn't have Mac OS or Google or Meta without it. But its place is allowing industry to standardize and to reduce costs. Those benefit consumers indirectly since we have fewer competing standards and reduced development costs can imply reduced end user costs. But that only works because each company can make improvements and exclude others from using those improvements; i.e. they can make proprietary improvements.
If the project you include it in does not use the same license, then I think you are technically re-licensing it.
But either way, I don't see how the rest of your comment applies to what I said.
I wonder if there will be any justification for this remark :-)
> Excluding people would only be done if someone took a permissive license and then re-licensed it to something more closed
Yes, that is the only way they can be distinguished. If nobody ever distributes proprietary software including the permissively-licensed code, then it might as well be copylefted.
> you've entirely made up a malicious assumption about what people do with the software. And you're even assuming people ARE doing something like this with the software.
I think this is your point of departure with reality. This happens constantly! Anyone who ever includes permissively licensed code in a proprietary codebase is denying the users of that codebase from the freedoms the upstream developers gave them. The freedom to do this is the freedom to withhold rights from other people. You can choose not to care about that, if you want. But that's what is happening.
When corporations utilize the code and make a good faith effort to contribute back something, no matter how trivial, they are using the source.
Just because it’s legal doesn’t make it right and I feel confident given the current state of the world saying that we should start expecting more from corporations. The idea “they only exist to make money” is how you break the social contract.
What I'm saying is that's the point of the license. That's why universities use the licenses (e.g. MIT, Berkeley) and why Apache uses it. They're designed to stimulate the private sector by moving IP from research into industry (universities) or by industries pooling resources to make software purchases cheaper (Apache).
I don't think it makes sense to describe using them in this way as abusive or bad faith.
I don't agree. Releasing under a permissive license is explicitly saying "dDo what you want with this, including using it commercially without giving back". And if you're saying that, you can't cry "abuse" when someone does exactly what you told them they could do. Because that's what you've done: the license terms explicitly say that.
"Legal" has nothing to do with it; if you want other people to have to contribute their changes publicly, you use a copyleft license. If you don't care, you use a permissive license, and then there's no such thing as "abuse", as long as people follow the letter of the license.
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.
https://support.signal.org/hc/en-us/articles/360007320551-Li...
It doesn't allow you to use multiple phones at the same time.
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.)
(Arathorn: is e2ee metadata still on the roadmap?)
But no, not all your data is exposed. The e2ee parts, like message content in encrypted rooms, are opaque to Cloudflare.
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.
I've long wondered if this is actually true.
If I have a closed-source app and claim (and can verify!) E2EE, surely I could still read every message from my closed-source app, within the app itself, and you'd never know.
I've never been a mobile app developer but I've been a desktop and web developer since the 90s so I don't know what apps can and cannot see but in a desktop app or web app, if it's on the screen, it's decrypted and I can put code in to read/steal it.
Am I missing something here?
I just don't know if that is actually true, or if meta doing e2ee and then pinging your messages around from the app after they're delivered is true. I've no reason to believe either is.
Surely when I open up a chat in Whatsapp it would be as easy as doing a foreach on every msgElement.text value on screen and copying it to the mothership in plain text. After all, when I am reading them, they're decrypted.
Or, when I send a message, as soon as I press the "Send" button, send a copy to the mothership.
Perhaps I'm not seeing it right but it must be this simple. Right?
At least with an open source app you can inspect the "Send" code and see if it calls "SendToMothership" when it also calls "SendToRecipient".
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 also got my partner to switch to it. She’s not a super nerd like me but she was able to figure it out easily enough.
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.
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.
It's also a bit disheartening to see Matrix putting all that "Log in with Google", Apple, Facebook etc so prominently on their login page. The whole idea of decentralised services was getting out of those walled gardens.
I struggle to see why I should trust it with those things but not the account password.
Bubbling up these architectural details to the front end is a symptom of the webdev cargo cult coming up with broken ideas that get fossilized as the status quo.
The alternative would be something where I enter my Google username/password on random websites, and trust that they will forward it to Google and not do anything nefarious. This is less secure and less private.
That's not something companies like Matrix can use. If you're installing software already, why not skip the browser engine and install a full Matrix client instead?
Privacy Pass is currently being standardized by the IETF, so we may see more widespread adoption eventually: https://privacypass.github.io/
If a Privacy Pass token is needed for access to your email, then redeeming the token tells the service you (the client) can access your email. That's identified you.
https://www.mozilla.org/en-US/privacy/firefox/#bookmark-how-...
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.
Is that part of MAS? Was that initiative ever fully-baked? Or am I just misremembering?
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...
Mostly a desktop/web user myself, hoping all that Element X work will trickle down to us.
* Do all the Matrix clients need to be modified to support this authentication method?
2. Yes.
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.
So. . . how will we log in? This post is heavy on vague promises of greatness but light on concrete details of UX.
This is a reading comprehension problem more than a blog writing problem
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.
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.
> I always wonder how it will work for someone writing their own client, perhaps a very basic client (or a bot).
For interactive clients, it'll be the standard OAuth 2.0 Authorization Code flow[1]. For non-interactive services they say in the proposal[2] that one uses the existing method but they will implement the standard OAuth 2.0 Client Credentials flow[3], which is effectively like a traditional username/password deal, though the "password" is not the account password.
[1]: https://learn.microsoft.com/en-us/entra/identity-platform/v2...
[2]: https://github.com/matrix-org/matrix-spec-proposals/blob/002...
[3]: https://developer.okta.com/docs/concepts/oauth-openid/#clien...
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 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.
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.
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.
Element X is supposed to improve things, but it's stuck on Android and iOS for the foreseeable future.