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

Download & upload IPNS records through API / CLI #10484

Open
3 tasks done
cornwarecjp opened this issue Aug 20, 2024 · 3 comments
Open
3 tasks done

Download & upload IPNS records through API / CLI #10484

cornwarecjp opened this issue Aug 20, 2024 · 3 comments
Labels
effort/hours Estimated to take one or several hours exp/intermediate Prior experience is likely helpful kind/enhancement A net-new feature or improvement to an existing feature kind/feature A new feature P2 Medium: Good to have, but can wait until someone steps up

Comments

@cornwarecjp
Copy link

cornwarecjp commented Aug 20, 2024

Checklist

  • My issue is specific & actionable.
  • I am not suggesting a protocol enhancement.
  • I have searched on the issue tracker for my issue.

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.

@cornwarecjp cornwarecjp added the kind/feature A new feature label Aug 20, 2024
@lidel
Copy link
Member

lidel commented Aug 21, 2024

@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:

# Import ipns records
records=$(find ./fixtures -name '*.ipns-record')
for record in $records
do
key=$(basename -s .ipns-record "$record" | cut -d'_' -f1)
kubo-gateway/cmd/ipfs/ipfs routing put --allow-offline "/ipns/$key" "$record"
done

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

  • READ can be done via Gateway or Delegated Routing
    • example: curl "http://127.0.0.1:8080/ipns/$name?format=ipns-record" -o name.ipns-record
    • example: curl "http://delegated-ipfs.dev/routing/v1/ipns/$name?format=ipns-record" -o name.ipns-record
  • WRITE van be done via Kubo RPC
    • CLI: ipfs routing put --allow-offline "/ipns/$name" "$record"
    • HTTP: /api/v0/routing/put (docs)

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?

@lidel lidel added the need/author-input Needs input from the original author label Aug 21, 2024
@cornwarecjp
Copy link
Author

@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
Copy link
Member

lidel commented Aug 28, 2024

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

@lidel lidel added kind/enhancement A net-new feature or improvement to an existing feature P2 Medium: Good to have, but can wait until someone steps up exp/intermediate Prior experience is likely helpful effort/hours Estimated to take one or several hours and removed need/author-input Needs input from the original author labels Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/hours Estimated to take one or several hours exp/intermediate Prior experience is likely helpful kind/enhancement A net-new feature or improvement to an existing feature kind/feature A new feature P2 Medium: Good to have, but can wait until someone steps up
Projects
None yet
Development

No branches or pull requests

2 participants