7 ms·

This brings up a question I still haven't gotten a clear answer to: why isn't Signal peer-to-peer like this? What is it about p2p that made it not doable, rath

This brings up a question I still haven't gotten a clear answer to: why isn't Signal peer-to-peer like this? What is it about p2p that made it not doable, rather than Signal's current setup where every message goes through a centralized server before reaching the recipient? Would appreciate any insight.

throwaway94737 6y ago
Metadata.
sandworm101 6y ago
There are practical problems. Does no internet also mean no network connection? Getting two devices to talk to each other without a network is not straightforward. Bluetooth can do it but has range limitations. Wifi can do it to, but there you have to get into very hardware-specific wizardry to move packets between devices without a network router. The target devices, cellphones, are designed to provide network access, to login to a backbone of other devices, not to generate and manage the network themselves. Then there is the issue of encryption. Verifying keys is tricky without a common network. How does one revoke or renew a key? It is possible but complicated. Not something that a messaging app would normally attempt.
- kangaroozach 6y ago
  Thoughts on GeTenna? What about an open source encrypted protocol that uses an RF device like GoTenna on specific longer range frequencies? Anything like that exist?
  - khimaros 6y ago
    Meshtastic
- rjmunro 6y ago
  > Wifi can do it to, but there you have to get into very hardware-specific wizardry Android is supposed to support the standard for this called WiFi direct - https://en.wikipedia.org/wiki/Wi-Fi_Direct#Mobile_devices https://en.wikipedia.org/wiki/Wi-Fi_Direct#Mobile_devices. I've not seen much about it actually being used, though. Apple has its own proprietary thing that it uses for Airdrop, which unfortunately is not cross-compatible.
tleb_ 6y ago
I have this to-watch talk marked as Signal & centralization, so it might provide part of the answer: https://www.youtube.com/watch?v=Nj3YFprqAr8 https://www.youtube.com/watch?v=Nj3YFprqAr8
ajconway 6y ago
The issue with pure p2p is that devices are not always online. Mobile devices usually forbid (or at least highly discourage) executing code in background which doesn’t help either.
deckard1 6y ago
> What is it about p2p that made it not doable Well, everything? Nothing about mobile devices is suited for p2p. Mobile devices are the exact opposite of what you want for p2p to function smoothly. The devices are always going offline, they move around and acquire new IP addresses, they can't run things in the background without significant battery drain. And probably most important: NAT and routing issues. This isn't the '90s where two computers can just freely talk across the internet on any port they want to. At the very minimum you would need a centralized discovery server. At that point you may as well scrap the whole idea anyway.
- zrm 6y ago
  > At the very minimum you would need a centralized discovery server. That's not necessarily true. You could use a DHT. Or have decentralized discovery servers, i.e. your username is user@example.com and then example.com is contacted to coordinate direct communication with user. Or for local networks, use multicast service discovery to find local users.
- bigiain 6y ago
  > Nothing about mobile devices is suited for p2p. Mobile devices are the exact opposite of what you want for p2p to function smoothly. That's true for their (usually) CGNATed cellular data connections and NATed home wifi connections. But if you were happy to consider a solution where "p2p" meant "peers within bluetooth and wifi range of each other can store/forward messages in a mesh" then mobile devices are _exactly_ the piece of hardware you'd want. Add in some IPFS store/forward from opportunistically internet connected devices to allow message passing between disconnected local meshes, and you should build a really interesting (low bandwidth very high potential latency) messaging system. (Note: this "disconnected meshes with opportunistic internet connection" is pretty much what things like LoRaWAN and Meshtastic can do, but using specialised LoRa radio hardware instead of the built in capabilities of every smartphone on the planet.)
- throwaway423322 6y ago
  > Nothing about mobile devices is suited for p2p Nothing about "traditional" p2p is suited for mobile devices. Software has to adapt. Mobile phones would be excellent platforms if it wasn't for software limitations. Having GSM, GPS, WiFi and Bluetooth, while being carried around, make phones the best candidates for location-aware sneakernet-style p2p.
upofadown 6y ago
Forward secrecy normally requires a handshake where both endpoints are online. Signal is obsessively forward secret. The Signal Protocol's claim to fame is that it can do offline messaging while still providing forward secrecy. It very much requires a server to store the required cryptographic state to do so. I guess the restriction could be considered some sort of downside that comes with protocol complexity.
bigiain 6y ago
Because the problem they've chosen to solve is "secure reliable e2e encrypted messaging via the internet". (or something very similar to that) It's a big enough problem on its own. Tacking "p2p" on as well makes it a different thing, which is not what Signal are doing. I want my Signal messages to arrive at my friends Signal clients, even if that's later after they've recharged their dead phone. I don't want my Signal messages to vanish if I (or a friend) is on a WiFi network where p2p is blocked. There's a serious need for a centralised server for Signals goals to be achieved, so they have one. The fundamental design then means the added benefit of _also_ implementing p2p where possible is small, while the effort/cost is high. Of course that didn't build that.

