Build On IPFS - Not HTTPS

Location addressing versus content addressing might be one of the biggest debates right now between the Web2 and Web3 ecosystems.

Location Addressing Through HTTP/HTTPS

Web2, or the centralized internet, uses location addressing through the HTTP/HTTPS protocol to provide functionality for webpages to be routed to within a web browser. When a webpage is stored on a web server, it uses the HTTP/HTTPS protocol to serve that file as a public website that can be accessed around the globe.

When you navigate to a website, such as

https://filebase.com/blog/heres-why-you-should-build-on-ipfs/

you are navigating to a location where the article ‘Here’s Why You Should Build On IPFS’ is located. This is because location addressing uses the location of the file within its hosting server.

For example, the blog post ‘Here’s Why You Should Build On IPFS’, is located on a web server that hosts the Filebase blog. If the blog post’s name portion of the URL, called a ‘slug’, changes or is moved, the link will no longer work and you will get an error page, like a 404 Not Found message. So if the title changes to ‘Here’s Why You Should Build On IPFS Today’, the link

https://filebase.com/blog/heres-why-you-should-build-on-ipfs/

will no longer work.

Link Rot

This disadvantage is referred to as ‘link rot’. It is one of the main disadvantages of using HTTP/HTTPS. Small changes to webpages or URL structures can cause entire webpages to be renamed and accessed at a new URL, causing updates to be required in any configurations that use those static URLs so that they reflect the new location of the content.

Several studies have been done to calculate how many URLs on the Internet are considered ‘dead’, or no longer accessible and return an error such as a 404 Not Found message.

One study from 2014 of legal journals and other citations, found that about 70% of URLs originally cited in legal journals no longer existed, and around half of all URLs used by the United States Supreme Court for citing decisions no longer existed either.

Another study from 2012 estimated that of all social media links, about 30% would no longer exist in the next two years.

In a massive study completed by Ahrefs.com that compiled data over a nine-year period, they found that out of 174.3 million links, around 26.9 million were considered ‘dead’ or ‘lost’. Of these, the most common errors associated with links being inaccessible were caused by the links being dropped (47.7%), meaning in most cases the domain no longer exists entirely, or they were removed (34.2%), which means that the pages still exist, but the slug has changed so the original URL no longer works.

Content Addressing Through IPFS

InterPlanetary File System, or IPFS, uses content addressing to reference stored content instead of location addressing. Content addressing means that all content stored using content addressing is referenced through the content’s identifier, or CID.

When a file is uploaded to IPFS, the file’s contents are used to generate a cryptographic hash value. This value is used to generate a second value, known as the file’s content identifier.

Two things are always true about IPFS CIDs:

• The same file or folder added to two separate IPFS nodes using the same settings and parameters will produce the same CID. Any difference in the content, such as metadata differences, will produce a different CID.
• The length of the CID will be the same for every file or folder, regardless of the file size or content.

CIDs can be used to reference that file using IPFS native links or IPFS HTTP gateways.

IPFS native links are in the form of:

ipfs://[CID]

IPFS HTTP gateways bridge the gap between the IPFS network and programs that don’t natively support IPFS. By using an IPFS HTTP gateway, CIDs can be accessed by anyone in the world through a web browser. IPFS HTTP gateways are in the form of:

https://ipfs.filebase.io/ipfs/[CID]

Content Addressing Isn’t Susceptible to Link Rot

Content addressing doesn’t rely on URLs to remain the same or for domains to stay active. IPFS CIDs can be accessed through any IPFS HTTP gateway, with over a hundred public gateways to choose from currently.  As long as a CID is available on the IPFS network, the content can be accessed.

IPFS Pinning

To assure that CIDs are always available on the network, they must be pinned to an IPFS node. IPFS pinning is the process of storing a file or folder on an IPFS node’s permanent storage, rather than the node’s cache storage. If a file isn’t pinned, it’s stored in cache storage that will be cleared periodically by the network’s garbage collection process.

Filebase is a geo-redundant IPFS pinning service, meaning each file uploaded to IPFS through Filebase is pinned with 3x replication across different diverse geographic locations. This 3x replication provides important redundancy and reliability that ensures CIDs are always accessible and available.

You can sign up for a free Filebase account to get started with your IPFS journey today.

If you have any questions, please join our Discord server, or send us an email at hello@filebase.com.