Learn more about Filebase’s integration with the IPFS network.

What is IPFS?

InterPlanetary File System, or IPFS, is a distributed and decentralized storage network for storing and accessing files, websites, data, and applications. IPFS uses peer-to-peer network technology to connect a series of nodes located across the world that make up the IPFS network.

How does IPFS work?

IPFS is unique from other decentralized storage networks because it offers additional features and attributes such as content addressing, directed acyclic graphics (DAGs) and distributed hash tables (DHTs).

Unique Data Identification via Content Addressing

Data stored on IPFS is located through it’s content address rather than it’s physical location. When data is stored on IPFS, it is stored in a series of encrypted pieces, with each piece having its own unique content identifier, or hash. This hash serves as an identifier and links the piece to all the other pieces of that data.
Identifying an object, such as an object or a node, by the value of its hash is referred to as content addressing. The hash identifier is known as the Content Identifier, or CID. When objects are uploaded to an IPFS bucket on Filebase, the IPFS CID is listed in the object’s metadata for easy reference in any tool or application, or for use with an IPFS gateway.
Learn more about IPFS CIDs in our deep dive document about CIDs below:

Content Linking via Directed Acyclic Graphs (DAGs)

Directed Acyclic Graphs are a hierarchical data structure. A graph is a way to display objects and the relationship between them. A directed graph is when a graph’s edges have direction, as depicted in the photo above. An acyclic graph is a graph where the edges have definitive ends and do not create a loop to other objects. Think of a family tree that shows ancestors and their relationship to one another. This is a good example of a Directed Acyclic Graph.
In this context, an object in a graph is referred to as a node and an edge refers to the relation between the objects in a graph.
IPFS uses Merkle DAGS, where each node has a unique identifier that is the result of hashing the node’s contents. Merkle DAGs are a form of self-verified data structures.

Content Discovery through Distributed Hash Tables (DHTs)

A distributed hash table (DHT) is a distributed system for mapping keys to their associated values. DHTs are databases of keys and values that are split across all the peers on a distributed network. To locate content, you ask a peer on the network, which will return a DHT that tells you which peers are storing which blocks of content that make up the data object you’re requesting.

Native IPFS URLs

Applications that natively support IPFS content addressing can refer to content stored on IPFS in the format:
ipfs://{CID}/{optional path to resource}
This format doesn’t work for applications or tools that rely on HTTP, such as Curl or Wget. For these tools, you need to use an IPFS gateway.

IPFS Gateways

Content stored on IPFS can be accessed by using an IPFS gateway. Gateways are used to provide workarounds for applications that don’t natively support IPFS. An IPFS gateway can be local, private, or public, and uses the IPFS content ID to provide a URL link to the content for access to the stored content.
Filebase's native IPFS gateway is as follows: https://ipfs.filebase.io/ipfs/{CID}
The Filebase Public IPFS Gateway has an effective rate limit of 200 RPM (requests per minute).
All content stored on IPFS through Filebase can be accessed through the Filebase gateway with faster response times than accessing the content through any other gateway. This is because the Filebase gateway is peered with our IPFS nodes. The Filebase gateway is also peered with the IPFS gateways of other pinning services.

IPFS Subdomain Gateways

The format of a subdomain gateway is as follows:
Using a subdomain gateway as a drop-in replacement for a traditional gateway removes the need for there to be a CID version translation because there is a difference between opening an older CIDv0 resource and a CIDv1 resource. When a CIDv0 is accessed with a traditional gateway, the domain will return an HTTP 301 redirect to a subdomain, converting the CIDv0 CID to CIDv1 CID.
For example, opening a CIDv0 resource using a traditional gateway at:
returns a redirect to a CIDv1 representation at:
By using a subdomain gateway initially, there is no need for the conversion step to take place.
For more information on IPFS CIDs and fetching IPFS links, see our guide here.

What is ‘pinning’ data with IPFS?

When data is stored in a Filebase bucket, Filebase’s native edge caching technology keeps that data cached at the network’s edge locations for quick access to that data again. Then, when the IPFS garbage collection storage limit is reached, which varies between the IPFS Desktop client and Brave, the cached data is cleared to make room for other data. This clearing of unpinned data is referred to as the IPFS garbage collection process.
If you want data to be cached for a long period of time you can pin the data. This will keep the data cached on the IPFS network indefinitely, since pinned data is skipped during the garbage collection process, allowing for faster data retrieval times.
For more detailed information on IPFS pinning, see our deep dive below:
Typically, IPFS pinned files are stored on centralized cloud providers, like AWS. On Filebase, all files that are pinned onto IPFS are actually being stored on the Sia network. This creates an environment where the data storage layer for Filebase IPFS nodes is highly available, and most importantly, geo-redundant.
Pinning data is a unique feature of the IPFS network, and is not offered for buckets created on other networks.

How do I store data on IPFS through Filebase?

Simply navigate to your Dashboard Console, create a new bucket and choose the IPFS option.
If you have any questions, please join our Discord server, or send us an email at [email protected]