Let’s take a look at the possibility to deploy websites on IPFS, discuss obstacles and highlight an approaches to running a sustainable and easily scalable website or marketplace in the IPFS network.In the next articles, we will show you how to run a meaningful marketplace or e-commerce platform over the IPFS network. As mentioned earlier, the IPFS is a file system for distributed, decentralized and censorship-resilient data storage. The data can be basically anything – images, videos, text files, etc. Since a regular website is nothing more than a bunch of textual data (HTML/CSS/JavaScript) and due to the fact that it is easy to display the content stored in the IPFS network through web browser (over IPFS gateways, Brave browser), it is obvious , that IPFS is a propper tool for storing, sharing and retriving such content.

So where is the problem? Why don’t we see thousands of successful websites hosted content in the IPFS ? Why don’t we see decentralized e-commerce platforms offering all kinds of an illegal services including warez, drugs and weapons? Why although the IPFS is an awesome tool to make world more decentrallized and full of freedom, it lacks the practical implementation ?

Main reasons for this are as follows and will be discuss below:

• IPFS content immutability
• Too many resources per single page
• IPFS “does not know” the backend part
• Our society does not want to be decentralized yet

IPFS content immutability

IPFS content is immutable. Any change in content provides different CID. It means that any changes on your web provides different CID = “different URI” to access to your web. From this point of view the IPFS is suitable only for static content. If you make any changes in your content, you have to ensure that your customers gets new CID every time. To solve this, the solution can be the use of IPNS instead of IPFS, or store current CID on ethereum blockchain (ENS). These approaches were discussed many times earlier and we will not it discuss here.

Too many resources per single page

This issue may not be so obvious, but results in that there is much more difficult to effectively run websites in the IPFS than one could think. We think that it is the reason, why websites and IPFS e-commerce platforms are not spread yet. Let me explain it:

A common website is composed from many resources which are necessary for the proper functioning of the website. These are various cascading styles, external css libraries, javascript, images of various formats and sizes, video content, or other files. Dozens of external files are routinely loaded into a web page (for example, the article on the page you are currently reading loads 61 external resources).There are two issues here: The first one is that IPFS gateways are not made to handle such a large number of requests to resources that are being loaded per one page in the same time. Most gateways reject such requests (the website will not render correctly because some files missing) or request end up with 5xx error. The second issue is that each resource is being loaded at different speed and the user will have to wait for the whole page to lo be loaded.The solution is to separate form and content. Think about what data needs to be stored in the IPFS? The data which we want to make censorship resistant. Nothing more. It is data that we want to have decentralized and stored in a distributed manner. This data takes only a small part of the entire website in terms of data volume. But the most of the website’s content is a bunch of HTML, CSS and JavaScript, which does not need to be stored in the IPFS and can be loaded from the source out of IPFS. So the solution is to separate the form (= the code that will render the content) and the content itself. The code that will render/display the content can be stored outside of IPFS (e.g. in form of HTML template) and the content itself can be stored in the IPFS (e.g. in form of JSON file or XML). “Form and content” will splice in the user’s browser. A simple and effective solution. And the best thing is that “the template” is nothing more than an advanced IPFS gateway that displays and render the content (by its CID) in a structured way. One might argue that this solution brings partial centralization (IPFS gateway). That’s true. But on the other hand the content itself is still decentralized. And there can be dozens of gateways around the world that are able to render the content by this way.

IPFS “does not know” the backend part

Everything in IPFS is frontend. Natively, IPFS does not know the backend part. There are two ways to solve it. If we consider the backend part only the database of our application, then JSON or XML files stored in the IPFS network can be used for this purpose. It is the same solution that was discussed in the paragraph above. In the case when we need a full-fledged backend part of the application, it can be solved by separating the frontend part of the application (which runs in IPFS) and the backend part of the application, which run outside the IPFS. The front-end part of the application can send/retrieve data e.g. by AJAX. However, in this case it is clear that the backend part of the application is not decentralized and can be easily censored or shut down.

Our society does not want to be decentralized yet

IPFS is an excellent tool for the society who wants to be decentralized. But does our society wants to be decentralized? I am not sure. Ask people around you what censorship-resistant tech they know. Probably the most people tell you the Tor network and the Bitcoin and adds that both should be prohibited, because it supports an illegal activities. And those same people then screams loudly when the restriction of freedom touches their needs. Many people do not yet realize that our society has reached a tipping point where it is incredibly easy for a very small group of people (e.g. government) to censor, rule and control people around the world, set what is right and what is wrong. We believe that IPFS is a tool that can bring pepole freedom and will teach them to be responsible for themselves.