towards peer-* compatibility

[pgte]

(I'm opening this up for discussion, so that, if you're interested and it's feasible, the DDC working group can plan our contributions to this.)

For these reasons, it would be great that peer-star could use Companion for all things IPFS and libp2p.

From recent conversations and a quick analysis, I think Companion would have to be able to provide peer-star with:

• Ability to use a custom transport and discovery (defined in a JS module)
• Ability to implement a custom libp2p protocol (defined in a JS module)
• Ability to use pub-sub (including event-driven interface for notification of remote subscription changes)

[lidel]

Sounds feasible as long embedded js-ipfs is used.
Pubsub use with go-ipfs is blocked by ipfs-inactive/js-ipfs-http-client#518 and I am unsure how custom transports/protocols could be added when HTTP API is used (probably needs changes to go-ipfs itself?).

If you switch to experimental Embedded js-ipfs backend, then you will be able to specify JSON with custom configuration for that node (enable pubsub, set custom signaling servers and transport modules).

@pgte based on what I know at the moment, next steps are:

• Identify and document what are the extras you need.
  • Make a list of all customization peer-* need on top of default js-ipfs config and post in this issue.
• Add custom JS modules to Companion so they are available for embedded js-ipfs when custom config refers to them.
  • Ideally peer-* team would do the PR, but I can help the details or make time if more of involvement is needed.
  • The path forward would be for peer-* team to create a PR each time an update is needed.
• (needs evaluation) if safe, perhaps change default config that ships with companion to enable these changes out of the box.