3 ms·
While this might solve distributing content serving, i'm still stuck with transporting all my data through my single point of failure + spying ISP, when all of
by Too 9y ago
While this might solve distributing content serving, i'm still stuck with transporting all my data through my single point of failure + spying ISP, when all of my neighbors live within wifi-range.
For a truly distributed network we should look into ways to make internet work more like a mesh.
Back in university, all the student dorms were connected to the same internal campus network, back then internet was slow but you could still share files blazingly fast with all the other students on the network (using DC++ at that time). While this wasn't exactly a pure mesh either it shows that local data works and beats internet many times, even with just a few thousand clients. Then DC++ was mostly focused on pirated content but with a more human friendly solution, like IPNS, it's not unimaginable that average Joe neighbor with one click can create a local mirror of the whole Wikipedia for you.
- lgierth 9y agoIPFS can discover other nodes in the same local network via mDNS -- you don't need to have an internet connection at all to share data locally. Combine this with the recent work on PubSub [1] and CRDTs [2] and you can make many applications work locally, that are otherwise annoyingly strongly coupled to internet services (thing Etherpad, Google Docs, Skype, Github, etc.) > For a truly distributed network we should look into ways to make internet work more like a mesh. Yes! We'll be putting more work into the network stack (libp2p) in the coming months. IPFS itself has done a ton to rework how content is defined and moved around, and libp2p will do the same for the network connections underneath. Think overlay networks, cryptokey routing, packet switching. [1] https://ipfs.io/blog/29-js-ipfs-pubsub/ https://ipfs.io/blog/29-js-ipfs-pubsub/ [2] https://ipfs.io/blog/30-js-ipfs-crdts.md https://ipfs.io/blog/30-js-ipfs-crdts.md