-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Closed
Labels
effort/weeksEstimated to take multiple weeksEstimated to take multiple weekskind/enhancementA net-new feature or improvement to an existing featureA net-new feature or improvement to an existing featurekind/maintenanceWork required to avoid breaking changes or harm to project's status quoWork required to avoid breaking changes or harm to project's status quostarmaps
Description
ETA: 2022-12-16
Part of #8959 – based on discussions from IPFS Thing 2022
GO counterpart: #9124
Current state
Kubo shares RPC client with JS-IPFS:
After renaming GO-IPFS to Kubo, this state of things is arguably a bad user experience:
- js-ipfs and Kubo are joined at the RPC hip – unable to improve their respective RPC interfaces, and pretending to be interoperable:
- js-ipfs provides gRPC endpoint while Kubo does not
- we don't test all RPC command because implementations diverged already
- making change to RPC in Kubo forces us to do the same change in js-ipfs, and makes it extremely hard to coordinate releases to minimize breaking changes to rpc client library users (example: fix: multibase in pubsub http rpc #8183 & fix(pubsub): multibase in pubsub http rpc js-ipfs#3922)
Desired state
Ideally, we should have one Kubo client at https://github.com/ipfs/js-kubo-rpc-client and kubo-rpc-client
on NPM.
Keeping go-
prefix is important because we want consistency across languages,
and Kubo team will maintain go-kubo-rpc-client
too.
TODO
Below is a broad strokes plan, feel free to adjust if something else makes more sense:
- fork https://github.com/ipfs/js-ipfs/tree/master/packages/ipfs-http-client and name it https://github.com/ipfs/js-kubo-rpc-client
- generate API docs for js-kubo-rpc-client and publish them to GitHub pages
(this way developers are not forced to use https://github.com/ipfs/js-ipfs/tree/master/docs/core-api which is maintained manually and often contains bugs or parameters that are not supported by Kubo) - publish js-kubo-rpc-client to npm automatically with github action via aegir
- update https://github.com/ipfs/js-ipfsd-ctl to support both
ipfsHttpModule
andkuboRpcModule
(we will also rename binary package, but that is tracked separately in Rename NPM package to kubo npm-kubo#51) - switch https://github.com/ipfs/interop to talk to Kubo daemon over
js-kubo-rpc-client
and run it in the CI ofjs-kubo-rpc-client
repo
(we already runipfs/interop
tests in Kubo CI, but it is too late, we should do it in the library repo CI too) -
decide if js-kubo-rpc-client CI should reuse tests against Core APIs interface-ipfs-coreKubo RPC Client should have it's own tests, stripped out from interface-ipfs-core. And we should only bring over the tests that are applicable for kubo's supported RPC calls. Pull out relevant tests from interface-ipfs-core js-kubo-rpc-client#5 - update docs to mention only the new client
- add mention of
js-kubo-rpc-client
to Kubo README - docs.ipfs.io - find mentions of
ipfs-http-client
and switch tokubo-rpc-client
where Kubo daemon is used- https://docs.ipfs.io/reference/js/api/ - add note when to use
ipfs-http-client
(js-ipfs rpc client), and when the kubo one
- https://docs.ipfs.io/reference/js/api/ - add note when to use
- add mention of
Followups
Below are good improvements, but since we didn't have them with ipfs-http-client, we're not requiring them here.
- CI test that fails when a new command is added to Kubo and is not supported by
kubo-rpc-client
yet- trackled separately in Automation to detect new Kubo commands js-kubo-rpc-client#47
Metadata
Metadata
Labels
effort/weeksEstimated to take multiple weeksEstimated to take multiple weekskind/enhancementA net-new feature or improvement to an existing featureA net-new feature or improvement to an existing featurekind/maintenanceWork required to avoid breaking changes or harm to project's status quoWork required to avoid breaking changes or harm to project's status quostarmaps