One thing I've failed to find out about IPFS: who pays for hosting? The user? Or is it donated by some peers?
1. You add the files to your own node. This is how content gets added, but obviously it only lasts as long as your node is connected to the Internet, just like an ordinary HTTP server.
2. Someone views your content using their node. This causes their node to cache the content temporarily (IIRC for 30 minutes by default) and publish it to other nodes. In theory, if your content got at least one view every half hour it could live on in the users' caches forever.
3. Someone tells their node to pin your content. The node will then keep it permanently (until they unpin it) and serve it whenever it's connected to the Internet. Generally they would do this if they believe it's valuable--either because they want to keep it themselves, or as a public service to make it available to others (for example, pinning the Turkish Wikipedia to help evade censorship).
There are also several pinning services, which you can pay to have them pin your content on their node, in much the same way as you'd pay a hosting provider to serve your content.
The 30 minute interval would apply to the IPFS gateway that someone else would use to download your content (generally a standalone process though I believe there are efforts to make a browser with an embedded gateway). IPFS nodes automatically publish their cache, effectively making an autoscaling distributed CDN. However they will only cache content that they have gotten on behalf of their user; they won't go out and pull random content from the network to host it.
We lose the latter incentive with IPFS, and so Filecoin is replaced as the new incentive to give up storage space for the P2P network.
You can still put your content up on IPFS for free, it's just that only your IPFS node will be hosting the content, and thereby won't be truly decentralized. You're the only "seeder", so to speak.
Is hosting content the way that it is mined? Or is mining it something else?
Once implemented, you should be able to buy Filecoin from market exchanges. To earn it, Filecoin will use two "proofs-of-storage". One is "proof-of-replication" wherein your IPFS node proves to be replicating data, and "proof-of-spacetime" wherein your IPFS node proves to have stored said data for a certain amount of time.
You can read more about from their whitepaper: https://filecoin.io/filecoin.pdf
That's just the Go implementation though, there's an implementation entirely in JavaScript, and it would be more than plausible to bake the service into a browser bundle so it works like you describe. However, I believe there's strength in separation personally. The acts of hosting an IPFS gateway, and accessing IPFS content through a gateway, are separate.
Can these ten people not just share a single Eternum account?
The other content could be academic and an alternative to information akin to the old Usenet (pre binaries) and things like Gopher and BBS.
The major demand for a system like this, I'd wager, is pirated content. That is, if its better than the current models. The two big models currently being used for piracy are:
1) Usenet/NZB
* Centralized. Only a handful large networks with long retention. Rest are resellers.
* Usenet servers adhere to DMCA; indexers generally don't
* Pseudonymous, potentially anonymous
* Doesn't require upload; provided quick download speeds
* Based on open source and open standards
* Pretty much requires payment for payserver & indexer
* Little bit rougher on resources due to PAR2 and quick downloading/unpacking of large files has I/O impact. Nothing huge on recent desktop systems.
* Requires a bit more software for everything to work though nowadays there are all in one packages doing the dirty work for you.
2) BitTorrent
* Decentralized.
* Not anonymous. Requires at least VPN, who likely log, even though they claim they don't.
* Free as in beer
* Requires upload
* Based on open source and open standards
* Self-hosted. Some indexers adhere to DMCA; generally they don't
* Private indexers ("trackers") have a reputation system requiring more than 1:1 download/upload.
* Doesn't work at all with DSLite (native IPv6 + IPv4 behind NAT).
* BitTorrent, like Usenet, also has abstraction software (full stack) to make life easier.
BitTorrent is far better known among the general public but I regard BitTorrent as a poor man's Usenet. If it ain't on Highwinds, it ain't anywhere (of course not completely true given DMCA but still, they got 3,3k days retention).
With Usenet you pay for a sub to a payserver & indexer, with BitTorrent you pay by uploading and VPN.
Now, my question is, where does IPFS belong in this list? Can it compete with these 2 technologies?
Personally I believe IPFS to be far superior. BitTorrent has already shown that P2P works great. We don't need tokens for this.
For example, imagine someone has a blog, for which they've paid the network some number of tokens to host. I find one of their articles to be particularly useful, so I pin it on my own node (perhaps with a bandwidth limit if I don't want to get flooded should it become popular) and thus donate a small amount of hosting to the owner of the blog.
From what I've read I could just run the ipfs-daemon on my VPS/hosting server, but is there a user friendly way where I don't have to manually add every file everytime? How easy is it to host a web page with it?
How will does IPFS handle NAT? Could I host my own pinning server on a Raspberry Pi on my home network?
The IPFS daemon handles NAT in much the same way that BitTorrent does: NATed peers will dial out to un-NATed ones to establish a connection. I'm not sure if it also handles UPnP and the like to automatically forward ports if possible.
Either way, that was the most glaring shortcoming I saw in my brief foray into IPFS. There's lots of talk about pinning services and paying, not much talk about hosting your own pinning service, which was shocking to me since the idea of IPFS is to be decentralized, especially when most of the traditional bandwidth concerns of hosting your own content are mitigated by the P2P aspects.
It also means you don't need to trust the server to send you the correct content, since everything is automatically checked against its content hash.
It also means it's automatically a CDN - you don't need to be able to serve every single person who wants to look at your content, because they'll all be serving it to each other.
I have a few thousand web pages on my site, blog posts, etc. Most of it won't be seen in any given day. So I have to pin it as it's realistically unlikely anyone else will. Not much different from today. This probably describes 90% of web content out there, where a single node is all that is keeping that content alive.
Now imagine something slightly more popular than my website. Maybe a particular Medium article. If it's two years old, it's unlikely to be getting any hits at this point, though it might have been popular at one time. So again, Medium has to pin it (or maybe the author would). Popular stuff would stay floating around while it's being viewed.
It's almost a dynamic CDN/torrent which could help with bandwidth, but I don't see any advantage for persistence in most cases.
Similarly, this makes take-downs harder. It's no longer one node/machine hosting a file, but as many nodes as who find it valuable.
If users never pinned anything, you'd be correct, it would be basically the same as the current internet, with one organization maintaining everything. But IPFS gives you the ability to change that.
Overall, it's a subset of the availability of a single server, plus the page always stays at the same "place" and never moves.
This is an important point. If you pin all the content you link to, the links on your site will never break so long as your node stays up.
What about all the .EXEs (games, etc) and SDKs I download? I'll bet over the past 10 years I've downloaded and viewed a few hundred GBs (or more) of content.
If I ever want to see anything again, I have to pin (cache it locally). I could do _that_ (cache locally) with today's web.
I like the idea. But just don't see it working well at scale.
you need one data node up. You can have as many as you want.
if nobody wants to keep the old exes, they'll be lost forever. ipfs was never meant to keep everything forever. Its meant to guarantee you that the file you're viewing (if it still exists) is the same one that was published under this hash. With no regard as to the source of the file. It could be shared with you by your neighbor or the original uploader. And, if you see value in the content, you can also share it with others by pinning it.
its essentially bittorrent as a filesystem. as long as nodes exists, the files will be available.
With this kind of system the idea is that the cost difference between unpopular content and popular content isn't so pronounced. You might have to pay a little more up front, but there are fewer surprises in your bill.
This is the confusing part to me. How does updating content work? Lets say I want to visit the jstanley blog. Does this mean you can only ever publish once, because adding an entry would change the content hash? Does everyone have to contact you for the new info hash? Does ipfs work with existing DNS?
At the moment, go-ipfs (the reference implementation) only supports pinning content hashes, so if you have someone else pinning your content (like a pinning service) you have to notify them of the change. There are plans to add support for mutable pins in the future.
Put in the vocabulary of git: any given commit is referenced by hash[1] and is therefore immutable; IPNS addresses are like references (branches, etc) which can be updated at any time to point to a different commit.
[1]: Since the content is a merkle tree, if they've only changed a few files most of the pinned content will retain the same hash.
IPFS is not just going to act as an ad-hoc CDN, it's also going to work as a regional CDN.
If someone does a report on your funny video on WGN-TV and ten thousand Chicagoans hit your tiny little website in the next ten minutes, your server will get a few hits because nobody else has it yet. After that the network effect kicks in, and eventually everyone is loading it from an IPFS server somewhere in Chicago. When they start 'retweeting' it and everyone is looking for it, it'll end up scattered all over the country.
Until people lose interest, and then the copies will begin to disappear as the next fad automatically pushes it out.
Try reading their documentation. https://ipfs.io/docs/