docs: add manifesto

[achingbrain]

Some high-level thoughts behind the design rationale.

[tinytb]

How do applications omit features? Is it manual, automated / tree shaking, or some combination?

[tinytb]

Required:

• libp2p
• Somewhere to get/put blocks (blockstore)

bitswap would check blockstore first and look elsewhere if a file isn't there.

Optional feature example: IPNS (needs libp2p and pubsub)

• Configure IPNS service to extend Helia export? This would bring us back to where we are now
• Change the IPNS service to take the components you use to build a Helia node? (preferred, we think)

Could pass things to Helia that you want to use. If you don't want a feature, just don't add the module.

[tinytb]

What will the Helia APIs and other interfaces look like? What will it take to migrate from js-ipfs?

Can migrations be done in minutes, or will they take hours?

We should also mention the fact that Helia is expected to fully replace js-ipfs eventually, and js-ipfs will be deprecated.

[tinytb]

• depends on what parts of the API you're using. If it's just add and cat, then it's not a big change.

open question: How will users set their configuration?

note: These are ideas but they might change based on what we learn as Helia is developed.

Currently, there are many ways to set configuration. We want there to be 1 way to do it.

One big change for migrators is that they'll need to use some underlying libraries directly. Example:

• if you want to ping, you'll use libp2p directly. It won't be a method on the root of Helia.
• pubsub methods (currently just chain through to libp2p) won't be in Helia.

(js-ipfs root API)

• Will need to create migration documentation: from X method before, to Y thing now.

There will be a way to do what you did with js-ipfs, but it may be a little different.

[tinytb]

What will be the best way for users to do this? (exclude code)

[tinytb]

Have features implemented as separate modules or services; if you don't use the feature, you don't use its module.

Example: libp2p has a DHT implementation (kad-dht module). If you include it in your bundle, you get the DHT implementation; if you don't include it, you don't get the code for it either

[tinytb]

Can we briefly explain what these layers are? Anything beyond js-libp2p and js-bitswap?

[tinytb]

includes: ipld, unixfs

We are designing a filesystem API. People complain the current API is too big (many methods; does a lot of things; object API, configuration API, bootstrap API)

Helia is focused on delivering an ergonomic filesystem API - not changing the other components.

Non-goal: Rearchitecting everything.

• FILES.md is the really useful thing; files API
• The other things won't be part of the Helia API

[tinytb]

• don't need an API for config; you should just config your thing
• the other APIs are useful but don't need to be everywhere all the time.
• e.g. IPNS can be its own thing; you would use the IPNS module and pass it libp2p and blockstore. That way, it's not part of the Helia API because it doesn't necessarily have anything to do with the filesystem; it's just mutable pointers to CIDs.
• e.g. IPLD is its own thing; use the codecs directly, but pass it the blockstore so you have a place to put the blocks.

We'll create some documentation to show how to do network IPLD operations.