Skip to content

Latest commit

 

History

History
110 lines (70 loc) · 5.02 KB

ROADMAP.md

File metadata and controls

110 lines (70 loc) · 5.02 KB

Roadmap

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

Table of Contents

🛣️ Milestones

2023

Q2

Drive Adoption

Improve "hospitality" of the project: ipfs#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: ipfs#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: ipfs#41

Q3

Support Fully Speced Delegated Routing Protocols and Endpoints

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.

PL Delegate and Preload Nodes Will Be Shutting Down

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.

ipfs/ipfs#499

Past Milestones

2022

Mid Q4 (November)

Communicate the State of IPFS in JS

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)

Late Q4 (December)

Double Team Capacity

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: ipfs#6

2023

Early Q1 (January)

Finalize Execution Plan

  • Project scope, milestones, success criteria, and communication channels are established.
  • Community can follow along and contribute.

Late Q1 (March)

"v1" Released

  • Users can add and get files.
  • Packaging, publishing, testing, CI/CD, etc. are all set up.

Tracking issue: ipfs#2