Skip to content

Commit 5bda58f

Browse files
committed
ipip: ipns signed records response format
1 parent 748e1c4 commit 5bda58f

File tree

3 files changed

+102
-3
lines changed

3 files changed

+102
-3
lines changed

src/http-gateways/path-gateway.md

+7-2
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ description: >
44
The most versatile form of IPFS Gateway is a Path Gateway. It exposes namespaces, such
55
as /ipfs/ and /ipns/ under an HTTP server root and provides basic primitives for integrating
66
IPFS resources within the existing HTTP stack.
7-
date: 2023-02-27
7+
date: 2023-03-30
88
maturity: reliable
99
editors:
1010
- name: Marcin Rataj
@@ -137,6 +137,7 @@ For example:
137137
- [application/vnd.ipld.dag-cbor](https://www.iana.org/assignments/media-types/application/vnd.ipld.dag-cbor) – requests [IPLD Data Model](https://ipld.io/docs/data-model/) representation serialized into [DAG-CBOR format](https://ipld.io/docs/codecs/known/dag-cbor/). If the requested CID already has `dag-cbor` (0x71) codec, data is validated as DAG-CBOR before being returned as-is. Invalid DAG-CBON produces HTTP Error 500.
138138
- [application/json](https://www.iana.org/assignments/media-types/application/json) – same as `application/vnd.ipld.dag-json`, unless the CID's codec already is `json` (0x0200). Then, the raw JSON block can be returned as-is without any conversion.
139139
- [application/cbor](https://www.iana.org/assignments/media-types/application/cbor) – same as `application/vnd.ipld.dag-cbor`, unless the CID's codec already is `cbor` (0x51). Then, the raw CBOR block can be returned as-is without any conversion.
140+
- [application/vnd.ipfs.ipns-record](https://www.iana.org/assignments/media-types/application/vnd.ipfs.ipns-record) – requests a verifiable [IPNS Record](../ipns/IPNS.md#ipns-record) to be returned. Produces 400 Bad Request if the content is not under the IPNS namespace, or contains a path.
140141

141142
### `Range` (request header)
142143

@@ -201,14 +202,16 @@ parameter, if present)
201202

202203
Optional, `format=<format>` can be used to request specific response format.
203204

204-
This is a URL-friendly alternative to sending an [`Accept`](#accept-request-header) header. These are the equivalents:
205+
This is a URL-friendly alternative to sending an [`Accept`](#accept-request-header) header.
206+
These are the equivalents:
205207
- `format=raw``Accept: application/vnd.ipld.raw`
206208
- `format=car``Accept: application/vnd.ipld.car`
207209
- `format=tar``Accept: application/x-tar`
208210
- `format=dag-json``Accept: application/vnd.ipld.dag-json`
209211
- `format=dag-cbor``Accept: application/vnd.ipld.dag-cbor`
210212
- `format=json``Accept: application/json`
211213
- `format=cbor``Accept: application/cbor`
214+
- `format=ipns-record``Accept: application/vnd.ipfs.ipns-record`
212215

213216
<!-- TODO Planned: https://github.com/ipfs/go-ipfs/issues/8769
214217
- `selector=<cid>` can be used for passing a CID with [IPLD selector](https://ipld.io/specs/selectors)
@@ -575,6 +578,8 @@ The following response types require an explicit opt-in, can only be requested w
575578
- Arbitrary DAG as a verifiable CAR file or a stream, see [application/vnd.ipld.car](https://www.iana.org/assignments/media-types/application/vnd.ipld.car).
576579
- TAR (`?format=tar`)
577580
- Deserialized UnixFS files and directories as a TAR file or a stream, see [IPIP-288](https://github.com/ipfs/specs/pull/288)
581+
- IPNS Record
582+
- Protobuf bytes representing a verifiable [IPNS Record](../ipns/IPNS.md#record-serialization-format) (multicodec `0x0300`)
578583

579584
# Appendix: notes for implementers
580585

src/http-gateways/trustless-gateway.md

+13-1
Original file line numberDiff line numberDiff line change
@@ -4,11 +4,14 @@ description: >
44
Trustless Gateways are a minimal subset of Path Gateways that allow light IPFS
55
clients to retrieve data behind a CID and verify its integrity without delegating any
66
trust to the gateway itself.
7-
date: 2022-11-09
7+
date: 2023-03-30
88
maturity: reliable
99
editors:
1010
- name: Marcin Rataj
1111
github: lidel
12+
- name: Henrique Dias
13+
github: hacdias
14+
url: https://hacdias.com/
1215
tags: ['httpGateways', 'lowLevelHttpGateways']
1316
order: 1
1417
---
@@ -35,6 +38,14 @@ Downloads data at specified CID.
3538

3639
Same as GET, but does not return any payload.
3740

41+
## `GET /ipns/{key}[?{params}]`
42+
43+
Downloads data at specified IPNS Key. Verifiable :cite[ipns-record] can be requested via `?format=ipns-record`
44+
45+
## `HEAD /ipns/{key}[?{params}]`
46+
47+
same as GET, but does not return any payload.
48+
3849
# HTTP Request
3950

4051
Same as in :cite[path-gateway], but with limited number of supported response types.
@@ -52,6 +63,7 @@ Below response types MUST to be supported:
5263

5364
- [application/vnd.ipld.raw](https://www.iana.org/assignments/media-types/application/vnd.ipld.raw) – requests a single, verifiable raw block to be returned
5465
- [application/vnd.ipld.car](https://www.iana.org/assignments/media-types/application/vnd.ipld.car) – disables IPLD/IPFS deserialization, requests a verifiable CAR stream to be returned
66+
- [application/vnd.ipfs.ipns-record](https://www.iana.org/assignments/media-types/application/vnd.ipfs.ipns-record) – requests a verifiable :cite[ipns-record] (multicodec `0x0300`).
5567

5668
# HTTP Response
5769

src/ipips/ipip-0351.md

+82
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
---
2+
title: "IPIP 0351: IPNS Signed Records Response Format on HTTP Gateways"
3+
date: 2022-11-29
4+
ipip: ratified
5+
editors:
6+
- name: Henrique Dias
7+
github: hacdias
8+
url: https://hacdias.com/
9+
relatedIssues:
10+
- https://github.com/ipfs/specs/issues/320
11+
- https://github.com/ipfs/specs/pull/351
12+
- https://github.com/ipfs/kubo/pull/9399
13+
order: 351
14+
tags: ['ipips']
15+
---
16+
17+
## Summary
18+
19+
Add IPNS Signed Records response format to the [HTTP Gateway](/http-gateways/).
20+
21+
## Motivation
22+
23+
Currently, the gateway allows for trustless retrieval of data under the `/ipfs`
24+
namespace, but fetching the data as a CAR, or Block, and then verifying it locally.
25+
This is especially important for light IPFS clients, so that they can retrieve
26+
data from other gateways without delegating any of the trust to them. Unfortunately,
27+
this is not possible under the `/ipns` namespace.
28+
29+
In contrary to DNSLink, IPNS provides cryptographically-verifiable records that
30+
can be verified by the client. This means that, if a gateway is able to provide
31+
the IPNS signed record to an HTTP client, trustless retrieval would also be available
32+
under the `/ipns` namespace.
33+
34+
In this IPIP, we propose adding :cite[ipns-record] as a response
35+
format to the gateway under the `/ipns` namespace, allowing for trustless
36+
retrieval of IPNS records.
37+
38+
## Detailed design
39+
40+
The solution is to allow the Gateway to provide an IPNS signed record by
41+
requesting it using either the `Accept` HTTP header or the `format` URL query.
42+
43+
## Test fixtures
44+
45+
IPNS records for testing can be generated in Kubo by creating an IPNS record:
46+
47+
```bash
48+
$ ipfs key gen <key-name>
49+
k51Key
50+
51+
$ ipfs name publish /ipfs/bafyHash --key=<key-name> --ttl=<record-ttl>
52+
Published to k51Key: /ipfs/bafyHash
53+
54+
$ ipfs routing get /ipns/k51Key > key.pb
55+
```
56+
57+
## Design rationale
58+
59+
The current gateway already supports different response formats via the
60+
`Accept` HTTP header and the `format` URL query. This IPIP proposes adding
61+
one more supported format to that list.
62+
63+
### User benefit
64+
65+
By providing IPNS records through the gateway, IPFS light clients are able
66+
to race multiple gateways in search for an IPNS record for a certain IPNS key.
67+
This way, IPFS light clients do not necessarily need to implement the required
68+
machinery to fetch IPNS records from other IPFS nodes through the DHT or PubSub.
69+
70+
In addition, the retrieval of IPNS records is trustless in the sense that they can
71+
be verified by the client since the IPNS record includes a cryptographic signature
72+
provided by its creator.
73+
74+
### Compatibility
75+
76+
This IPIP proposes a new format to be added to the gateway, but does not change
77+
any prior format. Therefore, this IPIP is backwards compatible. Please note
78+
that IPNS records are also added to the :cite[trustless-gateway] specification.
79+
80+
### Copyright
81+
82+
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

0 commit comments

Comments
 (0)