throwaway94737 6y ago

Metadata.

sandworm101 6y ago

There are practical problems. Does no internet also mean no network connection? Getting two devices to talk to each other without a network is not straightforward. Bluetooth can do it but has range limitations. Wifi can do it to, but there you have to get into very hardware-specific wizardry to move packets between devices without a network router. The target devices, cellphones, are designed to provide network access, to login to a backbone of other devices, not to generate and manage the network themselves. Then there is the issue of encryption. Verifying keys is tricky without a common network. How does one revoke or renew a key? It is possible but complicated. Not something that a messaging app would normally attempt.

kangaroozach 6y ago
Thoughts on GeTenna? What about an open source encrypted protocol that uses an RF device like GoTenna on specific longer range frequencies? Anything like that exist?
- khimaros 6y ago
  Meshtastic
rjmunro 6y ago
> Wifi can do it to, but there you have to get into very hardware-specific wizardry Android is supposed to support the standard for this called WiFi direct - https://en.wikipedia.org/wiki/Wi-Fi_Direct#Mobile_devices https://en.wikipedia.org/wiki/Wi-Fi_Direct#Mobile_devices. I've not seen much about it actually being used, though. Apple has its own proprietary thing that it uses for Airdrop, which unfortunately is not cross-compatible.

tleb_ 6y ago

I have this to-watch talk marked as Signal & centralization, so it might provide part of the answer: https://www.youtube.com/watch?v=Nj3YFprqAr8 https://www.youtube.com/watch?v=Nj3YFprqAr8

ajconway 6y ago

The issue with pure p2p is that devices are not always online. Mobile devices usually forbid (or at least highly discourage) executing code in background which doesn’t help either.

deckard1 6y ago

> What is it about p2p that made it not doable Well, everything? Nothing about mobile devices is suited for p2p. Mobile devices are the exact opposite of what you want for p2p to function smoothly. The devices are always going offline, they move around and acquire new IP addresses, they can't run things in the background without significant battery drain. And probably most important: NAT and routing issues. This isn't the '90s where two computers can just freely talk across the internet on any port they want to. At the very minimum you would need a centralized discovery server. At that point you may as well scrap the whole idea anyway.

zrm 6y ago
> At the very minimum you would need a centralized discovery server. That's not necessarily true. You could use a DHT. Or have decentralized discovery servers, i.e. your username is user@example.com and then example.com is contacted to coordinate direct communication with user. Or for local networks, use multicast service discovery to find local users.
bigiain 6y ago
> Nothing about mobile devices is suited for p2p. Mobile devices are the exact opposite of what you want for p2p to function smoothly. That's true for their (usually) CGNATed cellular data connections and NATed home wifi connections. But if you were happy to consider a solution where "p2p" meant "peers within bluetooth and wifi range of each other can store/forward messages in a mesh" then mobile devices are _exactly_ the piece of hardware you'd want. Add in some IPFS store/forward from opportunistically internet connected devices to allow message passing between disconnected local meshes, and you should build a really interesting (low bandwidth very high potential latency) messaging system. (Note: this "disconnected meshes with opportunistic internet connection" is pretty much what things like LoRaWAN and Meshtastic can do, but using specialised LoRa radio hardware instead of the built in capabilities of every smartphone on the planet.)
throwaway423322 6y ago
> Nothing about mobile devices is suited for p2p Nothing about "traditional" p2p is suited for mobile devices. Software has to adapt. Mobile phones would be excellent platforms if it wasn't for software limitations. Having GSM, GPS, WiFi and Bluetooth, while being carried around, make phones the best candidates for location-aware sneakernet-style p2p.

upofadown 6y ago

Forward secrecy normally requires a handshake where both endpoints are online. Signal is obsessively forward secret. The Signal Protocol's claim to fame is that it can do offline messaging while still providing forward secrecy. It very much requires a server to store the required cryptographic state to do so. I guess the restriction could be considered some sort of downside that comes with protocol complexity.

bigiain 6y ago

Because the problem they've chosen to solve is "secure reliable e2e encrypted messaging via the internet". (or something very similar to that) It's a big enough problem on its own. Tacking "p2p" on as well makes it a different thing, which is not what Signal are doing. I want my Signal messages to arrive at my friends Signal clients, even if that's later after they've recharged their dead phone. I don't want my Signal messages to vanish if I (or a friend) is on a WiFi network where p2p is blocked. There's a serious need for a centralised server for Signals goals to be achieved, so they have one. The fundamental design then means the added benefit of _also_ implementing p2p where possible is small, while the effort/cost is high. Of course that didn't build that.