ipfs / kubo

An IPFS implementation in Go
https://docs.ipfs.tech/how-to/command-line-quick-start/
Other
16.16k stars 3.01k forks source link

Download & upload IPNS records through API / CLI #10484

Open cornwarecjp opened 2 months ago

cornwarecjp commented 2 months ago

Checklist

Description

I would like to have API / RPC functions for downloading / uploading IPNS records. This should include both our own records and third-party records. The reason for this is that I have application-level knowledge of who might have these records and who might be interested in them, so exchanging records directly (whenever two parties are online simultaneously) is a fast and efficient shortcut for my application. Being able to also exchange them through the IPFS network is a nice extra, for redundancy / scalability.

When uploading an IPNS record to Kubo, it's important to know what happens if Kubo already knows a more recent record for that name. I'd say, by default, it should return an error and keep the more recent record. For my application, that behavior will do fine.

When uploading an IPNS record to Kubo, one might want to specify whether it should be pinned (as soon as IPNS pinning is implemented; this feature is already requested, e.g. in #1958 ). I'll add some pinning-specific thoughts to #1958.

lidel commented 2 months ago

@cornwarecjp not sure how useful for your use case, but ipfs routing put --allow-offline "/ipns/$name" "$record" already exists, and we use it to import signed record test fixtures in tests:

https://github.com/ipfs/kubo/blob/330818582dcfb5dd71e66c33ffa5332883fa1c71/.github/workflows/gateway-conformance.yml#L77-L83

Just to clarify my understanding of your request, we seem to already have APIs for both reading and writing:

What is missing? What are ergonomics you'd like to see?

When uploading an IPNS record to Kubo, it's important to know what happens if Kubo already knows a more recent record for that name. I'd say, by default, it should return an error and keep the more recent record.

Would a dedicated command ipfs name record get|put with flags that allow for controlling behavior work?

cornwarecjp commented 2 months ago

@lidel Thanks for the response. I wouldn't have expected IPNS operations under ipns route: I didn't see the link between IPNS and routing (TBH I still don't see it; I'm a bit new to IPFS and still learning). Anyway, it seems sufficient for prototype building, so I'll see if I can make my application work with these.

From the documentation, it's not clear to me what /api/v0/routing/put will do if a record is already known for the name. It's certainly something I'll just try, but it might be a lack of documentation.

BTW, on further searching, I also found /api/v0/name/inspect (docs). Would that be much different from the /ipns/$name?format=ipns-record path?

A dedicated ipfs name record get|put would certainly make it easier to find for developers, but apparently that'd make the same functionality available in multiple places.

lidel commented 2 months ago

afaik ipfs routing put of ipns record only works locally (does not put to the). it should update locally resolved name if the sequence number is higher, if you see different behavior please fill a bug

?format=ipns-record exports the raw signed record ipfs name inspect is just a debug too that reads that record and shows you what is inside