3 ms·

> 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

> 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.
sliken 6y ago
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.
- KoftaBob 6y ago
  I'm very intrigued by these "wallwart arm systems" that you mentioned. Where can I read up on this?
  - sliken 6y ago
    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.

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.

sliken 6y ago

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.

KoftaBob 6y ago
I'm very intrigued by these "wallwart arm systems" that you mentioned. Where can I read up on this?
- sliken 6y ago
  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.