> Signal would grow immensely in my eyes if they made the server code open source [SEE EDIT], and allowed an easy way to set the centralised server address in the Signal app. The current server would be the default, and perhaps changing the server would be hidden in Advanced Options for now.
I feel like this misses the point of what Signal is. It's not just software, it is the network as well. The client is a client that lets you communicate on the Signal network, which is operated centrally. A client that lets you choose a server endpoint is no longer a "Signal client", it's a Signal-compatible network client.
People seem to have an expectation that Signal server API is public, and that it should allow any compatible client to connect, or that a given client to connect to any compatible endpoint (in the spirit of public client/server internetty stuff). From what I can see, part of the whole point of the centralisation is to take that client/server API private so that the 'official' signal server only ever has to support a single client that they also control (hence allowing rapid iteration, avoiding legacy support etc).
> Unfortunately, you cannot change the server address in the app as downloaded from any app store, so my criticism remains.
What's preventing someone maintaining a client fork where you can do this? We have the code to run a Signal-compatible networks and software that can support this, so why does nobody?
>What's preventing someone maintaining a client fork where you can do this? We have the code to run a Signal-compatible networks and software that can support this, so why does nobody?
If you read the link, what's discouraged is using the non official client to connect to the Signal service, or using the "Signal" name on something that isn't produced / run by OWS.
There's nothing there about preventing anyone from running a signal-compatible service/network and shipping a fork of their own client to connect to it, which is my original point.
In fact I’d say it’s actively encouraged to fork both the client and the server. What is not encouraged is just forking the client and using Signal’s servers.
“I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.“
> People seem to have an expectation that Signal server API is public, and that it should allow any compatible client to connect
That's because people have a reasonable assumption that a single actor (however good it is) should not have power over all of our communications. That's why we had federated networks in the first place (HTTP, SMTP, XMPP, DNS). Avoiding vendor lock-in is an important feature for most people.
Of course they do. That's why millions of us have been pushing for years for DNSSEC, TLS (hopefully someday with DANE), Tor onion services, RPKI, etc..
A bad state of affairs is no reason to keep going in the wrong direction.
ICANN's DNS roots are flawed by centralization, and DNS itself is a very insecure protocol. However, DANE is still a major progress over the browser CAs, because you can stop trusting random corporations and state agencies (the CAs, who are known to emit fake certificates) and instead trust your naming scheme.
Agreed DNS might not be the best candidate for this. However DNSSEC validation within the LAN (eg. on your local router, not @Google/CloudFlare) mitigates a lot of risks associated, and a new secure backward-compatible protocol like the GNU Name System (yes that's a thing) may eventually overcome those risks entirely in clever ways.
There's literature and actual deployments on tying name resolution to public key discovery in location-addressed protocols (eg. .onion, .i2p..) and it makes entire sense in my view. If such concerns interest you, check out the latest GNS draft RFC: https://lsd.gnunet.org/lsd0001
No, DANE is a step back from CAs. When the Certificate Transparency logs show a CA has misissued, any of Google, Apple, or Microsoft can destroy that CA, as has happened with several of the largest CAs. Meanwhile, not only is there no such thing as Certificate Transparency for DANE, but you also can't revoke .COM at all.
Pretty much every way you look at DANE, it's a debacle.
I feel like this misses the point of what Signal is. It's not just software, it is the network as well. The client is a client that lets you communicate on the Signal network, which is operated centrally. A client that lets you choose a server endpoint is no longer a "Signal client", it's a Signal-compatible network client.
People seem to have an expectation that Signal server API is public, and that it should allow any compatible client to connect, or that a given client to connect to any compatible endpoint (in the spirit of public client/server internetty stuff). From what I can see, part of the whole point of the centralisation is to take that client/server API private so that the 'official' signal server only ever has to support a single client that they also control (hence allowing rapid iteration, avoiding legacy support etc).
> Unfortunately, you cannot change the server address in the app as downloaded from any app store, so my criticism remains.
What's preventing someone maintaining a client fork where you can do this? We have the code to run a Signal-compatible networks and software that can support this, so why does nobody?