This IPIP specifies
/routing/v1/ipns HTTP API to offload naming system onto another process or server.
One of the motivations of this document is to introduce simple to use HTTP APIs and ultimately reduce barrier for interaction across alternative systems.
Expanding on the motivations of [ipip-0337], the work here concentrates on delegation of IPNS over HTTP API. Naming is part of the core IPFS DHT functionality. The performance of naming system over the IPFS DHT can suffer from long delays due to churn of records and quorum requirements.
/routing/v1/ipns to the existing [http-routing-v1] specification.
The rationale for delegated IPNS over HTTP APIs closely follows the reasoning listed in [ipip-0337].
The document proposes the following:
PUTsemantics for publication and resolution of IPNS records.
The ability to offload naming to another process or server using a simple HTTP API brings several benefits:
See the "Compatibility" section of [ipip-0337].
Standard IPNS record serialization format is used, making it fully compatible with the existing IPNS ecosystem.
application/vnd.ipfs.ipns-record protobuf serialization format.
This format is widely in use in IPNS over PubSub and DHT routing systems.
Further, interoperability across the existing and HTTP APIs is also desirable in order to reduce the barrier for adoption of the delegated HTTP APIs.
To maximize interoperability with existing ecosystem, the canonical IPNS record serialization format [ipns-record] (
0x0300) can be requested with content type
All interaction over the APIs should use TLS to protect against third-party observation and tampering. Additionally, the IPNS records must be validated according to the rules stated in [ipns-record] before further processing.
To avoid Denial of Service attack, maximum IPNS record size defined in [ipns-record] applies.
Privacy in delegated IPNS is out of scope for this IPIP.
Copyright and related rights waived via CC0.