review comments

Author: jazzz

standards/application/privatev1.md

@@ -9,7 +9,7 @@ contributors:
 
 # Abstract
 
-This specification defines PRIVATE1, a conversation protocol for establishing secure, full-duplex encrypted communication channels between two participants. PRIVATE1 provides end-to-end encryption with forward secrecy and post-compromise security using the DoubleRatchet algorithm, combined with reliable message delivery via Scalable Data Sync (SDS) and efficient segmentation for transport-constrained environments.
+This specification defines PRIVATE1, a conversation protocol for establishing secure, full-duplex encrypted communication channels between two participants. PRIVATE1 provides end-to-end encryption with forward secrecy and post-compromise security using the Double Ratchet algorithm, combined with reliable message delivery via Scalable Data Sync (SDS) and efficient segmentation for transport-constrained environments.
 
 The protocol is transport-agnostic and designed to support both direct messaging and as a foundation for group communication systems. PRIVATE1 ensures payload confidentiality, content integrity, sender privacy, and message reliability while remaining resilient to network disruptions and message reordering.
 
@@ -24,7 +24,7 @@ However, being encrypted is merely the starting point, not the complete solution
 
 # Private V1
 
-PrivateV1 is a conversation type specification that establishes a full-duplex secure communication channel between two participants. It combines the Double Ratchet algorithm for encryption with Scalable Data Sync (SDS) for reliable delivery and an efficient segmentation strategy to handle transport constraints. 
+PRIVATE1 is a conversation type specification that establishes a full-duplex secure communication channel between two participants. It combines the Double Ratchet algorithm for encryption with Scalable Data Sync (SDS) for reliable delivery and an efficient segmentation strategy to handle transport constraints. 
 
 PRIVATE1 provides the following properties:
 
@@ -56,7 +56,7 @@ It also assumes that some other component is responsible for delivering the gene
 
 ```mermaid
 flowchart LR
-    Content:::plain--> Privatev1 --> Payload:::plain
+    Content:::plain--> PrivateV1 --> Payload:::plain
     classDef plain fill:none,stroke:transparent;
 ```
 ### Content
@@ -68,9 +68,9 @@ Applications provide content as encoded bytes, which is then packaged into paylo
 Content MUST be smaller than `255 * max_seg_size`
 due to segmentation protocol limitations.
 
-**Agnostic**
+**Structure**
 
-The protocol treats the contents as a arbitrary sequence of bytes and is agnostic to its contents.
+The protocol treats the contents as an arbitrary sequence of bytes and is agnostic to its contents.
 
 ### Payload Delivery
 How payloads are sent and received by clients is deliberately not specified by this protocol.
@@ -81,7 +81,7 @@ Confidentiality, integrity, and forward secrecy are provided regardless of how p
 However, transport choice may affect other properties and characteristics.
 
 **Recipient Privacy:** 
-The routing/addressing layer may leak sensitive metadata including the recipients identity. The payloads generated by this protocol do not reveal the participants of a conversation, however the overall privacy properties are determined by the delivery mechanism used to transport payloads. 
+The routing/addressing layer may leak sensitive metadata including the recipient's identity. The payloads generated by this protocol do not reveal the participants of a conversation, however the overall privacy properties are determined by the delivery mechanism used to transport payloads. 
 
 **Reliability Performance**
 While PRIVATE1 handles message losses, more reliable transports reduce retransmission overhead. 
@@ -106,7 +106,7 @@ PRIVATE1 requires a unique identifier, however the exact derivation is left to i
 
 Additionally implementations MUST determine the following constants:
 - `max_seg_size` - maximum segmentation size to be used.
-- `max_skip` - number of keys which can be skipped per session. Values are determined by 
+- `max_skip` - number of keys which can be skipped per session.
 
 ## Value Derivations
 
@@ -196,7 +196,7 @@ The following mappings connect PRIVATE1 concepts to SDS fields:
 - `channel_id`: uses the `conversation_id` parameter.
 
 **Sender Validation**
-SDS uses a `sender_id` payload field to determine whether a message was sent by the remote party. This value is sender reported and not validated which can have unknown implications if trusted in other contexts. For security hygiene Clients SHOULD drop SDS messages if `sender_id` != the sender derived from the encryption layer. !TODO: PrivateV1 is not sender aware currently
+SDS uses a `sender_id` payload field to determine whether a message was sent by the remote party. This value is sender reported and not validated which can have unknown implications if trusted in other contexts. For security hygiene Clients SHOULD drop SDS messages if `sender_id` != the sender derived from the encryption layer. !TODO: PRIVATE1 is not sender aware currently
 
 **Bloom Filter Configuration**
 
@@ -291,7 +291,7 @@ flowchart TD
 
 ### Encrypted Payload
 ```protobuf
-message Doubleratchet {
+message DoubleRatchet {
     bytes dh = 1;               // 32 byte publickey
     uint32 msgNum = 2;          
     uint32 prevChainLen = 3;     
@@ -322,7 +322,7 @@ message Message {
 }
 ```
 
-**content:** This field is an protobuf encoded `Segment`
+**content:** This field is a protobuf encoded `Segment`
 
 ### Segmentation 
 
@@ -345,7 +345,7 @@ message SegmentMessageProto {
 
 !TODO: This should be encoded as a FrameType so it can be optional.
 
-### Frame
+### PrivateV1Frame
 
 ```protobuf
 message PrivateV1Frame {                 
@@ -377,15 +377,15 @@ This means that senders SHOULD generate a new ephemeral key for `ssk` for every
 ### Excessive Skipped Message 
 
 Handling of skipped message keys is not strictly defined in double ratchet. 
-Implementations need to choose an strategy which works best for their environment, and delivery mechanism. 
+Implementations need to choose a strategy which works best for their environment, and delivery mechanism. 
 Halting operation of the channel is the safest, as it bounds resource utilization in the event of a DOS attack but is not always possible.  
 
 If eventual delivery of messages is not guaranteed, implementors should regularly delete keys that are older than a given time window. 
 Unreliable delivery mechanisms will result in increased key storage over time, as more messages are lost with no hope of delivery. 
 
 ## Security/Privacy Considerations
 
-### Sender Deniability and Authentication**
+### Sender Deniability and Authentication
 
 Encrypted messages do not have a cryptographically provable sender to third parties due to the deniability property of the Double Ratchet algorithm.
 However, participants in a conversation can authenticate each other through the shared cryptographic state.
@@ -400,3 +400,18 @@ Without proper authentication during initialization, an adversary could perform
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
 
 
+## References
+- **[DOUBLERATCHET]** "The Double Ratchet Algorithm", Signal, 2016.
+  https://signal.org/docs/specifications/doubleratchet/
+
+- **[SDS]** "Scalable Data Sync Specification", vac, 2024.
+  https://github.com/vacp2p/rfc-index/blob/main/vac/raw/sds.md
+
+- **[SEGMENTATION]** "Message Segmentation Specification", Waku, 2024.
+  https://github.com/waku-org/specs/blob/main/standards/application/segmentation.md
+
+- **[CONTENTFRAME]** "ContentFrame Specification", Waku, 2024.
+  https://github.com/waku-org/specs/blob/main/standards/application/contentframe.md
+
+- **[CHAT-DEFINITIONS]** "Chat Definitions Specification", Waku, 2024.
+  https://github.com/waku-org/specs/blob/main/informational/chatdefs.md