We rarely get to see an app have to grow suddenly like that. And with Signal being open source, it must be very educational to follow.<p>Has anyone found a publication around what they had to do on the technical side (code)?<p>Edit: Their server's repo hasn't been updated since April 2020. Why?<p><a href="https://github.com/signalapp/Signal-Server" rel="nofollow">https://github.com/signalapp/Signal-Server</a>
This was a painful episode, but on the bright side, the team is sure to have learned a lot. Hopefully they won't have bled too many users. Looking forward to a more stable Signal in the future!
I have been following the changes on GitHub in the last 2 days, I wish they would actually add comments to the commits to explain the reasons of change or further info.
I think they have issues with message retrying and spamming the server.<p>- They added handling of HTTP 508 and do not retry jobs in this case<p>- There is a list of HTTP errors that are handled manually, including the new HTTP 508, but for example 503 is not handled and Jobs (e.g. messages) will be retried indefinitely and I have seen logs with many 503 entries and retries.<p>- They have increased the maximum backoff time from 30s to 60s (+ added jitter) and it can now also be changed remotely via server flag.<p>- Any HTTP error not handled explicitly is considered an IOException (strange?) and retried. List of handled HTTP exceptions (413, 401, 403, 409, 410, 411, 423, 499 and 508) is here: <a href="https://github.com/signalapp/Signal-Android/blob/2c1c6fab3560ef12996030cf7c84cc0d895e329e/libsignal/service/src/main/java/org/whispersystems/signalservice/internal/push/PushServiceSocket.java#L1439" rel="nofollow">https://github.com/signalapp/Signal-Android/blob/2c1c6fab356...</a> I personally would not repeat requests automatically by default on any HTTP error - unless handled manually (so reverse logic), only on connection error.<p>- They have just switched off OkHTTP automatic "silent" connection retries: <a href="https://square.github.io/okhttp/3.x/okhttp/okhttp3/OkHttpClient.Builder.html#retryOnConnectionFailure-boolean-" rel="nofollow">https://square.github.io/okhttp/3.x/okhttp/okhttp3/OkHttpCli...</a>
I don't think they have tested this enough, it's more of a blind try and I think it can decrease request delivery reliability.
The OkHttp implementation retries requests silently (with backoff and retry limit) in case of: Unreachable IP addresses, Stale pooled connections, Unreachable proxy servers. This is transparent to the application. In the past I have complained to the OkHttp team that POST requests should not be retried at all and they fixed it (your requests need to be idempotent anyway, regardless of this).<p>- I believe they may be also having issues with requests that are non idempotent and have been retried by OkHttp silently or in cases where application has sent something to the server and server received it, but the response has never made it back to the client. In this case client will retry request and this can cause trouble if requests are not deduplicated on server side and idempotent. But this is just my guess.
If you're still having delivery issues in any of your private conversations try "reset secure session" from the chat menu. It worked for me with a couple of my contacts.
I would say one of the most important things they need to compete with WhatsApp is a better desktop client. WhatsApp's client is great because it works in the browser and is a joy to use. It would be nice if people didn't have to be burdened with downloading a big Electron app and then sit through the slow process where it syncs contacts etc. (kind of makes the user feel like it's broken)
Can somebody explain their financial model? How are they paying for the servers and stuff.
The claim "No ads. No trackers." and that they are "free for everyone".
Congrats to the team. I am sure it must have been a stressful one.<p>Some remaining issues:<p>The desktop app on first message in any conversation says: "Partially sent, click for details". When retried, the message goes through, but is not synced with the mobile client (never appears there).<p>PS: Happy Signal exists. It's easy to let inconvenience make you forget it sometimes.
It would be nice to have a self hosted server that you can use with some friends. example: Me and 2 other friends use our own server while with my parents use signal server.
An important point that I didn't see mentioned: Signal implements the "Sealed Sender" feature in order to encrypt metadata (as much as possible).<p><a href="https://thehackernews.com/2018/10/signal-secure-messaging-metadata.html" rel="nofollow">https://thehackernews.com/2018/10/signal-secure-messaging-me...</a><p>That's in my opinion the USP against other (actually or allegedly) E2E platforms like WhatsApp or Telegram.
Glad that is back and happy to see Signal growing, but I really don't like the tongue in cheek tone of Signal on social media, I hope they don't take this route like Telegram (who is becoming a social media platform itself with feature bloat).<p>Hope Signal adapt a serious tone and keep the product thight adding features for privacy and security.<p>Just a personal preference, maybe the hip tone helps to grow.
Is there any way to send messages via Signal using an API to a previously approved number? i.e. someone accepts my chat, then I can send messages via an API?<p>I cant find much (good) documentation on it..?<p>I have a system that needs to send alerts from an enterprise system, and we need a more secure way than Telegram...
Is it technically possible to have end to end encryption with Signal if it evolved to first attempt to use direct connections via RTC or some other method?<p>If they're incurring serious costs to run, that tells me Signal's days are numbered until it has to start commercializing.