This project is creating a focused, modular, opinionated, JavaScript-native implementation of IPFS (the Interplanetary File System).
Our goal is a high-quality implementation of the IPFS protocol in TypeScript/JavaScript. It shall run in web browsers, in service workers, in browser extensions, in Node.js, and virtually everywhere else JS runs.
Created: 2022-10-26
Updated: 2023-03-07
Status: Draft
Notes: Maintainers have aligned on this roadmap. Please add any feedback or questions in:
https://github.com/ipfs/helia/issues/5
Improve "hospitality" of the project: #35
After Helia is functional and users can adopt it, Protocol Labs EngRes ceases maintaining the legacy js-ipfs project. Issue for tracking js-ipfs deprecation with roadsigns to Helia: ipfs/js-ipfs#4336
Port over examples from js-ipfs-examples to helia-examples to help with onramping: #29
Demonstrate a practical example of Helia in a service worker as a fallback for HTTP gateways: ipfs/in-web-browsers#207
Setup mechanism for measuring adoption: #41
While it will be possible from a connectivity perspective to make DHT queries from a browser, we expect various applications will want to still delegate out routing. HTTP Routing v1 is a protocol for delegated routing that other IPFS implementations like Kubo have implemented. While it currently uses HTTP as a transport, it is speced and not tied to the Kubo RPC API.
Given new browser-friendly p2p transports, we’ll shut down the complicated “song-and-dance” with the legacy delegate/preload nodes. This yields a simpler setup for one’s application and removes centralized infrastructure.
For delegated routing, one can configure HTTP Routing v1 endpoints. When it comes to providing content from a browser node, it will be up to developers to account for user behavior like closing tabs or laptop lids. The general recommendation is to either run your own preload node or upload content explicitly to a pinning service for providing.
Problem to solve: Currently, very few know the direction for IPFS-in-JS and how they can best help. This affects project resourcing, recruiting, and IPFS adoption in general.
Done state:
- Present and share the IPFS Camp 2022 presentation. (Done: State of IPFS in JS, slides)
- Write and publish a blog post. (Done: State of IPFS in JS)
- Hold a community vote and communication about a name for the new IPFS-in-JS implementation. (Done: Name)
Problem to solve: Currently, the IPFS-in-JS effort has less than one full-time SWE (Software Engineer) who is also splitting time with js-libp2p.
Done state: Accepted offer for 1-2 additional full-time engineers.
Why: Extra hands are needed for designing, planning, and executing on IPFS-in-JS. Even if we outsource development, help is needed to review and guide the development work.
Tracking issue: #6
- Project scope, milestones, success criteria, and communication channels are established.
- Community can follow along and contribute.
- Users can add and get files.
- Packaging, publishing, testing, CI/CD, etc. are all set up.
Tracking issue: #2