IPIP-379: Delegated IPNS HTTP API

[masih]

Propose HTTP APIs for delegated naming system that enables offloading of naming system to other processes or servers.

Relates to:

• Specify how delegated /routing/v1 API can support new protocols #377

Fixes #343

[lidel]

Thank you for submitting this @masih 🙏

Dropped quick feedback around JSON and Signatures, and including canonical serialization protobuf format as mandatory part of spec (need to support canonical serialization because entire ecosystem expects that).

We could also have JSON as default for quick eyeballing, don't feel strongly about it nor find much utility: it feels like a distraction/security UX/DX footgun but lmk if you had some specific use cases that depend on introducing this additional JSON serialization format

[lidel]

@masih apologies for slow turnaround on this one, wanted to give it a propser thought when i have more time, but it never happened :(

To move things forward, I gave it another pass.

I am ok with making JSON as human-readable as you want – we already made that call in existing /routing/v1/providers, but we can't compromise on signature.

My proposal is to reuse signature and Record Verification steps from the IPNS spec and avoid inventing new things to keep the number of things IPNS implementer needs to do at minimum – details inline.

[lidel]

@masih i'd like to pick this up and move forward. Are you ok with changes suggested above?

Especially my concerns around signatures in JSON (#379 (comment)) which lack useful spec or use case (who will be using JSON?). Perhaps we could remove JSON from this IPIP for now, and add it in future IPIP, if anyone has use case / need for it?

FYSA me and @hacdias plan to support IPNS GET and PUT in Kubo if cid.contact intents to support it.

• Kubo will use the original application/vnd.ipfs.ipns-record for both GETs or PUTs, we will never use JSON.
  • The ipns-record protobuf from the IPNS spec is what other already implemented IPNS routers already use (DHT, ipns over pubsub), and it is true for the rest of ecosystem too: ?format=ipns-record on Gateways, we also have multicodec and IANA registration pending -- all use the well-defined application/vnd.ipfs.ipns-record.

[masih]

@lidel please go ahead we can iterate on remaining issues in separate IPIPs thanks 🙏

[lidel]

Ok! We will circle back to this when @hacdias is back next week and we will make it limited to application/vnd.ipfs.ipns-record + have reference implementation in boxo and kubo. Having end users publish IPNS records to both DHT and IPNI by default is our priority.

TODOs:

• rebase so it shows up on specs.ipfs.tech
• remove JSON representation, keep application/vnd.ipfs.ipns-record for now, reference IANA registration
• replace links to specs.ipfs.tech with proper :ref and :cite
• boxo implementation
• kubo GETs: uses boxo and resolves IPNS via default IPNI in addition to DHT and optional pubsub
• kubo PUTs: publishes records to IPNI

[hacdias]

@lidel I rebased the PR and made the following updates:

• Merged the IPNS routing API with the HTTP Routing V1 specification.
• Removed the JSON representation as you mentioned.
• Removed unnecessary Headers.
• Replaced the links with :ref and :cite.

[lidel]

Applied final editorial tweaks, this looks ready from my end.
Moving to "ready for final review" stage.

Added to the agenda of IPFS Implementers WG call on 2023-06-01 but don't expect issues, since we've reduced the scope to the bare minimum:

• /routing/v1/ipns GET and PUT of serialized IPNS record in existing format, no special headers, no JSON, no streaming

[hacdias]

I opened a Boxo implementation PR here: ipfs/boxo#333

[lidel]

No concerns raised during final ratification during IPFS-Implementers-Sync-2023-06-15, ratified, merging.

Thank you @masih and @hacdias for making this happen!