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

Rename IpfsDHT to Kad or something else #337

Open
hsanjuan opened this issue May 20, 2019 · 4 comments
Open

Rename IpfsDHT to Kad or something else #337

hsanjuan opened this issue May 20, 2019 · 4 comments
Labels
effort/days Estimated to take multiple days, but less than a week exp/expert Having worked on the specific codebase is important P4 Very low priority

Comments

@hsanjuan
Copy link
Contributor

While IPFS uses this DHT, this DHT does not need IPFS for anything.

@KristenPire
Copy link

KristenPire commented May 21, 2019

I think the same as you, and so i've made a PR for this issue.

@gpestana
Copy link
Contributor

I remember the naming has been kept for backwards compatibility, so you probably want to keep an alias too (cross comment to the PR #338). @anacrolix opened a PR to solve this not too long ago, but the merge got postponed. The discussion shows why (#223)

@aschmahmann
Copy link
Contributor

aschmahmann commented Sep 4, 2019

I disagree with this idea given the current way this library is set up. However, if we were prepared to make a couple changes I'd be all for it.

  1. The protocol ID is here and listed as /ipfs/kad/1.0.0
  2. There is special handling for the IPFS use case of Provider records instead of just Get/Put.
    • Provider records could just be special handlers on Get/Put that deal with Key-MultiValue instead of Key-Value
    • Key-MultiValue could have separate Get/Put that are not restricted to provider records

@anacrolix
Copy link
Contributor

A cleaner DHT interface can be ripped out from IpfsDHT, and IpfsDHT made to wrap it, conforming the expectations asserted at

go-libp2p-kad-dht/dht.go

Lines 73 to 81 in a12e621

// Assert that IPFS assumptions about interfaces aren't broken. These aren't a
// guarantee, but we can use them to aid refactoring.
var (
_ routing.ContentRouting = (*IpfsDHT)(nil)
_ routing.Routing = (*IpfsDHT)(nil)
_ routing.PeerRouting = (*IpfsDHT)(nil)
_ routing.PubKeyFetcher = (*IpfsDHT)(nil)
_ routing.ValueStore = (*IpfsDHT)(nil)
)
.

@Stebalien Stebalien mentioned this issue Apr 21, 2020
7 tasks
@Stebalien Stebalien added effort/days Estimated to take multiple days, but less than a week exp/expert Having worked on the specific codebase is important P4 Very low priority labels Jul 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/days Estimated to take multiple days, but less than a week exp/expert Having worked on the specific codebase is important P4 Very low priority
Projects
None yet
Development

No branches or pull requests

6 participants