Signal's Server repo hasn't been updated since April 2020(github.com)
github.com
Signal's Server repo hasn't been updated since April 2020
https://github.com/signalapp/Signal-Server
7 comments
Guess why they require a CLA to be signed:
Without publication of the source code, Signal is treating the server code as non-AGPL. This is totally within their rights, since they own the code, including contributions, thanks to the CLA which allows re-licensing contributions under an OSI license, not all of which require disclosing source code for network services.
https://community.signalusers.org/t/where-is-new-signal-serv...
https://community.signalusers.org/t/where-is-new-signal-serv...
There isn’t that much that needs to change to back end code for a messaging app from one month to the next. The frontend app and backend infra may well have changed significantly with the recent surge of new users after WhatsApp-gate. But that doesn’t always result in changes to the code running the backend messaging services.
I dont agree. I tried to build and start the self-hosted signal for myself. As I know, version 5.1.0 of android app doesn't work with current server 3.21, but app version 4.66.1 works fine. I mean, app does not work as planed, of course you can write messages to yourself and send SMS, but you cannot find out if a user is registered number with a signal server and cannot start signal chat with him. All because of that, since 5.1.0 accesses /v1/attestation/<UUID> and gets 404, and 4.66.1 accesses /v1/profile/<number> and gets a valid server response.
This is a fastly growing messaging startup we're talking about. You may be right, but to me it sounds highly unlikely they haven't had to make even the slighest patch to their server code in 10 months.
Given most of the complaints about signal are UI/UX, it wouldn’t surprise me if most of that time has been spent client side (and that’s naturally going to have the larger code base too). Plus many of the backend stability problems might just have been solved by “let’s throw another server in” (not a philosophy I 100% support but given dev resource is finite and people usually judge software by the client side experience, I couldn’t blame Signal if that’s how they’ve been operating).
Also let’s not forget that Signal was founded 6 years ago so they’ve already had some time to work on their backend code already (and in a sector that isn’t exactly lacking of research papers and prior art for solutions).
Also let’s not forget that Signal was founded 6 years ago so they’ve already had some time to work on their backend code already (and in a sector that isn’t exactly lacking of research papers and prior art for solutions).
Take your point, though given it's all E2E, the server logic doesn't need to be that complicated, or changed with new features, since every new feature can be implemented as a message. Server just needs message queues and routing?
I'm aware they're looking at backup features and such, wondering if they'd be part of the server, or a different system.
I'd expect some improvements to performance and such, esp. as they grow, so good catch on the 10 month wait, but it's an orange flag rather than red flag to me.
I'm aware they're looking at backup features and such, wondering if they'd be part of the server, or a different system.
I'd expect some improvements to performance and such, esp. as they grow, so good catch on the 10 month wait, but it's an orange flag rather than red flag to me.
Since the Signal platform does collect metadata, even though it’s very less compared to what other platforms collect, anyone who trusts Signal must assume that any metadata collected by Signal could possibly be available to people whom it shouldn’t ideally be available to. Is that really bad? Can’t say, unless you look at your threat model, what’s important to you and the mitigation factors to consider.