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

Point users at canonical kubo/client/rpc library #9124

Closed
10 of 11 tasks
Tracked by #9142
lidel opened this issue Jul 19, 2022 · 17 comments
Closed
10 of 11 tasks
Tracked by #9142

Point users at canonical kubo/client/rpc library #9124

lidel opened this issue Jul 19, 2022 · 17 comments

Comments

@lidel
Copy link
Member

lidel commented Jul 19, 2022

Part of #8959 – based on discussions from IPFS Thing 2022
JS counterpart: #9125

Current state

Screenshot 2022-07-19 at 14-49-53 ipfs_kubo IPFS implementation in Go

We have two RPC clients for "GO-IPFS":

After renaming to Kubo, this state of things is arguably a really really bad user experience:

  • Which RPC client should GO developers use to interact with Kubo?
  • What is the reason to choose one over another?

Desired state

Ideally, we should have one Kubo client at https://github.com/ipfs/go-kubo-rpc-client

Keeping go- prefix is important because we want consistency across languages,
and Kubo team will maintain go-kubo-rpc-client too.

TODO

cc @2color @BigLep @Jorropo @ajnavarro

@lidel
Copy link
Member Author

lidel commented Dec 9, 2022

Food for thought:

Our CLI for RPC over HTTP is built with https://github.com/ipfs/go-ipfs-cmds/

We use this library for generating docs at https://docs.ipfs.tech/reference/kubo/rpc/
(Generator code at https://github.com/ipfs/ipfs-docs/tree/main/tools/http-api-docs)

Would be really nice if we leveraged this somehow in HTTP client library.

Ideally, it would depend on Kubo, and generate client for commands based on go-ipfs-cmds annotations present in Kubo sources. Not sure how feasible this is, but someone wants to explore this, we could add more annotations if needed – prior art in #8802.

@lidel
Copy link
Member Author

lidel commented May 22, 2023

Triage notes:

@MichaelMure
Copy link
Contributor

One not-so-nice aspect of this idea is that suddenly your API client depend on quite heavy and break prone dependencies like libp2p. Maybe consider at least a dedicated go.mod file?

@Jorropo
Copy link
Contributor

Jorropo commented May 22, 2023

@MichaelMure go-ipfs-http-client already depends on libp2p https://github.com/ipfs/go-ipfs-http-client/blob/b19af5f15743e0923bae036babdf5437624142a7/go.mod#L11, this is required to provide better types than string everywhere in the API (peer.ID, ...).
I'm not planning to move go-ipfs-api, as it's not a blocker for our CI and I don't want to have to think about two HTTP clients.

@lidel
Copy link
Member Author

lidel commented May 23, 2023

@Jorropo is go-ipfs-http-client the thing we want to support going forward?
If so, should we rename it to ./client/go-kubo-rpc-client or ./client/httprpc or ./client/kuborpc during the move, to avoid renaming in the future?
(one breaking change, instead of two)

@BigLep
Copy link
Contributor

BigLep commented May 23, 2023

2023-05-23 conversation:

  • We are going to copy to ./client/httprpc
  • Add Kubo changelog.md
  • go-ipfs-http-client: Add stubs
  • go-ipfs-http-client: Add readme notice
  • go-ipfs-http-client: archive the repo

@lidel
Copy link
Member Author

lidel commented May 23, 2023

Maybe let's just call it client/rpc? Will look less ugly, and will allow us to use websockets or webtransport behind the scenes if we ever need to opportunistically use other transport than plain HTTP:

kuboClient "github.com/ipfs/kubo/client/rpc"
node, err := kuboClient.NewLocalApi()

@BigLep
Copy link
Contributor

BigLep commented May 30, 2023

@Jorropo : do you have the corresponding PR for this?

@Jorropo
Copy link
Contributor

Jorropo commented May 30, 2023

do you have the corresponding PR for this?

#9906

@lidel lidel changed the title Create go-kubo-rpc-client library Create canonical kubo/client/rpc library Jun 15, 2023
@lidel lidel changed the title Create canonical kubo/client/rpc library Point users at canonical kubo/client/rpc library Jun 15, 2023
@lidel
Copy link
Member Author

lidel commented Jun 15, 2023

Updated progress in the top comment + filled ipfs/go-ipfs-http-client#184 and ipfs/go-ipfs-api#296 based on my understanding of next steps.

@ElPaisano
Copy link
Contributor

Hi all, triaging old ipfs-docs issues right now and I came across Issue 1194: List other Kubo RPC API clients, which depends on this. It looks like work can't yet start on 1194?

@lidel
Copy link
Member Author

lidel commented Aug 22, 2023

@ElPaisano good question!

We've had a release with kubo/client/rpc library already, so I think we can move forward with this in sense that we no longer mention https://github.com/ipfs/go-ipfs-http-client and https://github.com/ipfs/go-ipfs-api and instead point users in docs and readmes to kubo/client/rpc which lives in this repo.

(This can happen without being blocked by ipfs/go-ipfs-http-client#184 and ipfs/go-ipfs-api#296)

@Jorropo
Copy link
Contributor

Jorropo commented Aug 22, 2023

https://github.com/ipfs/go-ipfs-api is not replaced by kubo/client/rpc, ideally we would but the coreapi implemented by kubo/client/rpc lacks some Kubo features and endpoints.

kubo/client/rpc is a direct upgrade of https://github.com/ipfs/go-ipfs-http-client in all ways (it's a fork after all)

@BigLep
Copy link
Contributor

BigLep commented Aug 22, 2023

kubo/client/rpc is the only thing we're supporting or investing in. Lets just point users there.

As a result, I agree with @lidel, that ipfs/ipfs-docs#1194 shouldn't be blocked. Carry on please @ElPaisano.

@ElPaisano
Copy link
Contributor

sounds good, thanks all

@BigLep
Copy link
Contributor

BigLep commented Oct 5, 2023

2023-10-05 conversation: emphasis before IPFS Connect is just to make sure we're always pointing at the new thing.

@hacdias
Copy link
Member

hacdias commented Oct 13, 2023

The only point remaining here is to create an automation to alert us when a new command is added, which I extracted to #10178. I think that is enough of its own thing to deserve its own issue. Therefore, I am closing this one. I think the main points (documentation, archiving repositories, directing to new clients) have been done.

If you find a wild mention to the old clients that we no longer want to support, feel free to submit a PR to replace the links.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Archived in project
Development

No branches or pull requests

6 participants