You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.
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.)
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:
All the complex, bug-prone CLI stuff can be done on the client.
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).
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:
It would be kind of nice to either just call this interface the routing interface or use three independent interfaces.
The text was updated successfully, but these errors were encountered: