Below are the list of initiatives we intend to work on in 2024! This work is beyond our continued solid maintainership of various IPFS implementations, tools, services, and specs where we handle bug fixes, security patches, dependency updating, community contribution landing, and releases. Clearer milestones and dates along with public Github issues will be articulated in early 2024 after we complete the initial graduation logistics from Protocol Labs Inc. In the interim, please feel free to

Browsers can reliably fetch CIDs (both as assets of a page as well as whole appss) in a verifiable and trustless manner without being vulnerable to centralized chokepoints. For example, the CID of a dapp frontend or wikipedia article that is provided on public content routing networks like the Amino DHT can then be fetched and verified with a browser.

A minimal set of specifications we need to have to enable radical interop thanks to HTTP. This is the golden path informed by and benefitting projects like IPFS Chromium, or any light integration of content-addressed data that does not want to deal with details of P2P (including mobile).

Popular IPFS implementations like Kubo and Helia support the wide array of data that is already content addressed by developing sufficient specs and tooling to be able to support incrementally verifiable large blocks. The utility of IPFS moves closer new userbases, with content-addressable data from Docker containers to Blockchains state-trees now being viable for distribution with IPFS protocols without requiring any additional or duplicative processing.

There is a very minimal HTTP-based set of protocols and requirements for building IPFS implementations that can be interoperable across most common ecosystem implementations.

As a north star, the amount of effort to build compatible IPFS tooling in something like Python, .NET, etc. (that doesn’t have much IPFS or libp2p tooling today) should be extremely minimal.

A user can hit a Boxo-based HTTP gateway (e.g., ipfs.io gateway, localhost Kubo gateway) and if there was an error, get a link to download an “IPFS request trace”. They can then use tooling locally or centrally hosted that can analyze the “IPFS request trace” to pinpoint the issue.

When using a hosted solution like check.ipfs.network, they can get a link to the analyzed result that can be shared with others to help with troubleshooting or educating.

Meet the ecosystem-raised need for a denylist standard and turn-key support to enable services to deal with DMCA, abuse like phishing, and other takedown requests.

For areas where we have heard multiple complaints of “X should be better for my usecase” and where we want to encourage developers to solve it their own way but they seem stuck waiting on us to fix the problem, we demonstrate some examples to pave the way forward.