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?
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.
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?
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.
Not really. A DHTs can perform this without a centralized discovery service. Bit torrent for instance uses this, and clients can trade peers without being on the DHT.
Additionally there's so many bittorrent clients that there's millions of machines in the DHT and even a brute force search of IPv4 is't going to take long to find one of the millions, which will happily give you dozens of other peers.
So sure many clients include a bootstrap server for the DHT, but that's needed once and you can skip that if you are willing scan a few 1000 hosts for a client.
I've pondered writing a DHT based client for signal like functionality (sync messages, async messages, and resistance to traffic analysis), I don't see any technical blockers. I get why signal is centralized and does have some attractive features that would be hard to match with a p2p setup. In particular quick startups, low message latency, and battery/network efficiency. With that said I think a p2p e2e chat client is quite feasible.
What would make it MUCH more feasible is people started buying wallwart arm systems (more common years ago), or raspberry Pis and ran a p2p client as a service so that clients in the home could leverage the service for email, chat, file transfers, etc.
None are current AFAIK. I do think that the downsides of P2P could be largely offset by assuming a raspberry Pi or equivalent small system to offset the battery, bandwidth, and CPU penalties that are so hard to justify on Mobile.
So they are of historical interest only, but if you want to did up the history I'll give you some search terms. Marvell had a $99 reference platform called the SheevaPlug CloudEngine had a Pogoplug, CTera had a CloudPLug, Seagate DockStar, GuruPlug, DreamPlug, PylonPlug, sipJack, GeNiJack, etc. etc. etc.
They all had a GHz or so CPU, GigE, 512MB ram, etc.
> 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.)
> 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.
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.
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.
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.
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.