-
Notifications
You must be signed in to change notification settings - Fork 237
IPIP-378: Delegated Routing HTTP POST API #378
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
Changes from 1 commit
6336689
68c0dff
5bc8b14
4db804a
d9287e5
0f74972
82aa9d9
921b0b6
94429a5
05b000e
30a5e3b
7b32f53
fbefb1b
f6f0d9b
cf83c02
da12e11
05dceba
ccbc085
a69d2b8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -66,13 +66,13 @@ Specifications for some transfer protocols are provided in the "Transfer Protoco | |||||||||||||
|
|
||||||||||||||
| ### `GET /routing/v1/providers/{CID}` | ||||||||||||||
|
|
||||||||||||||
| #### Response codes | ||||||||||||||
| #### `GET` Response codes | ||||||||||||||
|
|
||||||||||||||
| - `200` (OK): the response body contains 0 or more records | ||||||||||||||
| - `404` (Not Found): must be returned if no matching records are found | ||||||||||||||
| - `422` (Unprocessable Entity): request does not conform to schema or semantic constraints | ||||||||||||||
|
|
||||||||||||||
| #### Response Body | ||||||||||||||
| #### `GET` Response Body | ||||||||||||||
|
|
||||||||||||||
| ```json | ||||||||||||||
| { | ||||||||||||||
|
|
@@ -90,6 +90,48 @@ Response limit: 100 providers | |||||||||||||
|
|
||||||||||||||
| Each object in the `Providers` list is a *read provider record*. | ||||||||||||||
|
|
||||||||||||||
| ### `PUT /routing/v1/providers` | ||||||||||||||
|
|
||||||||||||||
| #### `PUT` Response codes | ||||||||||||||
|
|
||||||||||||||
| - `200` (OK): the server processed the full list of provider records (possibly unsuccessfully, depending on the semantics of the particular records) | ||||||||||||||
| - `400` (Bad Request): the server deems the request to be invalid and cannot process it | ||||||||||||||
| - `422` (Unprocessable Entity): request does not conform to schema or semantic constraints | ||||||||||||||
| - `501` (Not Implemented): the server does not support providing records | ||||||||||||||
|
|
||||||||||||||
| #### `PUT` Request Body | ||||||||||||||
|
|
||||||||||||||
| ```json | ||||||||||||||
| { | ||||||||||||||
| "Providers": [ | ||||||||||||||
| { | ||||||||||||||
| "Protocol": "<protocol_name>", | ||||||||||||||
| "Schema": "bitswap", | ||||||||||||||
| ... | ||||||||||||||
| } | ||||||||||||||
| ] | ||||||||||||||
| } | ||||||||||||||
| ``` | ||||||||||||||
|
|
||||||||||||||
| Each object in the `Providers` list is a *write provider record*. | ||||||||||||||
|
|
||||||||||||||
| #### `PUT` Response Body | ||||||||||||||
|
|
||||||||||||||
| ```json | ||||||||||||||
| { | ||||||||||||||
| "ProvideResults": [ | ||||||||||||||
| { ... } | ||||||||||||||
| ] | ||||||||||||||
| } | ||||||||||||||
| ``` | ||||||||||||||
|
|
||||||||||||||
| - `ProvideResults` is a list of results in the same order as the `Providers` in the request, and the schema of each object is determined by the `Protocol` of the corresponding write object (called "Write Provider Records Response" in the Known Transfer Protocols section) | ||||||||||||||
| - This may contain output information such as TTLs, errors, etc. | ||||||||||||||
| - It is undefined whether the server will allow partial results | ||||||||||||||
| - The work for processing each provider record should be idempotent so that it can be retried without excessive cost in the case of full or partial failure of the request | ||||||||||||||
| - Default limit of 100 keys per request | ||||||||||||||
| - Implements pagination according to the Pagination section | ||||||||||||||
|
|
||||||||||||||
| ## Pagination | ||||||||||||||
|
|
||||||||||||||
| This API does not support pagination, but optional pagination can be added in a backwards-compatible spec update. | ||||||||||||||
|
|
@@ -118,7 +160,7 @@ limits, allowing every site to query the API for results: | |||||||||||||
|
|
||||||||||||||
| ```plaintext | ||||||||||||||
| Access-Control-Allow-Origin: * | ||||||||||||||
| Access-Control-Allow-Methods: GET, OPTIONS | ||||||||||||||
| Access-Control-Allow-Methods: GET, PUT, OPTIONS | ||||||||||||||
| ``` | ||||||||||||||
|
|
||||||||||||||
| ## Known Transfer Protocols | ||||||||||||||
|
||||||||||||||
|
|
@@ -148,6 +190,60 @@ Specification: [ipfs/specs/BITSWAP.md](https://github.com/ipfs/specs/blob/main/B | |||||||||||||
|
|
||||||||||||||
| The server should respect a passed `transport` query parameter by filtering against the `Addrs` list. | ||||||||||||||
|
|
||||||||||||||
| #### Bitswap Write Provider Records | ||||||||||||||
lidel marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||||||||||
|
|
||||||||||||||
| ```json | ||||||||||||||
| { | ||||||||||||||
| "Protocol": "transport-bitswap", | ||||||||||||||
| "Schema": "bitswap", | ||||||||||||||
| "Signature": "<signature>", | ||||||||||||||
| "Payload": "<payload>" | ||||||||||||||
|
||||||||||||||
| "Schema": "bitswap", | |
| "Signature": "<signature>", | |
| "Payload": "<payload>" | |
| "Schema": "bitswap-announce", | |
| "Signature": "<signature>", | |
| "Payload": "<payload>" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is still time. Changing thanks
lidel marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@masih is cid.contact doing verification of this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cid.contact does not support any PUT over http delegated routing.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@masih what is the max length of this list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking is to make the maximum length be derived from whatever the server supports as max request body. A user should be able to find this out via OPTIONS request usually?
If that makes sense I am happy to document this in the spec. Unless you think we need some explicit max length for that array?
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the format? Unix epoch? What resolution (ms? ns?)
Would ASCII string that follows notation from [rfc3339] (1970-01-01T00:00:00.000000001Z) be less ambiguous?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed on following standardized format that is easily human-parseable and doesn't have ambiguity.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a timestamp of a duration? If a duration, is it miliseconds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a duration, maybe get that into the name.
Also embed the units in the parameter name so there is no ambiguity?
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No concerns 👍
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason why we don't include PublicKey field from the start?
If we make it an optional, opaque bytes field, and say it should be deserialized as the protobuf from libp2p peerid specs, we have both solved RSA problem, and don't need to maintain PublicKeyType registry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, we could include PublicKey in the peer schema on out-of-band GET to /routing/v1/peers/{peerid} (IPIP-417).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm okay with either of these paths.
@masih are you okay with this suggestion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to me 👍
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we have to mangle Payload JSON anyway, what is the benefit of introducing it as a new struct?
It was probably discussed before elsewhere, but why can't we use exactly the same protobuf and signature DHT uses?
Reusing DHT record payload would save CPU time on IPFS nodes that publish to both DHT and IPNI (signature would be generated only once, not twice).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is the benefit of introducing it as a new struct?
I suspect the reason for this is better human readability? The beginning of this document (merged as part of IPIP-337 states "human-readable encodings of types are preferred".
save CPU time on IPFS nodes
We can make the same argument about HTTP delegated routing itself. Unless there is evidence to suggest that we should be heavily optimising this, my vote would be to favour human readability.
@guseggert what are your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@guillaumemichel this is related to #345 – can you point us where up-to-date protobufs related to CID announcements on DHT lives these days? Unsure how feasible it is to reuse the announcement's wire format here.
Could we write down and publish the basic wire format information like protobuf section about ipns record, so this IPIP can refer to spec website, and not some go code 🙏
@masih I think Content-Type reuse similar to what we did #379 would help in some cases, but not a silver bullet here. There is way way more CIDs than IPNS records, so some way of doing bulk PUT is still desired, but it should not be tied to a single protocol.
When IPFS node speaks more than bitswap (we already plan to do HTTP next to bitswap in many places), doing a PUT of the same CIDs once for every protocol duplicates the cost on the client.
I don't think there is anything special about Schema: bitswap-announce, having dedicated PUT for this one protocol feels odd, PUT for HTTP will look exactly the same.
Maybe instead of having Schema: bitswap-announce we should have Schema: provider-announce with Protocols list, which could then have both bitswap and HTTP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
having dedicated PUT for this one protocol feels odd, PUT for HTTP will look exactly the same
I agree 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uh oh!
There was an error while loading. Please reload this page.