Comment by smt88
2 years ago
Is Signal considered to be (or attempting to be) an open ecosystem?
My understanding is that Signal (the app) is private, not anonymous, centralized, and closed.
The underlying protocol is open and could be used for an open ecosystem, but I didn't think Signal aspired to do that.
The apps and most of the backend are open source too, not just the protocol.
The important distinction is that it's not decentralized like XMPP or email, which is a conscious decision: it would become very difficult to change it to add new features and they'd be left behind by closed-source competitors (see: XMPP).
I see that it is a ton of wishful thinking and FUD on the side of Signal to claim that: XMPP is alive and kicking, has all the features one needs, runs everywhere, at scale, offers the same or better crypto, better privacy, better resilience and is more sustainable. When Signal will inevitably fail/turn against its users/enshittify itself or get acquired, all federated and P2P protocols will keep on going. For decades. That's the kind of communications systems we should be demanding in the present era, nothing less.
Yet I'd wager most HN readers have a grand total of zero XMPP contacts. Myself included. Proving the GPs point.
9 replies →
Is it really a wish if it's already come true? I can't name a single person who uses XMPP. If a federated chat protocol ever wins, it'll probably be something more modern like Matrix. At least there's email too.
> My understanding is that Signal (the app) is private, not anonymous, centralized, and closed.
You are right about that. There used to be an open source build called LibreSignal
Moxie Marlinspike made clear [1]: You may inspect the code. You are even allowed to compile it. You are not allowed to connect your self compiled client to our message servers. We are not interested in a federated protocol. Make sure your fork creates its own bubble that does not overlap with Open Wisper Systems. Stop using the name Signal.
[1] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
Both the app and the server is open source
https://github.com/signalapp/Signal-Android https://github.com/signalapp/Signal-Server
There are forks like Session which doesn't require a phone number to sign up
https://github.com/oxen-io/session-android
I understand this, but Signal doesn't attempt to tolerate third-party apps on their servers as far as I know. They don't support interoperability.
You can run Signal app forks on the Signal server. Molly is a popular one. You just can't create new servers. I wish you could, but I get the reasoning of not wanting honeypots. But that doesn't stop you from running your own network of Signal servers. So I don't see anything stopping anyone. I mean Mullvad runs their own stuff and I don't see half the complaints about them. I've always been curious why Signal is so unique here. If 1/100th the people that made these concerns developed a open community of signal servers, I'm sure we'd have a viable alternative network. What's stopping everyone?
8 replies →
They've described what they're attempting to be here: https://signal.org/blog/the-ecosystem-is-moving/
Moxie's post looks solid, but there is a counter example: bitcoin nodes. They are a very loose federation of nodes that go through regular upgrades in the protocol. So it is possible.
But yes, it's also very hard. The bitcoin protocol didn't start out that way. It took a lot of knocks and bruises to get to the point they could upgrade all the servers in the federation.
Interestingly, the method bitcoin came up with allows protocol changes to fail, meaning the bulk of the federation never takes them up. Everyone gets a vote, and it only succeeds if the bulk of the federation upgrades. Perhaps from Moxie's point of view that's unacceptable, as it means he is no longer the dictator of the protocol.
Nonetheless, it is possible to design a protocol so it can be upgraded relatively quickly. Even if you don't do add "quick transition" features to a protocol transitions can still haven. IPv6 will replace IPv4. But as Moxie says, it's painfully slow.
The author is no longer CEO, though, and there are a lot of "I" statements in the post. Is it still accurate? Has the current CEO made any comment on it?
It's a great encapsulation of why Signal is not federated, and, unless you find the current CEO stating otherwise, is unlikely to change. Changes like the one detailed in the link simply wouldn't be possible to roll out efficiently in a federated ecosystem.
Signal has consistently focused on helping /most/ users do what they want with the app without sacrificing security. This change - away from requiring phone numbers - helps plug one of the biggest criticisms, both on the security and product side. Nothing about their mission requires federation, so I respect that they haven't sacrificed their mission in order to do it.
Matrix debunked these arguments: https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom...
I tested matrix in 2021 and found the experience pretty darn awful outside the main client. And by a cursory glance the ecosystem is still pretty much controlled by the matrix.org folks. When I was using it there was a lot of accusations that Synapse did not follow the specification and that server implementera had to reverse engineer what Synapse did to be able to federate.
And talking about that: does federation work properly yet? I used a third party provider and it made my life miserable.
I am all for federation, but in my experience the "federated" part of matrix was a lot worse than the jabber one they want to replace.
1 reply →
It's not [attempting to be an open ecosystem]. Their ToS used to forbid using third party clients. I don't think this has changed. They haven't banned anyone for using third party clients (to the best of my knowledge), but they're openly against an open ecosystem.
It's private, centralised and the network is closed (e.g.: non-federated), but the source code is public and open source. I think that for the server implementation they do code dumps every once in a while, rather than continuously keep it public.