Hacker News Reader

The reason Signal is successful is because it at least somewhat reliably works, while Matrix is the worst of fiddleware.

https://blog.koehntopp.info/2024/02/13/the-matrix-trashfire.... explains why Matrix is lacking market share, and I think Signal's decision to be aggressively closed is due to a justified fear of becoming that.

the matrix protocol immediately fell over on syncing huge channels etc tho

They have fixed that with sliding sync but not all clients support that yet.

> but not all clients support that yet

The mantra of every network that stays mediocre and never achieves critical mass

I don't know if there is a straightforward correlation. I agree that my first Matrix experience was also not that satisfactory, but my university switched from XMPP to Matrix. I really liked conversations and quicksy. It just worked for me out of the box even with OTR stuff. However, it seems that there was not enough development on the server side, which I guess it led to the switch by our computing Center. Also the whole German health system as well as the army is switching to Matrix. I still think it is completely over engineered but it has a decent push.

I think this is a false dilemma; you can have the high-quality implementations and be more open.

I've criticized Matrix before for their "protocol-first" approach and "too neutral" stance towards clients (which they've changed somewhat it seems; previously [1] was a table of clients with no clue what to choose, now it at least has "featured clients"). I feel they repeated the same mistakes as XMPP, which has not improved their client list.[2] Protocol nerds will say that's a good thing, but all it really does is ensure your protocol remains marginal because most people just get confused. People choose software, not protocols.

But you can write a high-quality client and a specification and allow people to write their own apps. IMHO Signal is needlessly restrictive. Sure, focus on your own implementation and the quality of that first. 100% the right decision. But there's no reason to not at least allow some things down the line. Signal is just a few months shy of their tenth birthday – they're well past the "ensure the quality of our official client"-phase.

[1]: https://matrix.org/ecosystem/clients/

[2]: https://xmpp.org/software/

At the end of the day, the problem with this model is that it expects free labor to take over the next part. Which might work for a little bit -- until it doesn't. Then you have the situation we're currently in where everything related to matrix is mediocre.

As soon as you do that though, it becomes a nightmare to adjust anything about the protocol, and you end up with incompatible clients. So you can use the app perfectly with friend 1 that has the official app, but with friend 2 who uses one client, sending photos doesn't work, and with friend 3 voice calls don't work, and adding friend 4 to a group chat somehow breaks it entirely for everyone.

Friend 2 insists on using their client because it has dark mode, and for the average user, what they see isn't "friend 2 is extra and has a broken client", they see "that app fails to send pictures about a quarter of the time, let's use whatsapp".

That was a fun read :-)

> https://blog.koehntopp.info/2024/02/13/the-matrix-trashfire.... explains why Matrix is lacking market share

It complains that cyberfurz.chat is a "server with profanity in the name".

...why?

because the author is looking for stuff to complain about, and apparently “furz” means fart in German :|

Easy to use is important and it's a shame that you're downplaying that. More accessible than PGP/OTR? Sure. But maybe by a hair's width of an alligator's back.

If I am working with a source who gets frustrated by the impenetrability of communicating with me because I insist they use matrix while they're not technical and likely impatient, then that person will be much more likely to use a fallback method such as SMS or email, and they'll do it without warning. It's legal risk, period. My job is to make sure that they can share information with me as easily as possible and during a particularly sensitive period of that person's life, usually. Matrix, as a sibling post highlighted well, is too difficult for this use-case. That is an enormous failure for a use-case of sensitive information sharing.

I really like the idea of federation, but I haven't seen it be successful in practice. I can't think of a federated service that isn't also highly centralized. This was a big problem for cryptocurrencies and it's not like email isn't almost all Microsoft or Google. Mastodon has been struggling as well.

While I think there are better services to be private and secure from a technical perspective, there's one killer security and privacy feature that Signal has that on one else does: usability. It's pretty hard to get my grandma onto Matrix, but it isn't hard to get her on Signal. The truth of the matter is that you can't have private and secure conversations if there is no one on the other side. So while I really do like Matrix and the like, I think of them as more alpha or beta type projects. I don't find that the bashing of Signal is helpful (like we also do with Firefox) because all it does is creates noise for people that don't understand the bashing is coming over a nuanced and biased point of view (we're mostly highly tech literate here on HN, it is a bubble. But people still read our comments that aren't). End of the day, if we aren't getting 1 click server installs (or literally everyone is a host), federated systems are going to become highly centralized at some point. PGP's always failed because the easiest way to hack a PGP email was to reply that you couldn't decrypt. It wasn't appropriate for the masses even when it wasn't difficult to use. Don't get me wrong, I love Matrix, but it's got a long way to go to get mass adaptation.

Fwiw, I remember a user awhile back offering a bounty for a decentralized pathway in Signal[0]. The idea was to create an AirDrop like system to help with things like local file sharing but then extend the project forward to create a mesh network. Seems like a reasonable idea to me. I think it may be more advantageous to try to push Signal in the right direction than rebuild from scratch. I'd highly encourage people with other opinions to participate in the Signal community because it is a crazy echo chamber in there and for some reason the devs treat it as a strong signal.

