From d7766a64ae0ce4fbb368dff141707e9db6ee2b69 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 22 Jul 2025 11:26:41 +1000 Subject: [PATCH] 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