logos-messaging/pm
1
0
Fork 0
mirror of https://github.com/logos-messaging/pm.git synced 2026-01-05 23:53:12 +00:00
Code Issues Packages Projects Releases Wiki Activity

Split FURPS in files per feature

Browse Source
This commit is contained in:
fryorcraken 2025-05-23 13:59:27 +10:00
parent c233aad659
commit 65f1921bdd
No known key found for this signature in database
GPG Key ID: A82ED75A8DFC50A4
7 changed files with 168 additions and 117 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

110
FURPS.md
View File

@ -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

14
FURPS/README.md Normal file
View File

@ -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)

26
FURPS/application/p2p_reliability.md Normal file
View File

@ -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

27
FURPS/application/sds.md Normal file
View File

@ -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

32
FURPS/core/light_push.md Normal file
View File

@ -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

39
FURPS/core/store.md Normal file
View File

@ -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.

37
ROADMAP.md
View File

@ -6,9 +6,9 @@ Testing out new format, once approved:
- Milestones are moved to Logos roadmap - Milestones are moved to Logos roadmap
- Deliverables are moved to GitHub issues - 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. 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**: **Deliverables**:
<!--
Once the deliverables are created as GitHub issues, we can delete the content below
and just provide a list of GitHub issue, or even simpler, a link to the GitHub milestone that contain them.
-->
#### Define and Implement Light Push Error codes in nwaku. #### Define and Implement Light Push Error codes in nwaku.
**Owner**: nwaku **Owner**: nwaku
**Feature**: [Light Push](./FURPS.md#light-push) **Feature**: [Light Push](./FURPS/core/light_push.md)
**FURPS**: **FURPS**:
- F4. Supports comprehensive error codes for various failure scenarios. - F4. Supports comprehensive error codes for various failure scenarios.
@ -49,7 +54,7 @@ Includes spec delivery
**Owner**: js-waku **Owner**: js-waku
**Feature**: [Light Push](./FURPS.md#light-push) **Feature**: [Light Push](./FURPS/core/light_push.md)
**FURPS**: **FURPS**:
- F4. Supports comprehensive error codes for various failure scenarios. - F4. Supports comprehensive error codes for various failure scenarios.
@ -69,7 +74,7 @@ Spec delivery not included.
**Owner**: nwaku **Owner**: nwaku
**Feature**: [Store](./FURPS.md#store) **Feature**: [Store](./FURPS/core/store.md)
**FURPS**: **FURPS**:
- F6. Industry practices are applied to PostgreSQL setup to reach appropriate performance - F6. Industry practices are applied to PostgreSQL setup to reach appropriate performance
@ -90,7 +95,7 @@ For
**Owner**: js-waku **Owner**: js-waku
**Feature**: [P2P Reliability](./FURPS.md#p2p-reliability) **Feature**: [P2P Reliability](./FURPS/application/p2p_reliability.md)
**FURPS**: **FURPS**:
- F1. Improves probability of message propagation through redundant publishing and receiving. - F1. Improves probability of message propagation through redundant publishing and receiving.
@ -107,4 +112,22 @@ For
- [ ] Specs: link to specs - [ ] Specs: link to specs
- [ ] Code: link to GitHub issues/PRs/Epic - [ ] Code: link to GitHub issues/PRs/Epic
- [ ] Dogfood: link to dogfooding session/artefact - [ ] Dogfood: link to dogfooding session/artefact
- [ ] Docs: links to README.md or docs.waku.org (TBD) - [ ] 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