[0] https://community.signalusers.org/t/signal-airdrop/

There is still a huge difference between a totally centralized system and partially federated one.

An analogy is the U.S. is a two-party system, but most would consider this significantly different than the one-party system in North Korea or Russia.

A federated system with a few large players is still much better than a centralized one.

I agree with all this, but only to a certain extent. The big disadvantage of a centralized system is the ability to control an entire ecosystem. The same reason we dislike monopolies. It's because monopolies of any kind have the ability to abuse their power, though that doesn't mean they do. I mean browsers are "decentralized" and that doesn't stop Google from exerting significant control, especially considering most browsers are chromium (I find it weird people say to fight Chrome by switching to a different color of Chrome).

Like I said, I'm all for Signal becoming federated. It's why I dropped that link to the airdrop feature request. I'd also be in favor of people running their own servers. I mean the server code is available, you just can't connect it with the main network. So as far as I see it, there's nothing stopping this from happening. I see a lot of people complaining but I'm not aware of any major roadblocks. That doesn't mean there aren't any, but I'm just not aware of any. And fwiw, there are alternative Signal clients like Molly[0]. So at least the app can be disjoint from the official ecosystem.

[0] https://github.com/mollyim

Signal has said that they don't want a decentralized network until they have settled on their standard and implementation as they see decentralized federation as what has prevented email from modernizing . I'm assuming they will never get to the point where they feel Signal is stable enough to decentralize.

I'm not sure why people keep responding with this. Signal doesn't want to work on the federated problem, sure, I'm well aware. But everything is open source. We're on a forum of hackers, makers, and programmers. So what is in the way? People keep saying "Signal this" "Signal that", what are they gonna do, stop sourcing the code? Ruin their entire business model? I doubt it. The code is open, so seriously, someone tell me what's stopping you all from creating a federated version?

A) it's already been done. There are forks already.

B) Network effects drive the value of tools that are networked. The forks aren't popular at all.

C) Signal is well funded and not in financial trouble, so they can sustain effort on development and infrastructure.

D) I suspect you already knew all this too. So why did you respond the way you did?

XMPP cries in a corner. I wish XMPP had more accessible (to the general public) desktop clients. Conversations is great, but speaking from experience, people aren't going to want to use Gajim because it looks like it's ten years old (even though that's a good thing ;). XMPP needs better clients in general. The last time I used Profanity it had very annoying bugs about sending and saving OMEMO encrypted files.

in a world where iOS users won't install another free app from the app store because they already use iMessage, matrix is like asking for your friends to perform calculus just to talk to you.

Sure, but I don't see whatsapp/telegram as worse realistically if you've already lost at that level.

Signal is very much in the same area of: "trust us".

With a caveat that they also say: "here's a bunch of information on why you should: but you can't really verify any of it and we have proven bad faith before- also we have an army of people who will pile-on if you call us out for not being actually verified, so, just trust us- we are the secure messenger and all those scary things are just so we are easy to use".

Pretty much, Signal is more dangerous for giving that false sense of privacy while you need to trust them just like other messaging apps, no thanks.

> Signal is more dangerous...

Definitely not true. Facebook literally censors private conversations. You simply can't send certain text strings to your friends. That is far more dangerous than relying on a third party that claims to be protecting your privacy. Especially since all signs point to them being honest.

What strings can't I send over WhatsApp?

I don't know about WhatsApp (but I also didn't mention WhatsApp), but go to FB Messenger right now, open up a conversation with yourself, and try to send a message containing the string "thedonald.win". You'll get an error message saying "Couldn't send", with no further explanation. The list of banned strings used to be longer, but they've unbanned a lot of them since the election ended.

To be clear, this is in private conversations. Not just posting publicly on Facebook or w/e.

Just tried with and without quotes and it sent fine. This was on Messenger version 445.0.0.41.109 on Android 14.

Could be regional. Are you in the US?

I'm in the UK.

I read somewhere here that, in the case of what's app more metadata is shared with meta, and telegram doesn't have E2EE by default for groups. Didn't check though.

You're correct. There are more security features with signal too like the server stuff. It's true that they don't update the code enough but the parent is being overly critical. It's not like WhatsApp is giving us access to the server in any form. So it's not a fair comparison. (Edit: Also, the app can be built from source and you can verify that the communication isn't happening in a way where the server could decrypt it. So it's not too big a deal that the server isn't perfectly up to date on public commits)

To their point, there are benefits to federated systems. But I've yet to see a federated system have moderate to large usage without becoming centralized. Think email. And until this problem can be solved you're still left with a "trust us" problem. There's no trustless system out there, yet. But hopefully it comes in the future. In the meantime, signal is the best if you also want to communicate with anyone that can't tell you if a stack is FIFO or LIFO (or even know those acronyms).

Funny enough the best way I found to convince iOS users to talk to me on signal is by telling them it's like iMessage but cross platform. Sure there are differences but most people aren't using those features. I do think signal could really benefit by just linking signalstickers.com into the app since that's the biggest complaint I actually get.

We really should convince Moxie Marlinespike to push the implementation of an out-of-the-box working bridge between the Signal client and the Matrix network. With e2e encryption, of course.

