I am not alone in being excited about the possibilities of a distributed, permanent file system for the web. Decentralizing the web will lessen the influence of big content aggregators and promote the free and easy exchange of ideas. There are many entrants in the distributed web field ( Maidsafe and Storj, for example), but IPFS has the advantage of actually having a client I can download and use now.
Recently, after tinkering around with its simple and intuitive client, I decided to try publishing our LACrimBook app to IPFS. LACrimBook is an application put together by my students at the Loyola College of Law Technology and Legal Innovation Clinic and maintained by me. It replaces the big and expensive commercially-available law books with a free alternative that you can put in your pocket. It's a great convenience and money-saver for law students and lawyers.
The architecture of the app is very straightforward and is built using entirely client-side code. UI is handled by the familiar troika of HTML, jQuery, and Bootstrap. The data (i.e, the entire Louisiana Criminal Code) is contained in a ~5MB json file, which is queried using jlinq, a lightweight javascript in-memory datastore. The entire app weighs about 9MB, making it a perfect candidate for this kind of distribution. The good news here is that it took me all of two minutes to get this application up and running on IPFS!
The IPFS process couldn't have been simpler. We already have a web-based version of LACrimBook that is hosted on Github Pages. So, I downloaded the zip file of our gh-pages code and extracted the files. Next, I executed this command:
ipfs add -r LACrimBook-gh-pages/
That's it! The app was available at
http://gateway.ipfs.io/ipfs/QmbeQDMbw8cdvyBZ9BsKTWfe2iXUbSXBc5FY9EqFfFgY2Q/
almost instantly.
As this technology grows and improves, I want to move toward deploying more of our apps in this way. We will focus on putting as much lean code as we can on the client side and publishing it using a distributed file system. For more complex apps, it will no doubt be necessary to maintain some server side infrastructure for the foreseeable feature. But, frankly, a lean server-side RESTful API along with distributed client-side code seems an elegant model to me, in many ways better than what we have now.
-
This is all fine and good for simple apps, but what about dynamic sites? I've read proposed solutions to this problem, but have yet to see a workable project in action. (Genius Hackers: we need a distributed database, please!)
-
The long-term cost of this model is unclear. In the future, IPFS is supposed to be supported by Filecoin, a blockchain currency that has yet to materialize. If Filecoin rockets in value in the same way Bitcoin did, it may end up being cheaper to host your code on a commodity virtual server, albeit without the benefit of permanency that IPFS provides.
-
I'm still a bit a bit puzzled as to how long our app is going to be available on IPFS. The "permanent" aspect of IPFS only happens when someone "pins" your files, which means that someone essentially volunteers to store it on their disk. I'm guessing that not a lot of people on IPFS are jumping up and down to store a digest of Louisiana Criminal Laws! As I understand it, Filecoin is supposed to remedy this problem. In the meantime, I believe that our app is at the mercy of the IPFS garbage collection system, unless some kindly soul with a legal bent volunteers to host it or if I keep my IPFS daemon running in perpetuity. Someone please correct me if I'm wrong!
Nicely captures it.
I'm planning to use Ethereum as an API router that resolves to JSON documents on IPFS. Not sure about the details yet but I think it might be good enough as a db replacement. If Filecoin can deliver payment on a schedule for those who continue to host and I can discover the payment address for an IPFS resource, then I can experiment with incentives and the Filecoin value for a resource can be a health indicator.