Baking right configuration into in-browser nodes

[Gozala]

Sharing nodes across browsing contexts / tabs (see #3022) implies sharing / consensus on configuration. That is also challenge facing native IPFS support in browsers. Also a thing that came up in the past with Textile Desktop / Radicle / IPFS Desktop

• Sharing IPFS deamon (by default) across all the embedders notes#390
• Leverage running IPFS daemon instead of spawning a new one. radicle-dev/radicle-alpha#677
• https://github.com/textileio/desktop/issues/50

Can we choose best configuration for in-browser nodes ?

It appears to me that IPFS node should adapt to the environment it's running in and use best possible configuration given conditions as opposed to making choosing right configuration embedders concern. I understand in practice things are more complicated, so I think we should aim to:

1. Move configuration option into API call option, wherever possible. Maybe even consider how to make that possible when it is not.
2. Consider which entity is in charge of specific option. Some choices concern user and not embedder and likely are not app specific.

I attempted to do preliminary analyses of current configuration options, took notes in hypothesis and compiled following table

option	drop	default	comment
repo	Yes	'ipfs'	Needs to verify with users
repoAutoMigrate	Yes	true	Can we do per MFS ?a
init.empty	Yes	false	Probably can have ipfs.clear() to clear app data
init.bits, init.privateKey, init.pass	🤷‍♂️		Guessing passing keys is common. Can we find a way to drop this ?
start	Yes	true	Chances are shared node is already started.
pass	🤷‍♂️		Seems like this should be between IPFS and user & note between App and user.
silent	Yes	false	Should probably have ipfs.setLogLevel(0) or something that can be changed at runtime.
relay.enabled	Yes	true	What would be a reason to disable this ?
relay.hop	Yes	null	Does not seem revenant in browser.
options.offline	Yes	false	Should be option passed to API calls
options.preload	Yes	false	Should probably be moved
EXPERIMENTAL.ipnsPubsub	Yes	🤷‍♂️	Should probably opt-in during IPNS publish
EXPERIMENTAL.sharding	Yes	false	Should probably move to ipfs.add instead.
config	Yes	null
ipld	🤔		Custom formats are used by Textile. Should have a way to load them.
libp2p	Yes	🤷‍♂️	Browser make best choices given the environment. Some options should probably move to API calls.
Addresses.Swarm	🤷‍♂️	[]
Discovery.MDNS	Yes		Should leverage IPFS Desktop
Discovery.webRTCStar	Yes	false	Can't do in SharedWorker yet.
Bootstrap	Yes	🤷‍♂️	Probably need API for adding but with user consent. Maybe visiting bootstrap node could offer adding itself ?
Pubsub	Yes	{Enabled:true}	Maybe individual call should opt-out ?
Swarm	Yes	🤔	Should probably intelligently adapt to conditions.

[lidel]

We've hit similar problem space when integrating embedded js-ipfs in Brave (ipfs/ipfs-companion#716 – full config is exposed for now) and exposing API on window.ipfs experiment (decided to hide API responsible for reading/updating config for security reasons).

• most of the configuration options are very low level and should not be exposed
• in browser contexts very little is actually customized by the embedder, usually its only:
  • adding own go-ipfs nodes to Bootstrapand options.preload to enable faster discovery and data retrieval
  • Addresses.Swarm to enable *-star signaling service (ws-star(dust), ws-webrtc-star) when discovery between browser peers is needed
  • Addresses.Delegates to enable delegated DHT lookups
    • IIRC this is has limited usefullness: returned peers are often listening on TCP, which can't be dialed directly, but one can leverage preload nodes to prefetch data.
    • (digression) It should be possible to use delegated DHT for fetching IPNS keys, enabling IPNS in the browser context, but it does not work yet: it requires decoupling IPNS in js-ipfs from DHT and make it use generic routing/discovery modules

IMO a power user should be able to customize (add? replace?) custom bootstrap/preload/delegate nodes, but most of the users will not care.

For regular user, perhaps we should discover local ipfs-desktop and prompt/add it automatically?

[SgtPooki]

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

Please feel to reopen with any comments by 2023-06-02. We will do a final pass on reopened issues afterward (see #4336).

This issue is most likely resolved in Helia (see https://github.com/ipfs/helia/blob/c936ba63a75276e206d804cf0ef35c3f9bf67f10/packages/helia/src/utils/libp2p.browser.ts), please try it out!

Assigning to @achingbrain to force a peek from you before we close this for good.

[achingbrain]

Closing since Helia has it's own config and it's a lot less complicated than js-IPFS.