Add a transport code to indicate content is provided via Trustless HTTP Gateway #321
Conversation
per the trustless gateway spec
table.csv
Outdated
| @@ -143,6 +143,7 @@ car-index-sorted, serialization, 0x0400, draft, CARv2 | |||
| car-multihash-index-sorted, serialization, 0x0401, draft, CARv2 MultihashIndexSorted index format | |||
| transport-bitswap, transport, 0x0900, draft, Bitswap datatransfer | |||
| transport-graphsync-filecoinv1, transport, 0x0910, draft, Filecoin graphsync datatransfer | |||
| transport-gateway-trustless, transport, 0x0920, draft, HTTP car datatransfer | |||
There was a problem hiding this comment.
With "gateway" in the name, am i right to assume this is for car transfer over IPFS HTTP gateway?
If so, would it make sense to include ipfs in the name?
| transport-gateway-trustless, transport, 0x0920, draft, HTTP car datatransfer | |
| transport-ipfs-gateway-trustless, transport, 0x0920, draft, HTTP IPFS Gateway CAR datatransfer |
There was a problem hiding this comment.
yes, if we view this namespace as having a very broad audience, making the assumption that "gateway" bears the singular meaning we think it does isn't appropriate
+1
There was a problem hiding this comment.
Why would you restrict this to CAR?
There was a problem hiding this comment.
@masih - i would be okay including ipfs here if there aren't objections
@rvagg - some more specific features could be passed in metadata about the transport - in the same way we specify characteristics for graphsync we could potentially allow advertisements of http support further specify what subset of the gateway specification is supported. That said, I'd hope that as we get to a single definition from https://specs.ipfs.tech/http-gateways/path-gateway/#ref-trustless-gateway we might be able to converge to an expected set of semantics for what is expected from an http transport.
@aschmahmann - do you mean versus also including single blocks, or versus also including unverifiable responses?
There was a problem hiding this comment.
do you mean versus also including single blocks, or versus also including unverifiable responses?
I meant single blocks
There was a problem hiding this comment.
Note: I would prefer knowing what this thing actually is before we merge it as it seems like there are a bunch of unknowns as to what this actually means/how it will be used and the point of the shared table is to enable interoperability (if it wasn't then people could just have system-specific enums and call it a day).
If the desire of the crowd here is to merge this PR before there are any definitions I'd like to request that the entry be removed from the table should it arise that this entry turns out to be abandoned or there is no definition of it in X (maybe 3 or as high as 6?) months.
No we haven't held other entries to this bar (especially the really old ones), but it'd be nice if we could do better going forward here and it doesn't seem like a huge ask that more than the people involved in this PR would be able to figure out what is meant by a the code being added to the table.
There was a problem hiding this comment.
We can change the comment to
HTTP IPFS Gateway trustless datatransfer
is there other wording at this stage you would propose / prefer?
I'm happy to re-visit in 3-6 months to
(a) remove if we aren't using it
(b) revising wording to reflect / point to the specification we've ended up with
|
how will this code end up getting used in the network chatter? |
my expectation is that this will be used in the same context as |
|
The only remaining hold-up here is the use of "gateway" unadorned, since that has a specific meaning for us but not all audiences of this table, |
|
I'd support adding IPFS -- @willscott ? |
|
updated name to be less ambiguous |
|
I've updated the comment per @aschmahmann 's request. @rvagg i don't think we're waiting for anything else here and I believe you're the one with relevant approval powers |
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
| @@ -143,6 +143,7 @@ car-index-sorted, serialization, 0x0400, draft, CARv | |||
| car-multihash-index-sorted, serialization, 0x0401, draft, CARv2 MultihashIndexSorted index format | |||
| transport-bitswap, transport, 0x0900, draft, Bitswap datatransfer | |||
| transport-graphsync-filecoinv1, transport, 0x0910, draft, Filecoin graphsync datatransfer | |||
| transport-ipfs-gateway-http, transport, 0x0920, draft, HTTP IPFS Gateway trustless datatransfer | |||
There was a problem hiding this comment.
💭 This terribly long string will most likely be sent with every IPNI roundtrip, which is not the best,
Due to the way IPNI implemented /routing/v1 API, we use string that can change at atny time, and not the number: ipfs/specs#377
I'd be strongly recommending moving to number instead of string. We've seen strings in this table change multiple times in the past ( /ipfs/ → /p2p, then /ipns-ns → /ipns etc) -- cc @masih @willscott to be aware of how brittle this string is
There was a problem hiding this comment.
ℹ️ the cid.contact find response https://github.com/ipni/specs/blob/main/schemas/v1/openapi.yaml#L120 does use compact number versions
There was a problem hiding this comment.
IPNI metadata always uses the varint numerical value.
There was a problem hiding this comment.
sgtm, I've opened ipfs/specs#403 for explicitly supporting hex codes on /routing/v1, and using strings only for "ossified" things.
|
Another comment is that trustless gateway basic primitive is a block, not a CAR. CAR is only means of sending more than a single block - important distinction, because there is no trustless gateway without |
lidel
changed the title
lidel
changed the title
lidel
changed the title
Add SDK to aid parsing IPNI metadata that represents IPFS Gateway HTTP transport protocol. Relates to: - multiformats/multicodec#321 Fixes #21
Add SDK to aid parsing IPNI metadata that represents IPFS Gateway HTTP transport protocol. Relates to: - multiformats/multicodec#321 Fixes #21
Add SDK to aid parsing IPNI metadata that represents IPFS Gateway HTTP transport protocol. Relates to: - multiformats/multicodec#321 Fixes #21
per the trustless gateway spec
The exact semantics of this spec are evolving, but might as well reserve a code that we can use for indicating the existence of an HTTP endpoint for index providers.