-
Notifications
You must be signed in to change notification settings - Fork 443
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
Peer Routing and Content Routing (DHT) #51
Comments
Hi @AlexFreeland, thank you for your feedback, it is highly appreciated We know it is a little confusing at the moment, but there is a key reason for it. The simple answer is, the DHT present in go-ipfs, will be available in JavaScript at https://github.com/libp2p/js-libp2p-dht and that is going to be the 'first DHT'. The 'second DHT', comes from the separation of concerns of Peer Routing and Content Routing, the explanation (and the realization) and can be found described here: ipfs/specs#1 libp2p spec presents some design decisions (https://github.com/libp2p/specs), getting the spec up to date is one of the goals of Q1 this year :) |
Thanks for the response @diasdavid So to clarify: the "second DHT" will entail separate peer and content routing modules, somewhat analogous to the division of responsibilities between https://github.com/libp2p/js-libp2p-kad-routing and https://github.com/libp2p/js-libp2p-kad-record-store? Is the intention to update or supersede these repositories? On a related note: I notice that implementations of the first DHT use the "/ipfs/kad/1.0.0" (and historically "/ipfs/dht") protocol; am I correct in assuming that the second DHT will employ separate protocols for peer and content routing? |
Hi @AlexFreeland, got an update for you :) Check: Note, consider the current implementation as |
Cleaning up some things
Updates project config to publish api docs
## [5.0.1](libp2p/js-libp2p-peer-store@v5.0.0...v5.0.1) (2022-12-16) ### Documentation * publish api docs ([libp2p#51](libp2p/js-libp2p-peer-store#51)) ([149e3b9](libp2p/js-libp2p-peer-store@149e3b9))
Co-authored-by: web3-bot <web3-bot@users.noreply.github.com>
* deps: bump protons-runtime from 4.0.2 to 5.0.0 Bumps [protons-runtime](https://github.com/ipfs/protons) from 4.0.2 to 5.0.0. - [Release notes](https://github.com/ipfs/protons/releases) - [Commits](ipfs/protons@protons-runtime-v4.0.2...protons-runtime-v5.0.0) --- updated-dependencies: - dependency-name: protons-runtime dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> * update .github/workflows/js-test-and-release.yml (libp2p#51) * update .github/workflows/js-test-and-release.yml (libp2p#52) * deps(dev): bump protons from 6.1.3 to 7.0.2 Bumps [protons](https://github.com/ipfs/protons) from 6.1.3 to 7.0.2. - [Release notes](https://github.com/ipfs/protons/releases) - [Commits](ipfs/protons@protons-v6.1.3...protons-v7.0.2) --- updated-dependencies: - dependency-name: protons dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> * chore: regenerate pb defs --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: web3-bot <81333946+web3-bot@users.noreply.github.com> Co-authored-by: achingbrain <alex@achingbrain.net>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## [3.1.3](libp2p/js-libp2p-multistream-select@v3.1.2...v3.1.3) (2023-03-31) ### Trivial Changes * replace err-code with CodeError ([libp2p#36](libp2p/js-libp2p-multistream-select#36)) ([fc2aefd](libp2p/js-libp2p-multistream-select@fc2aefd)), closes [js-libp2p#1269](libp2p#1269) * Update .github/workflows/semantic-pull-request.yml [skip ci] ([1861a94](libp2p/js-libp2p-multistream-select@1861a94)) * Update .github/workflows/semantic-pull-request.yml [skip ci] ([0f312c0](libp2p/js-libp2p-multistream-select@0f312c0)) * Update .github/workflows/semantic-pull-request.yml [skip ci] ([6a277a6](libp2p/js-libp2p-multistream-select@6a277a6)) ### Dependencies * bump it-merge from 2.0.1 to 3.0.0 ([libp2p#51](libp2p/js-libp2p-multistream-select#51)) ([129166b](libp2p/js-libp2p-multistream-select@129166b)) * **dev:** bump it-all from 2.0.1 to 3.0.1 ([libp2p#50](libp2p/js-libp2p-multistream-select#50)) ([d8420a0](libp2p/js-libp2p-multistream-select@d8420a0))
* fix: startup * Revert "fix: Published message field names (#49)" This reverts commit b8f66cd. * fix: close should always invoke callback * fix: avoid race conditions, by quietly ignoring unsub when shutdown * fix: only delete peer when connections match * fix: lint errors * fix: more work on connection shutdown * fix: RPC msg.from is now binary * fix: lint errors * fix: multiple connections to/from same peer This implements a refernce counting scheme. See libp2p/js-libp2p-floodsub#51 (comment) One test is still failing. * fix: topicCIDs => topicIDs * test: can not get this test to work! * fix: lint errors * fix: review changes * fix: lint errors on a comment, this going too far * test: get test working * test: add tests for publishing an array of messages * subscribe: polling for connectivity replaced by handling peer connection event * fix typo
Apologies if this is not the right place for this... still trying to wrap my head around the myriad repositories tied up with this project!
I'm just wondering if there is a roadmap (or similar) for the js-libp2p DHT functionality. I've had a bit of a poke around and discovered the -kad-routing and -kad-record-store modules, but these only provide a subset of the overall functionality described in the whitepaper, and the record store depends on the (seemingly deprecated) js-merkledag-store. Some cursory googling turns up the recently created js-libp2p-dht repo, which it seems natural to assume is the successor to these modules, but I've not found any sort of official indication that this is so.
Is this assumption correct? Will js-libp2p-kad-routing and js-libp2p-kad-record-store be superseded by js-libp2p-dht, and if so: is there a target timeframe in which to roll this out? And what areas (if any) would benefit from having more hands on deck?
Finally: just wanted to say that IPFS and libp2p are among the most exciting, and certainly the most potentially transformative pieces of emerging tech on my radar. Great stuff, everyone :)
The text was updated successfully, but these errors were encountered: