Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gateway: response type for fetching signed IPNS records #320

Closed
2 tasks
lidel opened this issue Sep 6, 2022 · 6 comments · Fixed by #351
Closed
2 tasks

Gateway: response type for fetching signed IPNS records #320

lidel opened this issue Sep 6, 2022 · 6 comments · Fixed by #351
Assignees
Labels
dif/expert Extensive knowledge (implications, ramifications) required IPIP (InterPlanetary) Improvement Proposal P1 High: Likely tackled by core team if no one steps up

Comments

@lidel
Copy link
Member

lidel commented Sep 6, 2022

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
@lidel lidel added P1 High: Likely tackled by core team if no one steps up dif/medium Prior experience is likely helpful IPIP (InterPlanetary) Improvement Proposal labels Sep 6, 2022
@lidel lidel self-assigned this Sep 6, 2022
@lidel lidel moved this to Todo in @lidel's IPFS wishlist Sep 6, 2022
@Winterhuman
Copy link

Winterhuman commented Sep 8, 2022

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
Copy link
Member Author

lidel commented Sep 16, 2022

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 lidel added P2 Medium: Good to have, but can wait until someone steps up need/analysis Needs further analysis before proceeding dif/expert Extensive knowledge (implications, ramifications) required and removed P1 High: Likely tackled by core team if no one steps up dif/medium Prior experience is likely helpful labels Sep 16, 2022
@lidel
Copy link
Member Author

lidel commented Oct 17, 2022

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.

@lidel lidel added P1 High: Likely tackled by core team if no one steps up and removed need/analysis Needs further analysis before proceeding P2 Medium: Good to have, but can wait until someone steps up labels Oct 17, 2022
@hacdias hacdias self-assigned this Oct 17, 2022
@RangerMauve
Copy link

I was literally just thinking about how this would be useful to have!

@guseggert
Copy link
Contributor

I have also opened #343 which is intended to be a replacement for Reframe, and thus not specifically tied to gateways.

@BigLep
Copy link
Contributor

BigLep commented Mar 9, 2023

@BigLep BigLep closed this as completed Mar 9, 2023
@github-project-automation github-project-automation bot moved this from 🏃‍♀️ In Progress to 🎉 Done in IPFS Shipyard Team Mar 9, 2023
@github-project-automation github-project-automation bot moved this from Todo to Done in @lidel's IPFS wishlist Mar 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dif/expert Extensive knowledge (implications, ramifications) required IPIP (InterPlanetary) Improvement Proposal P1 High: Likely tackled by core team if no one steps up
Projects
No open projects
Archived in project
Development

Successfully merging a pull request may close this issue.

6 participants