From f17de354cb9a4642ebfd392e94170fc7f7318fb3 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 16 Jul 2025 10:48:45 +1000 Subject: [PATCH 1/8] Clarifying CC absence --- 2025H2-SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2025H2-SUMMARY.md b/2025H2-SUMMARY.md index 0be4643..0837519 100644 --- a/2025H2-SUMMARY.md +++ b/2025H2-SUMMARY.md @@ -37,7 +37,7 @@ Strategy changes: | [BD - Acquire first 10 customers](draft-roadmap/acquire_first_10_customers.md) | Logos Movement Community Enabling: Growth | 2.1 | 7 | N/A | ✱ Capacity: How many people assigned in a 6 months window. -- 3.5 are applied across all milestones (Franck, Aaron, 1/2 Hanno, Tanya), 1 core research cc is awol. +- 3.5 are applied across all milestones (Franck, Aaron, 1/2 Hanno, Tanya), 1 core research cc was awol for 5 weeks. ## 🧩 Strategic Benefits Realisable from coming Half-Year (Top 5) From 415d81a2658f9fa8509e572e2d86d2614e42e1fa Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 16 Jul 2025 11:00:58 +1000 Subject: [PATCH 2/8] Introduce REQUIREMENTS # Conflicts: # README.md --- FURPS/TEMPLATE.md | 2 +- REQUIREMENTS.md | 40 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 41 insertions(+), 1 deletion(-) create mode 100644 REQUIREMENTS.md diff --git a/FURPS/TEMPLATE.md b/FURPS/TEMPLATE.md index 78ed6f2..4c2a722 100644 --- a/FURPS/TEMPLATE.md +++ b/FURPS/TEMPLATE.md @@ -20,6 +20,6 @@ 1. ... -## + (Privacy, Anonymity, Deployments) +## + (Privacy, Anonymity, Censorship-Resistance, Deployments) 1. ... \ No newline at end of file diff --git a/REQUIREMENTS.md b/REQUIREMENTS.md new file mode 100644 index 0000000..e11b8c7 --- /dev/null +++ b/REQUIREMENTS.md @@ -0,0 +1,40 @@ +# Inbound and Outbound Requirements + +## Flow + +The expected flow (feedback welcome to refine it) is: + +1. Project A writes requirements to B (outbound for A, inbound for A) in FURPS+ format. +2. Project B responds to A's requirements with their own FURPS+ commitments and roadmap, + including an overview of which milestones in B's roadmap cover which requirements of A. + +Note: + +Requirements are negotiable and are state explicitly to enable said negotiation. + +B may not be able to deliver all requirements within a half-year, +a light justification is needed to explain how do we work towards a requirement. +For example: "Building block x, y, z are necessary, and they are being worked on with milestones 1, 2, 3. + +Some requirements may be "rejected" as not considered in scope of B's work, ensuring that further discussion happen +and requirements are adjusted. + +## Inbound to Waku + +### Status + +TODO: Add link here once Status product document + +#### Waku's Response + +TODO: Justify here how Status' requirements are being worked towards to with current roadmap. + +## Outbound from Waku + +### Status + +TODO: list specific areas of concerns and risks + +### Codex + +TODO \ No newline at end of file From 4056be518876e89df0113f9e131a8f2f19b5c4ac Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Wed, 16 Jul 2025 11:40:31 +1000 Subject: [PATCH 3/8] Add outbound requirements for Codex --- REQUIREMENTS.md | 104 +++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 103 insertions(+), 1 deletion(-) diff --git a/REQUIREMENTS.md b/REQUIREMENTS.md index e11b8c7..0fbee98 100644 --- a/REQUIREMENTS.md +++ b/REQUIREMENTS.md @@ -37,4 +37,106 @@ TODO: list specific areas of concerns and risks ### Codex -TODO \ No newline at end of file +#### Publish Large Messages - Uploader is online + +To be used for messages archival in Chat SDK, Qaku, opchan, etc. + +**Functionality** + +1. Ability to transfer a message of 1MB or more between two or more nodes. +2. Message's CID is less than 100kB. + + +**Usability** + +1. Developer can implement upload feature with 10 lines of code or less. +2. No configuration is necessary. + +**Reliability** + +1. Download operation can be resumed. +2. Upload operation can be resumed. +3. Uploader can be expected to be online when user are downloading. + +**Performance** + +None + +**Supportability** + +1. Library for Browser applications. +2. Library for Nim desktop applications. +3. Library for Nim mobile applications. + +**+ (Privacy, Anonymity, Censorship-Resistance, Deployments)** + +1. The unavailability of a static host (IP, DNS) does not prevent a user to upload or download (censorship-resistance). +2. TODO (privacy) + +#### Publish Large Messages - Uploader is offline + +To be used for + +- large messages transfers (such as images, videos, audio) in Chat SDK, Opchan, etc. +- Enhancement of message archival (uploader does not need to be online). + +Builds on [Publish Large Messages - Uploader is online](#publish-large-messages---uploader-is-online) + +**Functionality** + +1. Message is cached to enable retrieval without sender being online (once uploaded). +2. Best effort in terms of message retention; expectations on restrictions are documented. + +**Usability** + +1. Receiver can download the large message, even if sender is offline, as long as they get the CID out-of-band. + +**Reliability** + +1. Uploader may be offline when receiver is retrieving the large message. + +**Performance** + +None + +**Supportability** + +1. Library for Browser applications. +2. Library for Nim applications. + +**+ (Privacy, Anonymity, Censorship-Resistance, Deployments)** + +TODO (privacy) + +#### Publish Large Messages - Retention is guaranteed + +In this scenario, the uploader wants to ensure the data is persisted and is willing to pay for it. +This may be a Qaku Q&A admin, a opchan cell owner or Status Communities owner. + +Builds on previous requirements. + +**Functionality** + +1. Uploader may pay for large message storage to have guaranteed retention. + +**Usability** + +1. Receiver can download the large message, even if sender is offline, as long as they get the CID out-of-band. +2. Receiver does not need to pay to retrieve the large message. + +**Reliability** + +1. Uploader may be offline when receiver is retrieving the large message. +2. Uploader is guaranteed a period of retention for a given price. + +**Performance** + +See previous requirements. + +**Supportability** + +See previous requirements. + +**+ (Privacy, Anonymity, Censorship-Resistance, Deployments)** + +See previous requirements. \ No newline at end of file From e55745bdc23f3586f805912fae513530df0cfd63 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 22 Jul 2025 11:03:39 +1000 Subject: [PATCH 4/8] typo --- REQUIREMENTS.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/REQUIREMENTS.md b/REQUIREMENTS.md index 0fbee98..fc62355 100644 --- a/REQUIREMENTS.md +++ b/REQUIREMENTS.md @@ -4,7 +4,7 @@ The expected flow (feedback welcome to refine it) is: -1. Project A writes requirements to B (outbound for A, inbound for A) in FURPS+ format. +1. Project A writes requirements to B (outbound for A, inbound for B) in FURPS+ format. 2. Project B responds to A's requirements with their own FURPS+ commitments and roadmap, including an overview of which milestones in B's roadmap cover which requirements of A. @@ -139,4 +139,4 @@ See previous requirements. **+ (Privacy, Anonymity, Censorship-Resistance, Deployments)** -See previous requirements. \ No newline at end of file +See previous requirements. From 1b9eb824089528adff0d1f67b3844520de81c2b1 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 22 Jul 2025 11:04:12 +1000 Subject: [PATCH 5/8] grammar --- REQUIREMENTS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/REQUIREMENTS.md b/REQUIREMENTS.md index fc62355..f6dd65b 100644 --- a/REQUIREMENTS.md +++ b/REQUIREMENTS.md @@ -10,7 +10,7 @@ The expected flow (feedback welcome to refine it) is: Note: -Requirements are negotiable and are state explicitly to enable said negotiation. +Requirements are negotiable and are stated explicitly to enable said negotiation. B may not be able to deliver all requirements within a half-year, a light justification is needed to explain how do we work towards a requirement. From 436e03970193dabfa0a4ce97991d8a30dd499545 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 22 Jul 2025 11:08:03 +1000 Subject: [PATCH 6/8] challenging requirements. --- REQUIREMENTS.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/REQUIREMENTS.md b/REQUIREMENTS.md index f6dd65b..d34812c 100644 --- a/REQUIREMENTS.md +++ b/REQUIREMENTS.md @@ -19,6 +19,8 @@ For example: "Building block x, y, z are necessary, and they are being worked on Some requirements may be "rejected" as not considered in scope of B's work, ensuring that further discussion happen and requirements are adjusted. +Finally, B may challenge some requirements, to ensure their are founded, and have been validated by A, through users and community work. + ## Inbound to Waku ### Status From 4d3b470aab3a658bcbb9b8ff30bece0380a31a4e Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 22 Jul 2025 11:22:50 +1000 Subject: [PATCH 7/8] fix README --- README.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/README.md b/README.md index ee12638..d76602a 100644 --- a/README.md +++ b/README.md @@ -2,6 +2,21 @@ *For tracking and project management processes please see* [PROCESS.md](./PROCESS.md) +## Roadmap & Milestones + +High Overview of approved milestones and roadmap can be found in https://roadmap.logos.co/waku/waku-milestones. +Milestones and deliverables can be found in GitHub: https://github.com/waku-org/pm/milestones + +More detailed explanation of proposed roadmap can be found in [draft-roadmap](./draft-roadmap/README.md) + +- Report for 2025H1 in [2025H1-SUMMARY.md](./2025H1-SUMMARY.md) +- Milestone proposal for 2025H2 in [2025H2-SUMMARY.md](./2025H2-SUMMARY.md) + +Outbound requirements, inbound requirements and Waku's response can be found in [REQUIREMENTS.md](./REQUIREMENTS.md) + +We use the FURPS+ framework to specify software and some non-software requirements. +Due to the desired properties of our software, `+` is used to express _privacy_, _anonymity_, _censorship-resistance_ and _deployments_ requirements. + ## Weekly Reporting Weekly reporting provides an insight on the progress by Milestones. Updates are published to https://roadmap.logos.co/tags/waku-updates. From d7766a64ae0ce4fbb368dff141707e9db6ee2b69 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 22 Jul 2025 11:26:41 +1000 Subject: [PATCH 8/8] split file, and keep Codex for follow-up PR --- README.md | 2 +- REQUIREMENTS.md | 144 ----------------------------------------- requirements/README.md | 37 +++++++++++ requirements/codex.md | 3 + requirements/status.md | 3 + 5 files changed, 44 insertions(+), 145 deletions(-) delete mode 100644 REQUIREMENTS.md create mode 100644 requirements/README.md create mode 100644 requirements/codex.md create mode 100644 requirements/status.md diff --git a/README.md b/README.md index d76602a..6c4ed63 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,7 @@ More detailed explanation of proposed roadmap can be found in [draft-roadmap](./ - Report for 2025H1 in [2025H1-SUMMARY.md](./2025H1-SUMMARY.md) - Milestone proposal for 2025H2 in [2025H2-SUMMARY.md](./2025H2-SUMMARY.md) -Outbound requirements, inbound requirements and Waku's response can be found in [REQUIREMENTS.md](./REQUIREMENTS.md) +Outbound requirements, inbound requirements and Waku's response can be found in [REQUIREMENTS.md](requirements/README.md) We use the FURPS+ framework to specify software and some non-software requirements. Due to the desired properties of our software, `+` is used to express _privacy_, _anonymity_, _censorship-resistance_ and _deployments_ requirements. diff --git a/REQUIREMENTS.md b/REQUIREMENTS.md deleted file mode 100644 index d34812c..0000000 --- a/REQUIREMENTS.md +++ /dev/null @@ -1,144 +0,0 @@ -# Inbound and Outbound Requirements - -## Flow - -The expected flow (feedback welcome to refine it) is: - -1. Project A writes requirements to B (outbound for A, inbound for B) in FURPS+ format. -2. Project B responds to A's requirements with their own FURPS+ commitments and roadmap, - including an overview of which milestones in B's roadmap cover which requirements of A. - -Note: - -Requirements are negotiable and are stated explicitly to enable said negotiation. - -B may not be able to deliver all requirements within a half-year, -a light justification is needed to explain how do we work towards a requirement. -For example: "Building block x, y, z are necessary, and they are being worked on with milestones 1, 2, 3. - -Some requirements may be "rejected" as not considered in scope of B's work, ensuring that further discussion happen -and requirements are adjusted. - -Finally, B may challenge some requirements, to ensure their are founded, and have been validated by A, through users and community work. - -## Inbound to Waku - -### Status - -TODO: Add link here once Status product document - -#### Waku's Response - -TODO: Justify here how Status' requirements are being worked towards to with current roadmap. - -## Outbound from Waku - -### Status - -TODO: list specific areas of concerns and risks - -### Codex - -#### Publish Large Messages - Uploader is online - -To be used for messages archival in Chat SDK, Qaku, opchan, etc. - -**Functionality** - -1. Ability to transfer a message of 1MB or more between two or more nodes. -2. Message's CID is less than 100kB. - - -**Usability** - -1. Developer can implement upload feature with 10 lines of code or less. -2. No configuration is necessary. - -**Reliability** - -1. Download operation can be resumed. -2. Upload operation can be resumed. -3. Uploader can be expected to be online when user are downloading. - -**Performance** - -None - -**Supportability** - -1. Library for Browser applications. -2. Library for Nim desktop applications. -3. Library for Nim mobile applications. - -**+ (Privacy, Anonymity, Censorship-Resistance, Deployments)** - -1. The unavailability of a static host (IP, DNS) does not prevent a user to upload or download (censorship-resistance). -2. TODO (privacy) - -#### Publish Large Messages - Uploader is offline - -To be used for - -- large messages transfers (such as images, videos, audio) in Chat SDK, Opchan, etc. -- Enhancement of message archival (uploader does not need to be online). - -Builds on [Publish Large Messages - Uploader is online](#publish-large-messages---uploader-is-online) - -**Functionality** - -1. Message is cached to enable retrieval without sender being online (once uploaded). -2. Best effort in terms of message retention; expectations on restrictions are documented. - -**Usability** - -1. Receiver can download the large message, even if sender is offline, as long as they get the CID out-of-band. - -**Reliability** - -1. Uploader may be offline when receiver is retrieving the large message. - -**Performance** - -None - -**Supportability** - -1. Library for Browser applications. -2. Library for Nim applications. - -**+ (Privacy, Anonymity, Censorship-Resistance, Deployments)** - -TODO (privacy) - -#### Publish Large Messages - Retention is guaranteed - -In this scenario, the uploader wants to ensure the data is persisted and is willing to pay for it. -This may be a Qaku Q&A admin, a opchan cell owner or Status Communities owner. - -Builds on previous requirements. - -**Functionality** - -1. Uploader may pay for large message storage to have guaranteed retention. - -**Usability** - -1. Receiver can download the large message, even if sender is offline, as long as they get the CID out-of-band. -2. Receiver does not need to pay to retrieve the large message. - -**Reliability** - -1. Uploader may be offline when receiver is retrieving the large message. -2. Uploader is guaranteed a period of retention for a given price. - -**Performance** - -See previous requirements. - -**Supportability** - -See previous requirements. - -**+ (Privacy, Anonymity, Censorship-Resistance, Deployments)** - -See previous requirements. diff --git a/requirements/README.md b/requirements/README.md new file mode 100644 index 0000000..4ec42d0 --- /dev/null +++ b/requirements/README.md @@ -0,0 +1,37 @@ +# Inbound and Outbound Requirements + +## Flow + +The expected flow (feedback welcome to refine it) is: + +1. Project A writes requirements to B (outbound for A, inbound for B) in FURPS+ format. +2. Project B responds to A's requirements with their own FURPS+ commitments and roadmap, + including an overview of which milestones in B's roadmap cover which requirements of A. + +Note: + +Requirements are negotiable and are stated explicitly to enable said negotiation. + +B may not be able to deliver all requirements within a half-year, +a light justification is needed to explain how do we work towards a requirement. +For example: "Building block x, y, z are necessary, and they are being worked on with milestones 1, 2, 3. + +Some requirements may be "rejected" as not considered in scope of B's work, ensuring that further discussion happen +and requirements are adjusted. + +Finally, B may challenge some requirements, to ensure their are founded, and have been validated by A, through users and community work. + +## Inbound to Waku + +### Status + +TODO: Add link here once Status product document + +#### Waku's Response + +TODO: Justify here how Status' requirements are being worked towards to with current roadmap. + +## Outbound from Waku + +- [Status](./status.md) +- [Codex](./codex.md) diff --git a/requirements/codex.md b/requirements/codex.md new file mode 100644 index 0000000..2fdb0de --- /dev/null +++ b/requirements/codex.md @@ -0,0 +1,3 @@ +# Waku's requirements on Codex + +TODO \ No newline at end of file diff --git a/requirements/status.md b/requirements/status.md new file mode 100644 index 0000000..c3eef5c --- /dev/null +++ b/requirements/status.md @@ -0,0 +1,3 @@ +# Waku's requirements on Status + +TODO: list specific areas of concerns and risks \ No newline at end of file