I think we're definitely approaching time when Signal / WhatsApp / Facebook Messenger / Google Messages / Matrix / etc will all become at least somewhat interoperable, and it's gonna happen very fast (~Q3), mostly because EU's Digital Markets App is basically forcing them to. (Well okay, only Meta-owned platforms are forced to.)

Matrix did an interoperability talk on FOSDEM (https://fosdem.org/2024/schedule/event/fosdem-2024-3345-open...) and it's basically confirmed (https://www.wired.com/story/whatsapp-interoperability-messag...) there was some experimental work done on connecting WhatsApp (and ergo every other Signal protocol compatible app) and Matrix.

From Moxie himself (excerpt from Github issue):

> It is unlikely that we will ever federate with any servers outside of our control again, it makes changes really difficult.

> ... I understand that federation and defined protocols that third parties can develop clients for are great and important ideas, but unfortunately they no longer have a place in the modern world. ...

Also, hasn't Moxie basically left Signal?

Signal has its problems, some of them sever. It's also buying "us" much needed time to build out federated and self-hosted chat platforms.

I truly believe they are altruistic, although it is unrealistic to expect that to last forever.

By the way, some of the claims you made about their "bad actions" are actually false. And Matrix is still incredibly annoying to work with for "normies" and only recently got first-class E2EE and retention policy, both things needed for a secure chat experience. And btw, those things aren't deeply supported in the ecosystem, and also it doesn't have client feature flag alerting (to allow good intentioned clients to de-facto report they don't support certain security features).

I do think Matrix (or something like it) is the future, but it's certainly not the present.

*severe

Matrix?! As someone who runs is own Matrix homeserver, oh, man, no way. Matrix is super fiddly, unreliable, and user-unfriendly (and I say this as someone who has at times agreed that Signal can be user-unfriendly).

Matrix also is just not particularly private. Servers control and know far too much about users, and pretty much no mainstream client enables E2E encryption by default. Matrix is an impressive piece of technology, but it has a long way to go before it's as usable for an average mobile phone user as Signal is.

Just because a project is open source doesn't mean everything the team works on or releases will be in the public eye, nor does it even imply that it has to be open source as well.

That's not what this is about.

It's not just any open-source project.

It's a privacy-orientated open-source project.

They could at least BSL the server code and allow others to verify the server code and host but not compete.

> They could at least BSL the server code and allow others to verify the server code and host but not compete.

This is exactly what they do (except they use AGPL): https://github.com/signalapp/Signal-Server

I agree about the passing utility of Signal [0] but Matrix (which I do use) is a barely adequate dumpster fire. They spent all this effort developing a generic synchronization protocol, but yet didn't include native encryption in 2014 and had to bolt it on as an afterthought? And the last time I tried to find a native client it seemed like they were all still using web engines for rendering (inherently slow and insecure), presumably because the markup is too complex to make straightforward native apps.

[0] I don't even use Signal. My tack is to isolate and contain my "mobile phone" device as much as possible (when I'm home it generally stays next to the door on a charger). Whereas Signal has been designed around that single device as a critical part of my life. When I can sign up using only a username, and use Signal from a native client or web browser without any sort of Android device in the picture, then I'll be interested.

They don’t and can’t disallow third party clients. The client is GPL.

https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

> If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.

Wow, I never really followed Signal's anti-federation drama that closely, but reading that thread is nuts. The LibreSignal folks just don't get it, despite Moxie's clear (at least to me) and plain language. The entitlement there is mind-boggling.

The license in the repo says otherwise, and the license is what governs your use and modification and redistribution of the client app, not their indignation.

Forks are a natural consequence of releasing free software. This is the life they chose.

Also, free software isn’t a product.

The ToS is the only thing that governs end users connecting to the API, and it doesn’t deny end users the use of third party clients. Also, even if it did, that would be insane, like Google saying you can’t even load google.com when browsing with Firefox. It would be pretty much without precedent on the web, and bonkers.

The GPL is the only thing that governs developers’ use of the client codebase. The GPL of course allows forking and modification and redistribution.

Such forks and redistributions obviously cannot use Signal’s trademarks, so LibreSignal was dumb to do so. Ultimately the feelings of the Signal team don’t matter here - only the license under which they officially released the code. You can’t be more explicit about permitted uses than that.

You can’t be open source but then claim you don’t want forks. It’s one or the other.

> The ToS is the only thing that governs end users connecting to the API, and it doesn’t deny end users the use of third party clients.

"You must not (or assist others to) access, use, modify, distribute, transfer, or exploit our Services in unauthorized manners" [1]

By my reading, the ToS does deny the use of third party clients. Someone could try to argue that a third party is using the services in the same manner as the authorized first party client, therefore it doesn't break the ToS; but since the company's leadership have said that's not OK (causing the mentioned client to stop being updated), I'd assume that if that argument worked in court, they'd just change the ToS to be more explicit about stopping it.

[1] https://signal.org/legal/

Who would you take to court? LibreSignal is simply distributing software, it's the users who are potentially breaking Signal's ToS by connecting to their servers using unauthorized clients.

This is like attempting to sue qBittorrent for copyright infringement.