fix(libp2p): Export Components type for use in apps that use libp2p

[MichaelJCole]

Title

fix(libp2p): Export Components type for use in apps that use libp2p

Description

See #2452

Notes & open questions

See #2452

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if necessary (this includes comments as well)
• I have added tests that prove my fix is effective or that my feature works

[achingbrain]

Thanks for opening this.

I'm hesitant to export this interface because it encourages the sort of code where everything depends on everything else. This is why the components field is not part of the libp2p interface and is only used internally within the libp2p module.

Could you speak a bit more to your use-case please?

[MichaelJCole]

Hi, I wrote a bit about this in #2449 (comment).

I wrote a bit about the use case in #2454

More or less, my use case is an electron app with a configuration similar to Vuze, utorrent, and other peer-to-peer desktop applications. Those applications set expectations for how configurable they should be. Also, I need to help users around NATs and firewalls and etc. Having access to the addressManager is part of it.

I mentioned in the PR, how Typescript only enforces these limitations at compile time. And they can be trivially overridden:

    // @ts-ignore missing components in libp2p types
    const am = libp2p.components.addressManager as DefaultAddressManager

So not including these types is really just making it harder to use. Javascript runtimes don't enforce private members unless you're compiling to ES2021+ and use # at the start of the names. The _name convention is well understood. IMHO, separating the interfaces from classes and putting them into their own package really just makes things harder for everyone.

Here are some screenshots of the UI's

https://vpn.ac/images/tutorials/socks5/qbittorrent1.png
https://www.bolehvpn.net/images/utorrent1.jpg
https://imgur.com/MQ4zkcA - 10 years old

[achingbrain]

I'm closing this issue because I think the underlying problem you mention in #2454 is that your observed addresses are not being confirmed by peers.

Exposing libp2p internals like this will not solve your problem.

If you really, really want to do this, you can @ts-ignore the types, or create a custom service that exposes the methods you want to call, but it seems that your particular network setup is giving AutoNAT problems, or your node hasn't been running for long enough to receive enough confirmations from a diverse enough set of peers, or perhaps both.