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.

Sign up for GitHub

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

Jump to bottom

IPIP-334: Double-Hashed Find Providers in Reframe #334

Closed
wants to merge 2 commits into from
Closed

IPIP-334: Double-Hashed Find Providers in Reframe #334

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e319c47
Describe the double-hashed FindProviders reframe request in parallel …
willscott Oct 15, 2022
9db3357
further detail into construction of the derived query
willscott Oct 15, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions reframe/REFRAME_KNOWN_METHODS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,7 @@ This document is defining known methods (request-response message types) and sem
- [Identify DAG-JSON Examples](#identify-dag-json-examples)
- [FindProviders](#findproviders)
- [FindProviders DAG-JSON Examples](#findproviders-dag-json-examples)
- [FindProvidersBlinded](#findproviders-blinded)
- [GetIPNS](#getipns)
- [GetIPNS DAG-JSON Examples](#getipns-dag-json-examples)
- [PutIPNS](#putipns)
Expand All @@ -39,6 +40,7 @@ The known Request types are the following and are described below:
type Request union {
| "IdentifyRequest" IdentifyRequest
| "FindProvidersRequest" FindProvidersRequest
| "FindHashedSHA256Request" FindHashedSHA256Request
| "GetIPNSRequest" GetIPNSRequest
| "PutIPNSRequest" PutIPNSRequest
| "ProvideRequest" ProvideRequest
Expand All @@ -51,6 +53,7 @@ The known Response types are the following and are described below:
type Response union {
| "IdentifyResponse" IdentifyResponse
| "FindProvidersResponse" FindProvidersResponse
| "FindHashedSHA256Response" FindHashedSHA256Response
| "GetIPNSResponse" GetIPNSResponse
| "PutIPNSResponse" PutIPNSResponse
| "ProvideResponse" ProvideResponse
Expand All @@ -69,6 +72,7 @@ The following methods (request-response pairs) are _cachable_:
type CachableRequest union {
| "IdentifyRequest" IdentifyRequest
| "FindProvidersRequest" FindProvidersRequest
| "FindHashedSHA256Request" FindHashedSHA256Request
| "GetIPNSRequest" GetIPNSRequest
}
```
Expand Down Expand Up @@ -145,6 +149,7 @@ Note: While the Key is a CID it is highly recommended that server implementation
# We expect different types of nodes, e.g. peer, miner, public IP, etc.
type Node union {
| Peer "peer"
| AuthenticatedPeer "apeer" # This type will be returned in blinded queries
| Any default
} representation keyed

Expand Down Expand Up @@ -203,6 +208,39 @@ Response:
}}
```

### FindProviders Blinded

A message for finding nodes with interest in a given key using double hashing to blind the key being requested.

```ipldsch
type FindHashedSHA256Request struct {
Query Bytes
}
```

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should support prefix requests, with variable length Queries

Suggested change
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.

The resulting digest is then packed itself into a multihash, using the multihash code identifier multihash.DBL_SHA2_256.
Comment on lines +222 to +223
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 full semantics of double hashing in the context of content routing are described at https://www.notion.so/protocollabs/IPFS-Double-Hashing-Repurpose-8fdaae8748414ae592a5d24d59c0d8ed
lidel marked this conversation as resolved.
Show resolved Hide resolved

```ipldsch
type FindHashedSHA256Response struct {
Providers [Provider]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FindHashedSHA256Response should contain a map of Bytes -> Encrypted Provider. A single FindHashedSHA256Request using prefix lookup may return multiple encrypted provider records matching the prefix.

}

type AuthenticatedPeer struct {
// ID is included in this superset of 'Peer'
ID Bytes // Enc_{MH}(PeerID || 0[32bytes])
// Multiaddresses may be set as a hint if the server knows the publisher.
Multiaddresses optional [Bytes]

Signature Bytes // signature of ID field by the publisher's PeerID.
}
}
```


### GetIPNS

A message for finding the latest IPNS records for a given identifier.
Expand Down