diff --git a/FURPS.md b/FURPS.md deleted file mode 100644 index f1989bd..0000000 --- a/FURPS.md +++ /dev/null @@ -1,110 +0,0 @@ -# Waku FURPS - -- 🏗️: New planned property, yet to be delivered. -- (Vac-DST): Simulations to verify this property -- (Vac-QA): Additional test coverage by Vac-QA to verify this property - -## Core Protocols - -### Light Push - -#### Functionality - -1. Enables light nodes to push messages to service nodes for relay to the network. -2. Requests service nodes to publish messages to WAKU2-RELAY pubsub-topics. -3. Provides confirmation that a message has been received by at least one node. -4. 🏗️ Supports comprehensive error codes for various failure scenarios. - -#### Usability - -1. Implements simple async request/response pattern. -2. Uses standard Waku Message format. -3. Only requires an established libp2p connection. -4. 🏗️ Provides descriptive error messages in responses. - -#### Reliability - -1. Implements retransmission on failure with exponential backoff. -2. Implements DoS protection through request rate limitation. -3. 🏗️ Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure). -4. 🏗️ 80% message transmission success rate on live Status network (service node from both Status Desktop and fleet Waku instances) - -#### Performance - -1. Only one network round trip is required for operation; including both configuration and message transmission. -2. Minimizes protocol overhead for efficient resource usage. - -#### Supportability - -1. Linux amd64 CLI as service node -2. Browser as client - -### Store - -#### Functionality - -1. Provides historical message retrieval from the Waku network, enabling nodes to query for messages they missed while offline. -2. Supports multiple query types: time-based, content-topic filtered, and message hash lookups. -3. Enables message presence verification without retrieving full message content. -4. Supports pagination for efficient retrieval of large message sets, and resuming retrieval after disconnection. -5. Supports comprehensive error codes for various failure scenarios. -6. 🏗️ Industry practices are applied to PostgreSQL setup to reach appropriate performance - -### Usability - -1. Implements simple async request/response pattern. -2. Uses standard Waku Message format. -3. Only requires an established libp2p connection. -4. Provides descriptive error messages in responses. -5. Supports query filtering to retrieve only relevant messages by content topic. - -#### Reliability - -1. Implements DoS protection through request rate limitation. -2. (limitation) No guarantees in terms of message presence or retention duration. -3. Store node always provide a response; thanks to DoS protection. - -#### Performance - -1. Only one network round trip is required for operation; including both configuration and message retrieval. -2. Implements pagination to manage resource usage on both client and server. -3. Allows presence queries to verify message existence without transferring full content. -4. Targets query response times under 2 seconds for typical requests. -5. 🏗️ Hash query of less than 10 hashes are served under 400ms; for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**. -6. 🏗️ Time range queries of less than 24 hours, with less than 10 content topics, are served under 400 ms; for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**. - -#### Supportability - -1. Linux amd64 CLI as service node -2. PostgreSQL as database engine. -3. Browser support as client. - -## Application Protocols - -### P2P Reliability - -#### Functionality - -1. Improves probability of message propagation through redundant publishing and receiving. -2. Enables detection and remedy of message losses between peers using Store or Filter based reliability strategies. -3. Enhances Lightpush reliability through service node pooling, redundant publishing, and failure detection. -4. Improves Filter reliability through redundant subscriptions and subscription health monitoring. - -#### Usability - -1. Provides feedback on message delivery status leveraging store protocol. -2. Automatically handles reconnection and retransmission when failures are detected. - -#### Reliability - -TBD - -#### Performance - -TBD - -#### Supportability - -1. 🏗️ Within browser environments (edge node mode) -2. Integrated in Status applications - diff --git a/FURPS/README.md b/FURPS/README.md new file mode 100644 index 0000000..eeadca9 --- /dev/null +++ b/FURPS/README.md @@ -0,0 +1,14 @@ +# Waku FURPS + +- (Vac-DST): Simulations to verify this property +- (Vac-QA): Additional test coverage by Vac-QA to verify this property + +## Core Protocols + +- [Light Push](./core/light_push.md) +- [Store](./core/store.md) + +## Application Protocols + +- [P2P Reliability](./application/p2p_reliability.md) +- [Scalable Data Sync](./application/sds.md) \ No newline at end of file diff --git a/FURPS/application/p2p_reliability.md b/FURPS/application/p2p_reliability.md new file mode 100644 index 0000000..c48093a --- /dev/null +++ b/FURPS/application/p2p_reliability.md @@ -0,0 +1,26 @@ +# P2P Reliability + +## Functionality + +1. Improves probability of message propagation through redundant publishing and receiving. +2. Enables detection and remedy of message losses between peers using Store or Filter based reliability strategies. +3. Enhances Lightpush reliability through service node pooling, redundant publishing, and failure detection. +4. Improves Filter reliability through redundant subscriptions and subscription health monitoring. + +## Usability + +1. Provides feedback on message delivery status leveraging store protocol. +2. Automatically handles reconnection and retransmission when failures are detected. + +## Reliability + +TBD + +## Performance + +TBD + +## Supportability + +1. Within browser environments (edge node mode) +2. Integrated in Status applications \ No newline at end of file diff --git a/FURPS/application/sds.md b/FURPS/application/sds.md new file mode 100644 index 0000000..76d6d2f --- /dev/null +++ b/FURPS/application/sds.md @@ -0,0 +1,27 @@ +# Scalable Data Sync + +## Functionality + +1. 🏗️ Ability to know that a published message has been received by at least one member of the group (and could therefore eventually be retrieved by other members). +2. 🏗️ Ability for participants to know when they have missed a message, and to retrieve them using Waku store protocol + +## Usability + +1. 🏗️ When sending a message to a large group, the application knows whether it was received by other group members, with high probability +2. 🏗️ When being part of a large group, the application is able to know whether they are missing messages, and is able to retrieve missed messages + +## Reliability + +1. 🏗️ When sending a message in a group, the publisher can ascertain the message was received by at least one recipient **(Vac-QA)** +2. 🏗️ When receiving messages in a group, the receiver can ascertain most missed messages by receiving one recent message from the group. **(Vac-QA)** + +## Performance + +Assuming messages in a group are sent at least every `S` seconds. + +1. 🏗️ When sending a message in a group, the publisher can ensure the message was received by at least one recipient within`S` seconds **(Vac-DST)** +2. 🏗️ When receiving messages in a group, the receiver can detect 90% of missed messages within `3*S` seconds, and reach eventual consistency within `6*S` seconds **(Vac-DST)** + +## Supportability + +1. 🏗️ Applied to Communities channels only, both Status Mobile and Desktop diff --git a/FURPS/core/light_push.md b/FURPS/core/light_push.md new file mode 100644 index 0000000..7f695ef --- /dev/null +++ b/FURPS/core/light_push.md @@ -0,0 +1,32 @@ +# Light Push FURPS + +## Functionality + +1. Enables light nodes to push messages to service nodes for relay to the network. +2. Requests service nodes to publish messages to WAKU2-RELAY pubsub-topics. +3. Provides confirmation that a message has been received by at least one node. +4. Supports comprehensive error codes for various failure scenarios. + +## Usability + +1. Implements simple async request/response pattern. +2. Uses standard Waku Message format. +3. Only requires an established libp2p connection. +4. Provides descriptive error messages in responses. + +## Reliability + +1. Implements retransmission on failure with exponential backoff. +2. Implements DoS protection through request rate limitation. +3. Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure). +4. 80% message transmission success rate on live Status network (service node from both Status Desktop and fleet Waku instances) + +## Performance + +1. Only one network round trip is required for operation; including both configuration and message transmission. +2. Minimizes protocol overhead for efficient resource usage. + +## Supportability + +1. Linux amd64 CLI as service node +2. Browser as client \ No newline at end of file diff --git a/FURPS/core/store.md b/FURPS/core/store.md new file mode 100644 index 0000000..b232584 --- /dev/null +++ b/FURPS/core/store.md @@ -0,0 +1,39 @@ +# Store + +## Functionality + +1. Provides historical message retrieval from the Waku network, enabling nodes to query for messages they missed while offline. +2. Supports multiple query types: time-based, content-topic filtered, and message hash lookups. +3. Enables message presence verification without retrieving full message content. +4. Supports pagination for efficient retrieval of large message sets, and resuming retrieval after disconnection. +5. Supports comprehensive error codes for various failure scenarios. +6. Industry practices are applied to PostgreSQL setup to reach appropriate performance + +## Usability + +1. Implements simple async request/response pattern. +2. Uses standard Waku Message format. +3. Only requires an established libp2p connection. +4. Provides descriptive error messages in responses. +5. Supports query filtering to retrieve only relevant messages by content topic. + +## Reliability + +1. Implements DoS protection through request rate limitation. +2. (limitation) No guarantees in terms of message presence or retention duration. +3. Store node always provide a response; thanks to DoS protection. + +## Performance + +1. Only one network round trip is required for operation; including both configuration and message retrieval. +2. Implements pagination to manage resource usage on both client and server. +3. Allows presence queries to verify message existence without transferring full content. +4. Targets query response times under 2 seconds for typical requests. +5. Hash query of less than 10 hashes are served under 400ms; for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**. +6. Time range queries of less than 24 hours, with less than 10 content topics, are served under 400 ms; for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**. + +## Supportability + +1. Linux amd64 CLI as service node +2. PostgreSQL as database engine. +3. Browser support as client. \ No newline at end of file diff --git a/ROADMAP.md b/ROADMAP.md index 21054c1..1b9b695 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -6,9 +6,9 @@ Testing out new format, once approved: - Milestones are moved to Logos roadmap - Deliverables are moved to GitHub issues -- Waku FURPS remains in [FURPS](./FURPS.md) +- Waku FURPS remains in [FURPS](./FURPS/README.md) -### Peer-To-Peer Reliability +### Define and Implement Peer-To-Peer Reliability Strategies Last remains of *Direct Message Reliability* milestone. @@ -24,11 +24,16 @@ Limited effort will be spent on store performance as its relevance is expected t **Deliverables**: + + #### Define and Implement Light Push Error codes in nwaku. **Owner**: nwaku -**Feature**: [Light Push](./FURPS.md#light-push) +**Feature**: [Light Push](./FURPS/core/light_push.md) **FURPS**: - F4. Supports comprehensive error codes for various failure scenarios. @@ -49,7 +54,7 @@ Includes spec delivery **Owner**: js-waku -**Feature**: [Light Push](./FURPS.md#light-push) +**Feature**: [Light Push](./FURPS/core/light_push.md) **FURPS**: - F4. Supports comprehensive error codes for various failure scenarios. @@ -69,7 +74,7 @@ Spec delivery not included. **Owner**: nwaku -**Feature**: [Store](./FURPS.md#store) +**Feature**: [Store](./FURPS/core/store.md) **FURPS**: - F6. Industry practices are applied to PostgreSQL setup to reach appropriate performance @@ -90,7 +95,7 @@ For **Owner**: js-waku -**Feature**: [P2P Reliability](./FURPS.md#p2p-reliability) +**Feature**: [P2P Reliability](./FURPS/application/p2p_reliability.md) **FURPS**: - F1. Improves probability of message propagation through redundant publishing and receiving. @@ -107,4 +112,22 @@ For - [ ] Specs: link to specs - [ ] Code: link to GitHub issues/PRs/Epic - [ ] Dogfood: link to dogfooding session/artefact -- [ ] Docs: links to README.md or docs.waku.org (TBD) \ No newline at end of file +- [ ] Docs: links to README.md or docs.waku.org (TBD) + +### Introduce E2E Reliability in Status Communities and Web Apps + +To solve reliability is to solve two problems: + +1. High heuristic that messages are received and sent +2. Ability to know whether messages are received or sent + +Problem (1) can never be 100% reliable in a network environment. The previous milestones focused on it. +To solve (2), is to create an end-to-end protocol, sender to recipient, that enables the ability to know whether recipient(s) have received messages. + +With this milestone, we design and deliver a first PoC for an end-to-end reliability protocol. +This protocol will be specified and implemented in the Status app for Status Communities chat rooms; +as well as in the browser for PoC Web Apps such as Qaku and Logos Forum. + +**deliverables**: + +TBD \ No newline at end of file