You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 12, 2024. It is now read-only.
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
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:
Move configuration option into API call option, wherever possible. Maybe even consider how to make that possible when it is not.
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.
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
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:
I attempted to do preliminary analyses of current configuration options, took notes in hypothesis and compiled following table
repo'ipfs'repoAutoMigratetrueinit.emptyfalseipfs.clear()to clear app datainit.bits,init.privateKey,init.passstarttruepasssilentfalseipfs.setLogLevel(0)or something that can be changed at runtime.relay.enabledtruerelay.hopnulloptions.offlinefalseoptions.preloadfalseEXPERIMENTAL.ipnsPubsubEXPERIMENTAL.shardingfalseipfs.addinstead.confignullipldlibp2pAddresses.Swarm[]Discovery.MDNSDiscovery.webRTCStarfalseBootstrapPubsub{Enabled:true}Swarm