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
Inspired by the occasional requests to configure the go-ipfs binary to use some of the options available when using IPFS as a library (e.g. #7617) it would be really convenient if we could create a type of DaemonPlugin that just output a set of IpfsNode constructor options (e.g. as described in #7652).
This would allow us to have a single major point of extensibility to monitor and expand (i.e. the IpfsNode constructor) while also expanding the options available to plugin developers.
We may want some error handling to occur in the event that Alice has two plugins that want to utilize conflicting options. However, IMO it would not be that unreasonable to put the burden of utilizing non-conflicting plugins on Alice. Other plugin systems of this nature allow conflicting/overriding options as long as there is a defined "load order" that allows users to tweak what the final output options look like.
Example:
Alice wants to utilize a plugin that uses several custom Bitswap options as well as a libp2p host with a custom peerstore. She creates two plugins AliceBitswap and AlicePeerstore that both return []IpfsNodeOption. These options are used by the daemon in the construction of the IpfsNode.
The text was updated successfully, but these errors were encountered:
fx recently released some new features that let you modify specific dependencies in the graph (uber-go/fx#653), I have written a PoC plugin interface to allow arbitrary injections into the go-ipfs fx graph and it works fine, I'll clean it up and open a PR.
Inspired by the occasional requests to configure the go-ipfs binary to use some of the options available when using IPFS as a library (e.g. #7617) it would be really convenient if we could create a type of DaemonPlugin that just output a set of IpfsNode constructor options (e.g. as described in #7652).
This would allow us to have a single major point of extensibility to monitor and expand (i.e. the IpfsNode constructor) while also expanding the options available to plugin developers.
We may want some error handling to occur in the event that Alice has two plugins that want to utilize conflicting options. However, IMO it would not be that unreasonable to put the burden of utilizing non-conflicting plugins on Alice. Other plugin systems of this nature allow conflicting/overriding options as long as there is a defined "load order" that allows users to tweak what the final output options look like.
Example:
Alice wants to utilize a plugin that uses several custom Bitswap options as well as a libp2p host with a custom peerstore. She creates two plugins
AliceBitswap
andAlicePeerstore
that both return[]IpfsNodeOption
. These options are used by the daemon in the construction of the IpfsNode.The text was updated successfully, but these errors were encountered: