Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Consider renaming the DHT API endpoint #2890

Closed
Stebalien opened this issue Mar 31, 2018 · 6 comments
Closed

Consider renaming the DHT API endpoint #2890

Stebalien opened this issue Mar 31, 2018 · 6 comments

Comments

@Stebalien
Copy link
Member

So, it may cause too much churn to fix this but... the DHT is just one implementation of a routing system. Really, the DHT command encompasses:

  1. Content routing.
  2. Peer routing.
  3. The "record store".

It would be kind of nice to either just call this interface the routing interface or use three independent interfaces.

@Stebalien Stebalien assigned ghost , daviddias and magik6k Mar 31, 2018
@ghost
Copy link

ghost commented Mar 31, 2018

I'd be fine with that -- but only if we should also start transitioning away from the ipfs dht command name too then. (Already have way to many name inconsistencies and less-than-idealisms.)

@ghost
Copy link

ghost commented Mar 31, 2018

(But really it's at the lower end of things we should fix/improve.)

@daviddias
Copy link
Member

💯 agreed! In fact, at the libp2p level,we've already exposed Peer Routing and Content Routing as separate things:

We've kept DHT at the core interface just to match go-ipfs really.

@Stebalien
Copy link
Member Author

we should also start transitioning away from the ipfs dht command name too then

While I agree that ipfs dht is also not quite correct, I'm not convinced we should try to keep the CLI and the API in-sync; UIs generally have different requirements from APIs and I think this is a great opportunity to think through our API a bit.

Eventually, I'd like to expose the CoreAPI as a v1 API (using a high-performance RPC library) and make the CLI use that as a backend. That way:

  1. All the complex, bug-prone CLI stuff can be done on the client.
  2. The API can be significantly more efficient.

@magik6k
Copy link
Member

magik6k commented Apr 10, 2018

I think that we can expose the routing part (find*, provide) under Routing, not sure what to do about the 'record store' part, probably just dropping those methods is acceptable as I haven't seen them used outside tests (or alternatively we could keep them in the DHT api as they are pretty dht specific).

@daviddias daviddias unassigned ghost , daviddias and magik6k Feb 11, 2019
@achingbrain achingbrain transferred this issue from ipfs-inactive/interface-js-ipfs-core Mar 10, 2020
@SgtPooki SgtPooki self-assigned this May 17, 2023
@SgtPooki
Copy link
Member

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

Please feel to reopen with any comments by 2023-06-02. We will do a final pass on reopened issues afterwards (see #4336).

This issue is most likely resolved in Helia, please try it out!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Status: Done
Development

No branches or pull requests

5 participants