3 ms·

> Maybe what we lost is actually the potential to develop alternative, peer-to-peer, decentralized systems. For this to work properly one needs (a) mostly reli

> Maybe what we lost is actually the potential to develop alternative, peer-to-peer, decentralized systems. For this to work properly one needs (a) mostly reliable addressing and routing, and (b) mostly online systems. IPv4 and IPv6 were indeed developed for both (a) and (b). But both started to disappear when laptops overtook desktops, which would be over a decade now, and became completely irrelevant when mobiles overtook computers (laptops + desktops). It's the world that has changed; it cannot come back in IPv4 due to address exhaustion, and won't come back in IPv6 because (a) requires stable addresses -- meaning VPNs for everyone -- and (b) requires the physically impossible "access to data when phone is out of battery and/or in a Farady cage". The server-in-the-middle is a must for reliability; People who seriously use Syncthing or btsync instead of Dropbox have to set up at least one "constantly on" server because of both (a) and (b) above. The last remaining use case for peer-to-peer is, I think, live (chat/voice/video) one on one conversations - and while it's an interesting and important use case, it can (and has) been solved with stable servers-in-the-middle, and I don't believe it is significant enough (or was, or will be) to stop progress; MinimalT makes much more sense than IPv6 or QUIC as a way forward, but we're unlikely to ever have that at scale.

cesarb 7y ago
> requires stable addresses -- meaning VPNs for everyone The true requirement is for a stable identity, not a stable address. You just mentioned Syncthing, which is an example of this: every Syncthing node has a stable identity (which is its public key), but not necessarily a stable address. All you need is a way to map the identity to the address, which does not have to be centralized (even though the current implementation in Syncthing, outside of broadcast-based local address discovery, is centralized); bittorrent DHT manages to map a torrent's hash to a set of addresses without needing any central node. > requires the physically impossible "access to data when phone is out of battery and/or in a Farady cage" [...] People who seriously use Syncthing or btsync instead of Dropbox have to set up at least one "constantly on" server You stated the solution yourself: to access the data when the phone is offline, mirror it to a node which is online. Just because these particular protocols require you to set up your own always-on node doesn't mean it's a hard requirement; some older peer-to-peer protocols from over a decade ago already securely mirrored data in nodes belonging to other users.
- beagle3 7y ago
  > All you need is a way to map the identity to the address, which does not have to be centralized (even though the current implementation in Syncthing, outside of broadcast-based local address discovery, is centralized); bittorrent DHT manages to map a torrent's hash to a set of addresses without needing any central node. That's true; but I think bittorrent DHT is the only decentralized one that seems have succeeded (I remember quite a few unsuccessful attempts two decades ago), and its success is probably related to its use case - it is of everyone's interest to have hashes well-mapped in case you'd need them. > Some older peer-to-peer protocols from over a decade ago already securely mirrored data in nodes belonging to other users. And for various reasons, they are all gone, whereas e.g. rfc822 email - which is properly decentralized/federated but does require a stable online node, is still going strong nearly 40 years later, despite somewhat successful attempts to re-centralize it by the likes of google. I think it's inherent - many people now only have a phone, but no one wants a service that becomes unavailable when you lose your phone or step in a faraday cage -- there even used to be on-phone voicemails back in the dumb phone days -- as peer to peer as dumb phones can get -- and they were not popular for the same reasons. And if it is indeed inherent, it would be better to take it into account when designing the next stage.
kortilla 7y ago
Where did you get the idea that we need stable addresses? This was solved with DNS, registration protocols, dhts, etc decades ago. Nobody has had stable addresses forever.
- beagle3 7y ago
  stable in the "for the next few minutes" sense, which you do need e.g. for mobile phone or video calls. With mobile phones your address can change every few seconds as you drive on a highway and get passed between cells and even carriers. DNS never solved this, DHTs didn't either; and I'm not familiar with a DHT that is actually successful except for bittorrent despite many attempts, even for "stable for a few hours" case. All the cases that sort of work (RTMFP flows, SIP registrations, old Skype, ...) essentially have peer-to-peer communication as a server-offload optimization (that is, peers may talk directly to each other after the server arranged everything iff the stars aligned correctly), not as their main method.

cesarb 7y ago

> requires stable addresses -- meaning VPNs for everyone The true requirement is for a stable identity, not a stable address. You just mentioned Syncthing, which is an example of this: every Syncthing node has a stable identity (which is its public key), but not necessarily a stable address. All you need is a way to map the identity to the address, which does not have to be centralized (even though the current implementation in Syncthing, outside of broadcast-based local address discovery, is centralized); bittorrent DHT manages to map a torrent's hash to a set of addresses without needing any central node. > requires the physically impossible "access to data when phone is out of battery and/or in a Farady cage" [...] People who seriously use Syncthing or btsync instead of Dropbox have to set up at least one "constantly on" server You stated the solution yourself: to access the data when the phone is offline, mirror it to a node which is online. Just because these particular protocols require you to set up your own always-on node doesn't mean it's a hard requirement; some older peer-to-peer protocols from over a decade ago already securely mirrored data in nodes belonging to other users.

beagle3 7y ago
> All you need is a way to map the identity to the address, which does not have to be centralized (even though the current implementation in Syncthing, outside of broadcast-based local address discovery, is centralized); bittorrent DHT manages to map a torrent's hash to a set of addresses without needing any central node. That's true; but I think bittorrent DHT is the only decentralized one that seems have succeeded (I remember quite a few unsuccessful attempts two decades ago), and its success is probably related to its use case - it is of everyone's interest to have hashes well-mapped in case you'd need them. > Some older peer-to-peer protocols from over a decade ago already securely mirrored data in nodes belonging to other users. And for various reasons, they are all gone, whereas e.g. rfc822 email - which is properly decentralized/federated but does require a stable online node, is still going strong nearly 40 years later, despite somewhat successful attempts to re-centralize it by the likes of google. I think it's inherent - many people now only have a phone, but no one wants a service that becomes unavailable when you lose your phone or step in a faraday cage -- there even used to be on-phone voicemails back in the dumb phone days -- as peer to peer as dumb phones can get -- and they were not popular for the same reasons. And if it is indeed inherent, it would be better to take it into account when designing the next stage.

kortilla 7y ago

Where did you get the idea that we need stable addresses? This was solved with DNS, registration protocols, dhts, etc decades ago. Nobody has had stable addresses forever.

beagle3 7y ago
stable in the "for the next few minutes" sense, which you do need e.g. for mobile phone or video calls. With mobile phones your address can change every few seconds as you drive on a highway and get passed between cells and even carriers. DNS never solved this, DHTs didn't either; and I'm not familiar with a DHT that is actually successful except for bittorrent despite many attempts, even for "stable for a few hours" case. All the cases that sort of work (RTMFP flows, SIP registrations, old Skype, ...) essentially have peer-to-peer communication as a server-offload optimization (that is, peers may talk directly to each other after the server arranged everything iff the stars aligned correctly), not as their main method.