IPIP-334: Double-Hashed Find Providers in Reframe #334
Conversation
…to the current method. FindHashedSHA256Request requests content routing records using a derived hash of a CID of interest. This extension to reframe also introduces authenticaled content routing records that can be returned by this method. These records will blind the true peer ID of the provider, and are extended with a signature allowing the requester to validate their authenticity.
| It is constructed by taking the raw bytes of the multihash, prepending the ascii bytes "CR_DOUBLEHASH", and taking the SHA256 hash of that data. | ||
| The resulting digest is then packed itself into a multihash, using the multihash code identifier multihash.DBL_SHA2_256. |
There was a problem hiding this comment.
What is the contingency for replacing SHA256 with other function in the future?
Creating a new message type?
Would it be acceptable renaming these requests to FingHashedProvidersRequest and move hash function multicodec to struct field?
There was a problem hiding this comment.
The current contingency is a new message type.
having it in the request is sub-optimal because it would mean another round of probing for what types of hashes are supported.
changing the hash algorithm will be 'a big deal' and something we don't do often, so using the existing 'identify' layer to identify which one the server supports seems preferable to the client trying other ones and getting told they're not supported.
we expect handlers of FindProviders to support 1 or at most 2 hash algorithms at any given time.
| ``` | ||
|
|
||
| The query is a derived hash of the multihash being requested. | ||
| It is constructed by taking the raw bytes of the multihash, prepending the ascii bytes "CR_DOUBLEHASH", and taking the SHA256 hash of that data. |
There was a problem hiding this comment.
Should support prefix requests, with variable length Queries
| It is constructed by taking the raw bytes of the multihash, prepending the ascii bytes "CR_DOUBLEHASH", and taking the SHA256 hash of that data. | |
| It is constructed by taking the raw bytes of the multihash, prepending the ascii bytes "CR_DOUBLEHASH", and taking a variable length prefix of the SHA256 hash of that data. | |
|
|
||
| ```ipldsch | ||
| type FindHashedSHA256Response struct { | ||
| Providers [Provider] |
There was a problem hiding this comment.
FindHashedSHA256Response should contain a map of Bytes -> Encrypted Provider. A single FindHashedSHA256Request using prefix lookup may return multiple encrypted provider records matching the prefix.
lidel
changed the title
|
Reframe is no more (ipfs/kubo#9479)
|
This PR describes a proposed request/response method for reframe to support "double-hashed" content routing lookups.
cc @guillaumemichel