-
Notifications
You must be signed in to change notification settings - Fork 31
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
feat: use ipfs dht #113
feat: use ipfs dht #113
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Not sure why a new ID was chosen. Maybe the reasoning is that if folks use this code as a jumping off point we want them to use their own DHT by default instead of using the IPFS dht? If they want to use the IPFS dht, that's fine but maybe it should be a conscious decision. |
@MarcoPolo At the time when this originally implemented to be demoed at IPFS thing it was integrated with RC versions of the respective implementations, as opposed to the more commonly deployed instances connected to the IPFS DHT - for instance there were no deployed go-peers that supported webRTC, and so to avoid wasted dials (which we also didn't have a mechanism for dealing with in js-libp2p as efficiently at the time) we just created our own mesh through our own DHT, which gave us faster discovery when we were demoing. |
Thanks for the context! That makes sense. I think it's probably okay to use the IPFS dht now. |
I think with using an isolated prefix and some bootsrappers aware of that prefix, its much easier to discover peers you actually care about. Theres a ton of peers in the ipfs dht that could make discovering peers you care about more challenging |
Are the default bootstrappers configured to provide peers with protocol ids other than |
I'm trying to avoid requiring dedicated bootstrappers for this app because they'd need TLS certificates. The purpose of this PR is to ease the peer routing for known Peers, i.e. the hosted Rust and Go peers. As you hint, inevitably, the Go/Rust peers will establish connections to peers that aren't relevant for this app, but there's also an advantage, by establishing those connections, their multiaddrs (with ephemeral keys) will be "published" (peer routing is rather implicit) making them easier to resolve from As for the browser client, I'm a little concerned that this will end up opening a bunch of random connections to the bootstrap nodes, but I'm sure we can avoid that by relying on the delegated routing endpoint like we do in Helia-libp2p (https://github.com/ipfs/helia/blob/main/packages/helia/src/utils/libp2p-defaults.browser.ts#L65).
I don't know. I presume not 🤷♂️ |
I deployed the latest main and I can already resolve the multiaddrs of the https://delegated-ipfs.dev/routing/v1/peers/12D3KooWFhXabKDwALpzqMbto94sB7rvmZ6M28hs9Y9xSopDKwQr The rust-peer on the other hand isn't resolvable from the delegated routing endpoint. But it's also not resolvable from Kubo. I think that might be because it's not connecting to the libp2p bootstrap nodes. |
@guillaumemichel Most are just Kubo nodes with the exception of the one Rust one
|
I was able to find my rust peer using |
It's working now since the Rust peer connects to the Bootstrap nodes ( #114) |
This PR changes the protocol ID used by the app to use the IPFS Kademlia DHT.
Open Questions
What roles does the DHT play in this app
Resolving bootstrap node PeerIDs to multiaddrs: My original thinking was that the DHT would be used to make it easier to discover the multiaddrs of deployed Rust and Go peers which have an ephemeral (because of the temp cert which rotates) WebRTC-direct and WebTransport multiaddrs. That way, we can avoid hardcoding ephemeral multiaddrs in the frontend and instead just hardcode the PeerIDs which would be looked up in the DHT. Either way, browsers are still incapable of being reliable DHT clients due to transport constraints.
By using the IPFS KAD DHT maybe we could lean on the delegated routing endpoint in the browser to resolve bootstrap node PeerIDs to multiaddrs. That would require that the Go and Rust peers publish their multiaddrs to the DHT (which should be pretty simple)