Gateway: response type for fetching signed IPNS records

[lidel]

This is a placeholder for creating IPIP with new response type that clients can use in Accept header or format parameter when making requests to /ipns/ namespace.
The initial need was identified in #296, which discussed returning DNSSEC proofs.

What

When using cryptographically-verifiable IPNS and not DNSLink, there should be a way for HTTP client to ask Gateway for a raw signed IPNS record, allowing light client to verify it locally (without having to trust gateway).

Why

It is possible to fetch immutable /ipfs/{cid} from gateways using CAR and Block response formats, and locally verify that hashes match (trustless retrieval). It is not possible to do the same for /ipns/ atm.

We need this for IPFS Client work happening in Browsers & Platforms group (cc @autonome @meandavejustice @markg85)

TODO

• create PR in Kubo with end-to-end sharness
• create IPIP PR that adds trustless retrieval of IPNS records to gateway specs
  • Accept: application/vnd.ipfs.ipns-record HTTP header
  • ?format=ipns-record

[Winterhuman]

Would it perhaps be a good idea to generalise this to ?format=record so that Peer, Provider, and IPNS records could all be fetched from IPFS gateways trustlessly?

It wouldn't really be trustless since Peer and Provider records in the DHT aren't signed yet, but, it can still be useful for light clients in it's current state.

[lidel]

This requires more analysis, I'd like to avoid inventing duplicated ways of fetching record over HTTP, but at the same time, Reframe adds a lot of overhead for light clients.

In theory, light clients could use Reframe over HTTP+DAG-JSON endpoint to read these records, and I believe IPNS get will also be supported (it would return signed record).

The main drawback of reframe is DAG-JSON response format which introduces a penalty of unnecessary deserialization.
If we could enhance Reframe endpoints to also support DAG-CBOR responses, then record bytes could be used as-is.

At that point it is TBD if we need to invent anything new, or could reuse Reframe.

[lidel]

Recently learned how messy Reframe impl. is, and how much additional work needs to happen before it is production ready. Even then, the overhead of special DAG-JSON/CBOR schema specific to Reframe for sending opaque bytes with IPNS record makes little sense, especially for IoT devices which will never use non-HTTP transport.

At this point, I believe Reframe introduces unacceptable complexity for clients, and there should be a simpler way that is built-into gateway.

We need an IPIP that defines a simple IPNS record response type that returns an opaque, signed IPNS record and nothing more.