We'd be better off by putting wikipedia on IPFS and IPFS into p2p cache.
I published the whole Wikidata dataset as separately accessible entities to IPFS and the initial publishing took ~2 weeks. Theoretically updating the dataset with weekly changes should be pretty fast after that, but if there is a change that impacts the JSON structure of every entity you have to start all over (which recently happened).
Right now Wikipedia/Wikidata is only really useful as a stress test for IPFS, but I'm optimistic for the future.
For anyone interested in this there is some (slow) progress on this at https://github.com/ipfs-wikidata , though it's admittedly a low priority for me right now, as I wait for the technical state of IPFS to improve.
One more major improvement is on the way, which is directory sharding using a HAMT data structure: https://github.com/ipfs/go-ipfs/pull/3042
I'm quite excited for directory sharding since it would make the project simpler, but the local filesystem on my server doesn't even seem to be able to handle all the files in a single directory.
You'll get the benefit of insuring off-line availability as well as only hosting pages you care about. Win-win.
Which kinda defeats the point of saving bandwidth on their side.
>js-ipfs node
That could work, though I was under the impressino that the js-ipfs implementation was WIP/Experimental (last I checked)
Traffic doesn't only need to be served by Wikipedia but could also include other volunteers (think archive.org and others) and the setup for helping out would be easy.
> That could work, though I was under the impressino that the js-ipfs implementation was WIP/Experimental (last I checked)
That is absolutely true, which WikipediaP2P is as well, and IPFS for that matter. I was simply pointing out some ways you can make the whole "Wikipedia on IPFS" thing to work in the future.
Simply pointing it at gateway.ipfs.io would achieve nothing but shift the problem around.