Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 1 commit into from

Conversation

MichaelJCole
Copy link
Contributor

@MichaelJCole MichaelJCole commented Mar 27, 2024

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

@MichaelJCole MichaelJCole requested a review from a team as a code owner March 27, 2024 16:52
@achingbrain
Copy link
Member

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 MichaelJCole changed the title bug(libp2p): Export Components type for use in apps that use libp2p fix(libp2p): Export Components type for use in apps that use libp2p Mar 27, 2024
@MichaelJCole
Copy link
Contributor Author

MichaelJCole commented Mar 28, 2024

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants