Provide a default libp2p instance

[BigLep]

Done Criteria

Helia can be constructed without a libp2p instance. In this case, a "good default" libp2p instance is provided.

Why Important

libp2p exposes a lot of knobs. Knowing the right one sets for a good connectivity story is not cear to new users. This reduces the barrier to entry and also serves as a base set to potentially tweak.

Notes

This default libp2p instance should be well commented so that interested users can learn from it to determining how they might follow suit or tweak.

[SgtPooki]

Should this be something that js-libp2p provides?

I imagine a set of default libp2p configs for different usecases would be really valuable for users:

• DHT libp2p config
• IPNI libp2p config
• browser node libp2p config
• server node libp2p config

[SgtPooki]

related:

• Enable WebRTC by default in the browser? js-ipfs#3541
• Baking right configuration into in-browser nodes js-ipfs#3042

[BigLep]

Should this be something that js-libp2p provides?

I'll let @achingbrain comment.

I imagine a set of default libp2p configs for different usecases would be really valuable for users

I think you bring up a good point. It may be useful to expose a libp2p "instance factory". Then a user can be selective of what variant they want. At the minimum having a "browser" and a "server" config.

[achingbrain]

I think applications like Helia are a better place to make choices about what a default libp2p config looks like rather than libp2p itself since you're closer to the user's needs at that point.

At the minimum having a "browser" and a "server" config.

We solved this problem in go/js-ipfs by having 'profiles' that a user could enable/disable - test, server, low-power, etc. These tweaked configuration options like connection limits and turned on/off different modules.

[SgtPooki]

I like the idea of profiles, but, if we can, it would be nice to allow composable functionality via features instead of profiles with everything hardcoded. i.e. similar to tsconfig lib (but we would need to handle merging and whatnot):

1. browser features (enables webtransport and websockets, because a "server" may or may not want "browser" functionality in different circumstances)
2. DHT features (enables default bootstrapping nodes, which are overridable. possible for both server + browser to want this or not)
3. default features (noise+yamux required for basically everything right now right? i'm not sure how these could be broken apart based on other features here)

[github-actions]

🎉 This issue has been resolved in version @helia/interface-v1.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version helia-v1.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