-
Notifications
You must be signed in to change notification settings - Fork 32
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
Test peer discovery with public DHT #96
Closed
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would need to be changed in all clients if they should be compatible. I am not sure if we want to do this though.
Somebody coming to libp2p via this project would get the impression that they can just use the IPFS DHT for their project. I don't think we want that? Not until we change it to be a "generic peer routing" DHT I guess?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mostly agree. The key question I'm trying to answer with this PR, is how well ambient peer discovery and routing work for js peers in this app (in the browser) using the public bootstrappers and how that compares with the approach of a single rust peer, single go peer and multiple browser js peers.
I haven't found a definitive answer to this in any of the libp2p specs or the docs.
Intuitively, it makes sense to me that all peers in this app use a separate DHT. But if we assume that we mostly have 50 concurrent browser peers with no DHT server and a single rust node, how well would all peers be able to propagate their messages to the other peers?
This is clearly a question that this app should be able to answer. And the tradeoffs are important for any application built with libp2p targeting the web platform.
This is default behaviour of the go kad-dht implementation, https://github.com/libp2p/go-libp2p-kad-dht/blob/master/internal/config/config.go#L19-L20
I didn't see it explicitly encouraged or discouraged and it seems like it wouldn't be the default if that were the case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is also the default for
rust-libp2p
actually :)100%! My thoughts are:
Imagine this:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you tell me about your bootstrap node, I can connect to it. My bootstrap node could then ask me, who I am connected to and find out about your bootstrap node. They can connect to each other, discover that they are both server nodes and form a DHT.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We would definitely need base this on peer records and not just plain addresses. It is still problematic because you could just make up a new identity, put a bunch of addresses in a peer record, distribute them and thus trigger dials to these addresses which is essentially an amplification attack :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's funny, we were just talking about something like this at the js-colo. We used to have something similar in webrtc-star so there is prior art - the signalling server used for the initial SDP handshake also functioned as a peer discovery method since when you connected to it, it would send you a list of other peers connected to the server.
These are high-value peers for browser nodes since they are guaranteed to support the same transports as you.
The thought was, we could have a protocol that supports returning a list of peers you know about filtered by some sort of attribute, the initial one would be the types of multiaddr they are available on - since there's little use returning tcp/quick-only peers to browser nodes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very interesting! Thanks for sharing :)
But, filtering or not, we'd have to figure out how we can trust the peer we just connected to with the data they've given us.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote up a proposal here: libp2p/specs#587