4 ms·

I thought signal was highly decentralized? What traffic does the server handle once two clients have "found" each other? Which I believe uses hashes of phone nu

by kortex 6y ago

I thought signal was highly decentralized? What traffic does the server handle once two clients have "found" each other? Which I believe uses hashes of phone numbers.

okso 6y ago
This article from 2018 illustrates the architecture of Signal: https://sorincocorada.ro/signal-messanger-architecture/ https://sorincocorada.ro/signal-messanger-architecture/
- Reedx 6y ago
  Based on that, they use Google, Apple, Twilio and AWS in the backend. All who have shown they are willing to deplatform with little notice as the result of kneejerk public pressure. How easily can Signal replace those dependencies if this comes for them? "Extremists move to secret online channels": https://www.nbcnews.com/politics/congress/extremists-move-secret-line-channels-plan-inauguration-day-d-c-n1253876 https://www.nbcnews.com/politics/congress/extremists-move-se...
  - okso 6y ago
    As far as I know, Google and Apple are only used to send Push notifications to users. These are optional, and Signal on Android can be used without Google. AWS S3 is/was used to share files with other users. It became a standardized API, with many alternatives supporting the protocol, so switching to a different provider or on-premises should not be difficult. Signal intends to remove the dependency on phone numbers, and therefore Twilio, but this has not be done yet.
  - scambier 6y ago
    All IM apps rely on Google or Apple (on their respective platforms) for the push notifications. The alternative is polling in relatively small intervals, but that wakes up the app, which uses the battery without any real usage. And if the OS decides to kill your app's process, your polling dies with it and you don't get notifications.
- kortex 6y ago
  Cunningham's law is a beautiful thing, cheers :)
sneak 6y ago
You are incorrect. Signal is a centralized client-server model.
gaius_baltar 6y ago
(I wrote this in a dupe of this story so I'm posting an extended version of the message here. Maybe it is useful.) Maybe that's a good reason to open for federation and now I wonder if it would be possible to have an user migration between servers without cooperation from the origin server. This would allow users to move to a new one without losing track of existing conversations. Seems crazy, but the reason we can't do this with email is the lack of a generally agreed identity for an user account that does not depend on the server itself. Signal accounts have a "master" key that can provide this and it's only stored in the device and backups (it's the most trusted of all keys, after all). A sketch: - User creates an initial account on server X (account: user@serverX.org), the procedure includes signing a message saying "I use server X since $TIMESTAMP and this is the 1st server that I use"; - Everything works as now. - User wants to change server, so they signs a new message "I use server Y since $TIMESTAMP and this is the 2nd server that I use" (account: user@serverY.org); this message is sent to all chats/groups/contacts and to the old server (as an information only, it may be already down or be non-cooperative). Contacts update the server part of the account and start sending messages through the new one. Maybe the user can still try to contact the old server for a while, for the event it delivers a message from a account that didn't get the first, but at some moment all users will get the new address. Notice: I have no idea of how this can work with sealed senders of other metadata-prevention measures that Signal uses and we all love. Bonus: no more dependency on phone numbers. Or if it goes to an more email-like architecture were users only speaks with their servers, it can adopt concepts from djb's Internet Mail 2000 [https://cr.yp.to/im2000.html https://cr.yp.to/im2000.html]. This will *not* work for current email due to the need of keeping compatibility with the enormous existing user base, but this problem does not exist for a new protocol.
lucb1e 6y ago
Completely wrong, it's a service as centralized as Facebook. Maybe you're mixing it up with Matrix, Briar, or some other decentralized chat system.

by kortex 6y ago

I thought signal was highly decentralized? What traffic does the server handle once two clients have "found" each other? Which I believe uses hashes of phone numbers.

okso 6y ago

This article from 2018 illustrates the architecture of Signal: https://sorincocorada.ro/signal-messanger-architecture/ https://sorincocorada.ro/signal-messanger-architecture/

Reedx 6y ago
Based on that, they use Google, Apple, Twilio and AWS in the backend. All who have shown they are willing to deplatform with little notice as the result of kneejerk public pressure. How easily can Signal replace those dependencies if this comes for them? "Extremists move to secret online channels": https://www.nbcnews.com/politics/congress/extremists-move-secret-line-channels-plan-inauguration-day-d-c-n1253876 https://www.nbcnews.com/politics/congress/extremists-move-se...
- okso 6y ago
  As far as I know, Google and Apple are only used to send Push notifications to users. These are optional, and Signal on Android can be used without Google. AWS S3 is/was used to share files with other users. It became a standardized API, with many alternatives supporting the protocol, so switching to a different provider or on-premises should not be difficult. Signal intends to remove the dependency on phone numbers, and therefore Twilio, but this has not be done yet.
- scambier 6y ago
  All IM apps rely on Google or Apple (on their respective platforms) for the push notifications. The alternative is polling in relatively small intervals, but that wakes up the app, which uses the battery without any real usage. And if the OS decides to kill your app's process, your polling dies with it and you don't get notifications.
kortex 6y ago
Cunningham's law is a beautiful thing, cheers :)

sneak 6y ago

You are incorrect. Signal is a centralized client-server model.

gaius_baltar 6y ago

(I wrote this in a dupe of this story so I'm posting an extended version of the message here. Maybe it is useful.) Maybe that's a good reason to open for federation and now I wonder if it would be possible to have an user migration between servers without cooperation from the origin server. This would allow users to move to a new one without losing track of existing conversations. Seems crazy, but the reason we can't do this with email is the lack of a generally agreed identity for an user account that does not depend on the server itself. Signal accounts have a "master" key that can provide this and it's only stored in the device and backups (it's the most trusted of all keys, after all). A sketch: - User creates an initial account on server X (account: user@serverX.org), the procedure includes signing a message saying "I use server X since $TIMESTAMP and this is the 1st server that I use"; - Everything works as now. - User wants to change server, so they signs a new message "I use server Y since $TIMESTAMP and this is the 2nd server that I use" (account: user@serverY.org); this message is sent to all chats/groups/contacts and to the old server (as an information only, it may be already down or be non-cooperative). Contacts update the server part of the account and start sending messages through the new one. Maybe the user can still try to contact the old server for a while, for the event it delivers a message from a account that didn't get the first, but at some moment all users will get the new address. Notice: I have no idea of how this can work with sealed senders of other metadata-prevention measures that Signal uses and we all love. Bonus: no more dependency on phone numbers. Or if it goes to an more email-like architecture were users only speaks with their servers, it can adopt concepts from djb's Internet Mail 2000 [https://cr.yp.to/im2000.html https://cr.yp.to/im2000.html]. This will *not* work for current email due to the need of keeping compatibility with the enormous existing user base, but this problem does not exist for a new protocol.

lucb1e 6y ago

Completely wrong, it's a service as centralized as Facebook. Maybe you're mixing it up with Matrix, Briar, or some other decentralized chat system.