3 ms·
IPFS "solves" the problem of distributing static files - basically, a CDN built on content addressable storage. But if you don't have nodes pinning your content
by dymk 8y ago
IPFS "solves" the problem of distributing static files - basically, a CDN built on content addressable storage. But if you don't have nodes pinning your content, or you're going to loose that data.
The article bills it as some alternative to HTTP, but it's a subset of functionality. You can't do dynamic pages with IPFS. There's no concept of cookies, so stateful sessions aren't a thing.
Why do articles insist on comparing IPFS to "the web", whatever that means? It's a distributed filesystem. Not at all representative of most content on "the web".
- cjslep 8y agoThe original "web" was built to serve files, with a special kind of markup called Hyper Text that could reference another file with a Hyper Link. Browsers today will still treat servers like a filesystem if it's old enough. It took a decade to get the JavaScript cruft and layers of browser features that basically makes the modern browser a native gaming-like app with a gigantic scripting engine and a fat pipe internet connection. It's possible iterations on IPFS could parallel the current web. But I am not a fortune teller. I just wanted to be sure we all understand where the web came from: serving files as if a gigantic connected filesystem.
- zaarn 8y agoBrowsers don't treat any server like a filesystem. If you see a directory index; that is generated purely on the server.
- CompuHacker 8y agoIn the process of researching and writing a one-line quip about FTP and Gopher, I found that Google Chrome will tell you not to enter credit card details or sensitive information over the insecure connection... to an FTP server. That being said, FTP though.
- jillesvangurp 8y agoThe web is also started out as a distributed filesystem; it's just not replicated (unless you use a cdn). In the begining the web had no cookies, javascript, animated gifs, etc. So, ipfs adds resilience and scaling to the web. Using ipfs for serving up static content instead of a traditional http server can make a lot of sense. Long term browsers might learn to interface with ipfs directly and simply specify hashes of what to fetch in their dynamic content. Eventually that too might be content addressed. If you think about a modern docker based system, basically all you tell your server is an image name and a version tag that points to some content hash of the image it then goes and figures out what to run. Right now mostly you still get that stuff running on dedicated hardware provisioned ahead of time. But with e.g. lambda's that is less of a thing and the code gets provisioned to hardware just in time. Building a docker registry against ipfs probably isn't rocket science and it wouldn't surprise me if that hadn't been done already. Scripts in a browser are just files, so they could come from ipfs. Sessions are often ids or hashes identifying something in a DB. That could be a file in ipfs instead or in a distributed db on top of ipfs. Not saying all of that is a good idea but ipfs can be a bit more than just a file distribution mechanism.
- c1sc0 8y agoNo dynamic pages? Great. No cookies? Excellent! Back to the origins of the web!
- thomastjeffery 8y agoThe dynamic part can be done client side, and state can be stored as new permanent (so long as it is mirrored) data.