IPIP-0379: Delegated IPNS HTTP API

4. Design rationale

The rationale for delegated IPNS over HTTP APIs closely follows the reasoning listed in [ipip-0337].

The document proposes the following:

HTTP GET and PUT semantics for publication and resolution of IPNS records.
Use of existing IPNS Record serialization format as HTTP Content-Type application/vnd.ipfs.ipns-record.

4.1 User benefit

The ability to offload naming to another process or server using a simple HTTP API brings several benefits:

It reduces the resource drain on light clients such as JavaScript running on a web page, mobile devices, IoT devices, and gateway HTTP services.
It enables scaling of IPNS resolution separately from retrieval and deserialization/verification services.
Expands the utility of IPNS beyond IPFS nodes, contributes to its broader adoption and impact by reducing integration costs.

4.2 Compatibility

See the "Compatibility" section of [ipip-0337].

4.2.1 Serialization Format

Standard IPNS record serialization format is used, making it fully compatible with the existing IPNS ecosystem.

[ipns-record] uses 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 application/vnd.ipfs.ipns-record.

4.3 Security

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.

4.4 Alternatives

See:

IPNS over (libp2p over HTTP). While it may be possible in the future, it has more narrow utility and way bigger implementation complexity than libp2p-agnostic HTTP API with protobuf GET/PUT.
Reframe; it was deprecated and now removed. Historical reasons can be found in [ipip-0337].
JSON IPNS Record representation was descoped due to open question how signing should work and unclear use case (discussion).
API-specific max record size was descoped, as it would introduce interop problems harmful to the IPNS ecosystem.

IPIP-0379: Delegated IPNS HTTP API

1. Summary

2. Motivation

3. Detailed design