-
Notifications
You must be signed in to change notification settings - Fork 232
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
IPIP-417: Delegated Peer Routing HTTP API #417
Conversation
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.
@hacdias I had to rebase this one to be based on the latest versions of the other two, apologies for the noise.
b12388d
to
9790174
Compare
IMO it would be great to have delegated peer routing use signed peer records. It seems essential because without signatures you have to trust a middleman. A simple "Signature" field could be added to the proposed schema. The signature can be the array of bytes resulting of the signature using the private key associated with the peer ID (and corresponding algorithm) of (all) the other (non-empty) fields of the schema. |
@guillaumemichel I like the idea, but that'd require deeper changes to the way we implement things. Currently, the idea was to mostly "relay" the results of All in all, we have to find the balance. For IPNS (#379), it is easy to send signed records, because that's literally what is passed around. Here it seems it'd be more complicated. |
25d51dc
to
e66a70a
Compare
src/routing/http-routing-v1.md
Outdated
#### Response Body | ||
|
||
A [`peer` schema record](#peer). |
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.
Open Question: should the response body for /routing/v1/peers
be a single entity? What we want to obtain is the addresses of the peer. But addresses can end up being discovered on the fly. Supporting streaming is reasonably easy and could be part of the spec.
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.
Should be multiple, and work the same as /providers
– we may have more than one result for the same peerid coming from different backend services (e.g. if /routing/v1
queries both DHT and IPNI)
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 offers both: /providers
returns list of all providers and /providers/<peer-id>
returns a specific one.
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.
e66a70a
to
4ee487a
Compare
FYSA we've got implementation in
|
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.
Applied final editorials, and included legacy schemas with guidance to parse them the same way as peer
one (to leverage presence of ID
and Addrs
fields). This is what boxo
does for Schema: bitswap
entries.
This is ready for final reviews and ratification, will discuss during IPFS Implementers call today
@lidel : are we good to merge now? |
Co-authored-by: Marcin Rataj <[email protected]>
Co-authored-by: Masih H. Derkani <[email protected]>
we will have legacy schemas in the wild for a while, added a note that clients may parse them the same way as peer one (both have ID and Addrs)
34dbaba
to
95999ef
Compare
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.
This has been waiting for ratification feedback for a few weeks now, and no concerns were raised.
Thank you @hacdias for landing this.
For anyone reading this in the future:
- Self-hosting /routing/v1 endpoint for delegated routing needs will ship in Kubo 0.23
This IPIP introduces the
/routing/v1/peers
endpoint to the Routing HTTP V1 API for peer routing support.