IPFS, The Interplanetary File System, Simply Explained
achainofblocks.com
achainofblocks.com
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".
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.
That being said, FTP though.
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.
(we ask for a small donation to cover food & facilities, but if this is a hardship for you, e-mail me and I can help out)
For some reason this reminded me of the scene from Stranger Than Fiction where she's teasing Harold, "Anarchists have a group? They assemble? Wouldn't that defeat the whole purpose?"
(I don't suppose I know how you would handle a distributed meetup, unless IPFS has some facilities I'm unfamiliar with...)
matrix: https://matrix.org/blog/home/
Not affiliated, just a fan plugging.
Heh, emphasis on "some," since he's only talking for 15min. ;)
Based on the review at https://muratbuffalo.blogspot.com/2018/02/paper-review-ipfs-...
I get all the additional functionality IPFS comes with, but it just feels too complex to get adopted. I can go out right now and start interacting with BitTorrent networks, but I don't even know where to get started with an IPFS system
IPFS has a unique, global DHT as a matter of principle, and so, only requires the hash of the file to start downloading. Everyone gets the same bootstrap nodes, and then is part of the same DHT, with a common lookup mechanism relying on Kademlia.
On the other hand, I feel like IPFS is not as advanced as dat in relevant ways. IPFS is not good for file edition, while dat has systems that simplify modification of even large files and merging of structured files.
There is nothing stopping Bittorrent clients from agreeing on "this dht will be global", and similary, what stops IPFS clients/peers from forming a different DHT? Nothing as far as I know, not like scuttlebutt which has a transport-layer network-wide key.
What about trackers, bittorrent can but does not work well without trackers, so its not really according to me, decentralized, since some peer is more equal than another peer.
IPFS is meh, datproject is where its at.
Instead of just reusing bittorrents piece-per-peer-exchange-protocol (that greedy not perfect algorithm, forgot its name) - which can saturate even high end links, they invented bitswap, full with bugs, then decided lets make filecoin instead, like a bartering engine of exchanging pieces.
datproject also can saturate my 250mbit connection.
(Theoretically you can do this with IPFS too, but I love how dat is implemented!)
I've also been excited that Dat seems to be investing a Rust implementation that would presumably make Dat accessible from any language that can interoperate with C/Rust.
Where this happens to be particularly annoying with BitTorrent are aggregate Torrents: You have a bunch of separate files available for download (think TV series or books) each forming its own DHT node. Then somebody decides to create an aggregate torrent (such as libgen's “1000 books” torrents) and offers that for convenience or efficiency reasons. Will the clients that previously downloaded the individual files share them with this new torrent? No! Because the new Torrent “is different” even if each of it's files are byte-by-byte identical.
Could BitTorrent be upgraded to allow for this? Probably, but it'd be radical paradigm-shift requiring a redesign of everything (“BitTorrent 2.0”). So why not start from scratch with a new protocol entirely?
A protocol that does what torrent does but better would be dat://, IPFS is terrible at being BitTorrent but better.
It's quick and easy. I recommend the browser extensions.
Otherwise, its first and foremost for geeks, then other geeks implement apps for the normals using the technology.
Still very geeky, but we're trying to make sure it's very simple to use for data scientists/analysts/researchers alike.
here's more on us: https://qri.io & https://github.com/qri-io
This is similar to how Tron will work.
What makes IFPS more global is that they have defined a set of standards for linking objects together to form potentially complex structures. The holy grail is to scale this up to create a whole new World Wide Web based on linked IFPS objects rather than linking to resources on specific hosts.
Which if true would make it more of a global swarm
Oddly, it would also imply you could potentially generate entirely new files out of the network; in an infinitely large network, you wouldnt even have to specifically upload a new file — the hashtree would be enough, and the network would find the pieces to compose it
Never got anyone to confirm/deny my understanding of it, and its not clear to me why it wouldnt be the case, if it weren’t.
More specifically, its not clear to me what benefit exists to associating a block with its originating file; my understanding of bittorrent requires you to receive/send out the total list of blocks anyways (the .torrent file), as you're requesting the missing blocks (and at start, thats all blocks), and others are responding with blocks the have to offer (which may not be all blocks, since you can request from partially-finished peers aka leechers).
In IPFS, you don't have an associated server (a tracker) to tell you who your peers are for a given file, so first you'll ask around for the list of blocks required for that file, and then you'll ask anyone who responded for your missing blocks, same as bittorrent. But you'll have to keep asking for new peers, since you aren't being updated by the server, and sending out the list of missing blocks all the same.
It seems to me that there's not much benefit to requesting specifically the file, and then the blocks, rather than just requesting the blocks directly, when doing that updated request.
And if you're asking for the blocks directly... then that kind of de-duplication would be a natural outcome.
Also a spot where it might actually be impactful today -- Memes.
And if its truly an interplanetary mindset, there might come a point long into the future where such a feature would be an actual feature, rather than an accident. But regardless, I only mean it as an implication of how I believe IPFS is implemented, not an intended benefit/feature of it. I specifically mean it as an easy way to point out where my understanding failed, if I'm wrong; or an easy way to verify my understanding is correct ;)
It's vanishingly unlikely that this would yield useful results in practice.
In a moderately-sized network, however, if only a few contiguous bytes in a GB file change, then only a single block would need to be uploaded. (if the original file is sufficiently available already)
Is it possible to put a site on it that does any kind of computation that is not frontend JS or that stores state in some fashion?
here's more on us: https://qri.io & https://github.com/qri-io
https://github.com/ipfs/go-ipfs/issues/3429
I was running IPFS on a VPS last year serving no content, and was consuming about half a gig a day in bandwidth.
Is this a fundamental issue with the underlying concept?