Fission has been working with the IPFS ecosystem since we started. Content addressing is a fundamentally useful innovation that opens new use cases and approaches that are difficult or impossible without.

This year, the community and the organizations involved are changing in significant ways. Protocol Labs is nucleating a number of the engineering, open source, and operational teams into separate startups, engineering collectives, and foundations.

For IPFS projects and tooling, we must re-evaluate how we work together from code to commons.

What is IPFS Mainnet?

Mainnet is a term used to describe the default or "main" network that default settings connect to. This has mostly been "assumed" for the IPFS network, and not really highlighted for anyone other than protocol experts. The technical name for Mainnet is Amino, and there's a blog post from September 2023 that goes into some more details and changes happening.

Diving deeper into Mainnet, there are a variety of public utilities that are described in more detail in the IPFS docs. One of the most notable is the IPFS.io public gateway, that serve up content-addressed data through an HTTP gateway that every browser can access.

This was run by Protocol Labs, and will now be a responsibility of the emerging IPFS Foundation, who in turn are relying on the new IP Shipyard organization to do the technical work to host and maintain the gateway.

There are a number of other public IPFS Mainnet gateways, including the gateway we've been running at Fission for many years:

While Fission's gateway is listed, we only serve up content that is synched to our servers by published apps and WNFS file systems

You'll note from the list that there are a number of commercial providers of IPFS services, like Cloudflare, Pinata, and Web3 Storage. As well as their "public" gateways, many of these organizations also sell services hosting dedicated gateways.

The way that IPFS works, all the nodes / gateways / desktops etc connect together and store pieces of data, "addressed" by the data itself. Unlike with a single web server being down and no one else having the "authority" to have the data at a location like example.com/somedata.pdf, IPFS nodes ask each other for all of the blocks that make up a content address, and the receiver can then verify that the data is correct.

IPFS Mainnet is the giant global network that uses the default bootstrap list, the default Distributed Hash Table (DHT) that helps locate content on the network, and all of the public and dedicated gateways that connect to it.

Alternate Networks

Using a different list of bootstrap nodes and other configuration settings, you can choose to not connect to IPFS Mainnet. Here are two examples of projects that made this choice:

Source Network uses IPFS to synch and serve data across their ecosystem – we had them on for a Fission Tech Talk a while back – but doesn't connect to Mainnet by default.

Quiet is a chat app that uses IPFS to synch and connect devices, but on a network that is private to the connected devices.

Performance, privacy, or other considerations are all reasons that you might not want to use Mainnet, while still relying on the same codebases and technology stack.

Everywhere Computer and IPFS

Fission's primary product is the Everywhere Computer. This is the platform we're building on top of the open protocol InterPlanetary Virtual Machine (IPVM) that we developed alongside a number of collaborators in the UCAN and IPVM working groups.

The Everywhere Computer lets you run compute everywhere. This is accomplished by supporting WebAssembly functions that are published to IPFS, and by fetching and storing data that needs to be computed to and from IPFS. Separately, we use libp2p, the peer-to-peer networking layer that IPFS also runs on, to connect all of the compute providers, and to share receipts of results and other data across the network.

Simplistically, you could say IPVM and the Everywhere Computer add compute to IPFS.

Note that we didn't say "IPFS Mainnet" there. We heavily use content addressing in the design of the system, so that we can do things like cache functions on compute nodes, cache results across the network to skip computation all together, and many of the other optimizations you can do from edge devices to servers when you're using content addressing rather than location addressing.

The design of the Everywhere Computer will introduce the concept of Subnets. These will be default settings, permissions, optimized functions, and other configuration options that let anyone compose groups of computers to support different ecosystems and applications.

However, our default public beta subnet (cool name and logo forthcoming!) will connect to IPFS Mainnet. The public commons that the IPFS Mainnet represents is something that we've always been excited about and supported, and we're excited to add content-addressed compute with the Everywhere Computer.

You can watch a demo and overview of the Everywhere Computer from our late Feb 2024 presentation

Across both public gateways and commercial providers, developers will be able to fetch data, run it through an IPVM compatible function, and then store the results back on IPFS Mainnet.

Sign up for the Everywhere Computer beta if you'd like to be involved.

Gathering the Commons

Along with IP Shipyard, we're hosting an event today in Denver to share the news about IPFS Mainnet support, and start gathering the commons of people and organizations that are interested in supporting and improving this public global network.

Here are some questions to think about IPFS as Commons:

As an ecosystem, app or project that relies on the IPFS technology stack (whether it connects to Mainnet or you run a private network), what do you need and how do you want to provide support in return?

As a commercial provider, let's talk about inter-connecting our nodes and jointly running a more efficient network. If you rely on Kubo, go-libp2p, js-libp2p that are maintained by the IP Shipyard team, or other open source code bases, how do you plan on supporting them? What features and functions would you want to prioritize and fund, or contribute engineering resources to help implement?

As an individual using IPFS from your desktop or through various apps, how do you want such an open network to function, and what should it prioritize?

There are a number of legal challenges, takedown requests, and content moderation topics that come up across public gateways. Should IPFS Mainnet supporters join forces to decide on how to handle some of these concerns across the commons network?

This year, the IPFS and extended ecosystem is graduating to a more commons based approached, with many separate companies, foundations, and funding partners.

At ETH Denver we want to introduce the changes, and invite people to take part in supporting and governing large public commons projects like the ipfs.io public gateway, and the Kubo IPFS node codebase.

We will have a presentation by Adin Schmahmann from IP Shipyard, IPFS Core Maintainer, to introduce IP Shipyard’s New Chapter and other existing and upcoming initiatives.

We will follow with a discussion of IPFS as Commons, welcoming IPFS operators, dapp builders, blockchain ecosystems, and others interested in the future of the IPFS commons. This will be a facilitated discussion and Q&A, hosted by Boris Mann, Founder of Fission.

If you're in Denver, you've still got time to join us for the IPFS Mainnet event today, Wed Feb 28th, 4pm MST, otherwise we'll be sharing presentation slides and other follow up notes on the IPFS Discussion Forum.