logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-03 22:53:11 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update store.md

Browse Source
This commit is contained in:
Jimmy Debe 2025-01-02 01:05:30 -05:00 committed by GitHub
parent 2f9e7c1d2a
commit 409e1faf58
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 9 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
standards/core/store.md
View File

@ -19,11 +19,6 @@ It also supports pagination for more efficient querying of historical messages.
**Protocol identifier***: `/vac/waku/store-query/3.0.0` **Protocol identifier***: `/vac/waku/store-query/3.0.0`
# Wire Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as described in [RFC2119](https://www.ietf.org/rfc/rfc2119.txt).
### Terminology ### Terminology
The term PII, Personally Identifiable Information, The term PII, Personally Identifiable Information,
@ -31,6 +26,11 @@ refers to any piece of data that can be used to uniquely identify a user.
For example, the signature verification key, and For example, the signature verification key, and
the hash of one's static IP address are unique for each user and hence count as PII. the hash of one's static IP address are unique for each user and hence count as PII.
# Wire Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as described in [RFC2119](https://www.ietf.org/rfc/rfc2119.txt).
### Design Requirements ### Design Requirements
Nodes willing to provide the storage service using `WAKU2-STORE` protocol, Nodes willing to provide the storage service using `WAKU2-STORE` protocol,
@ -236,7 +236,8 @@ the store query client MUST populate the `message_hashes` field in the `StoreQue
for which it wants to verify presence in the store service node. for which it wants to verify presence in the store service node.
The `include_data` property MUST be set to `false`. The `include_data` property MUST be set to `false`.
The client SHOULD interpret every `message_hash` returned in the `messages` field of the `StoreQueryResponse` as present in the store. The client SHOULD interpret every `message_hash` returned in the `messages` field of the `StoreQueryResponse` as present in the store.
The client SHOULD assume that all other message hashes included in the original `StoreQueryRequest` but not in the `StoreQueryResponse` is not present in the store. The client SHOULD assume that all other message hashes included in the original `StoreQueryRequest` but
not in the `StoreQueryResponse` is not present in the store.
### Pagination info ### Pagination info
@ -347,7 +348,8 @@ In response to a _backward_ `StoreQueryRequest`:
# Security Consideration # Security Consideration
The main security consideration to take into account while using this protocol is that a querying node have to reveal their content filters of interest to the queried node, hence potentially compromising their privacy. The main security consideration while using this protocol is that a querying node has to reveal its content filters of interest to the queried node,
hence potentially compromising their privacy.
## Adversarial Model ## Adversarial Model