docs(waku): adds furps for communities over Waku #18485
Conversation
jrainville
requested review from
iurimatias and
fryorcraken
and removed request for
a team
Jenkins BuildsClick to see older builds (27)
|
docs/FURPS/communities-over-waku.md
Outdated
| - **Control node**: the sole authority for publishing official community description changes. | ||
| - **Token masters**: same rights as owners except cannot manage other token masters. | ||
| - **Admins**: same rights as token masters, except cannot deploy/mint/burn tokens. | ||
| - Messages must be available on Waku **store nodes** for **at least 30 days**. |
There was a problem hiding this comment.
Is Store nodes here a hard requirement?
Or is the requirement that messages are queued for 30 days?
There was a problem hiding this comment.
As per my other comments, I would move away from requirements that are imposed on specific tech, and instead, more functional requirements of the final product:
- A user who was offline must eventually be able to retrieve all messages of the community, as long as they were offline for less than 30 days.
- A user that was offline less than one week must be able to retrieve all missed messages within 5 minutes
- A user that was offline for more than one week, and less than 30 days, must be able to retrieve all missed messages within 30 minutes
docs/FURPS/communities-over-waku.md
Outdated
| - Waku must ensure **delivery of messages to subscribed peers**, even under: | ||
| - Temporary disconnections | ||
| - Slow or lossy networks | ||
| - Waku store nodes must reliably store messages for **30 days**, and make them retrievable on demand. |
docs/FURPS/communities-over-waku.md
Outdated
| ## Functionality | ||
|
|
||
| - **Community messages** (channel posts, updates) must be sent and received via **Waku**. | ||
| - **Description change notifications** must be broadcast on Waku when the community description is updated via Codex. |
There was a problem hiding this comment.
| - **Description change notifications** must be broadcast on Waku when the community description is updated via Codex. | |
| - Participants must be notified of **Description changes**. |
"Broadcast on Waku" implies that that all nodes need to be notfied rather than limited to community members.
There was a problem hiding this comment.
I would rephrase to:
"Users must be aware of changes on the community description" within 1 hour.
Also, I would define in more details "description":
- logo
- descriptive text
- owner id
- member ids
and then you can clarify for each (eg Logo + descriptive text) what is needed:
- retrievable for any user, member or not
- only members can see it, etc
And we can also start questioning things such as:
- members of the community can get the list of all other members in the community.
docs/FURPS/communities-over-waku.md
Outdated
| - Temporary disconnections | ||
| - Slow or lossy networks | ||
| - Waku store nodes must reliably store messages for **30 days**, and make them retrievable on demand. | ||
| - Description change messages must be **deduplicated and verifiable**. |
There was a problem hiding this comment.
What particular properties need to be verified?
docs/FURPS/communities-over-waku.md
Outdated
| - **Partial updates** (e.g., channel edits, member changes) can be proposed by **admins**, but must be sent to the **control node** for approval before being published. | ||
| - Communities support a **permission model**: | ||
| - **Control node**: the sole authority for publishing official community description changes. | ||
| - **Token masters**: same rights as owners except cannot manage other token masters. |
docs/FURPS/communities-over-waku.md
Outdated
|
|
||
| ## Functionality | ||
|
|
||
| - **Community messages** (channel posts, updates) must be sent and received via **Waku**. |
There was a problem hiding this comment.
This requirement makes sense, but out of curiosity is Waku a hard requirement here?
There was a problem hiding this comment.
I suggest to rewrite that as a requirement to the "Logos" stack, then we (Waku. Codex, etc) can review what system should handle what.
There was a problem hiding this comment.
Awesome job, thank you for that.
As discussed in our call, I suggest those requirements to be focused on Logos stack as a whole. So that whether Waku or Codex is used can be left to Waku Chat SDK devs.
I also suggest to rewrite some requirements to understand what exactly Status app needs out of the overall library, instead of dictating how you'd want to see it.
E.g. "30 days on Waku" is not a good requirement.
A better reqquirement is "user can access messages after being offline, as long as tehy were offline for less than 30 consecutive days".
Then the Chat SDK can decide whether to leave message for 30 days on Waku, or 1 hour on Waku and the rest on Codex, etc.
Would be good to spend more time on privacy/anonymity/censorship-resistance.= expectations too
docs/FURPS/communities-over-waku.md
Outdated
|
|
||
| ## Functionality | ||
|
|
||
| - **Community messages** (channel posts, updates) must be sent and received via **Waku**. |
There was a problem hiding this comment.
I suggest to rewrite that as a requirement to the "Logos" stack, then we (Waku. Codex, etc) can review what system should handle what.
docs/FURPS/communities-over-waku.md
Outdated
| @@ -0,0 +1,51 @@ | |||
| # Waku Requirements for Status Communities — FURPS | |||
|
|
|||
| Note: These requirements assume the Community Description has been moved to Codex | |||
There was a problem hiding this comment.
I would suggest to see the "Logos stack" as a whole from an app dev point of view, and state your requirements on the full stack.
As discussed, it may make more sense to have the Community Description on-chain, simply because it opens the design space in terms of "who can add users", and makes administration much easier.
It allows a more lazy retrieval approach to it (in comparison to pushing on Waku).
Hence, we need requirements on this such as "nobody can now who is in teh community" so that specific solutions (Merkle tree, proof) can be specified.
docs/FURPS/communities-over-waku.md
Outdated
| ## Functionality | ||
|
|
||
| - **Community messages** (channel posts, updates) must be sent and received via **Waku**. | ||
| - **Description change notifications** must be broadcast on Waku when the community description is updated via Codex. |
There was a problem hiding this comment.
I would rephrase to:
"Users must be aware of changes on the community description" within 1 hour.
Also, I would define in more details "description":
- logo
- descriptive text
- owner id
- member ids
and then you can clarify for each (eg Logo + descriptive text) what is needed:
- retrievable for any user, member or not
- only members can see it, etc
And we can also start questioning things such as:
- members of the community can get the list of all other members in the community.
docs/FURPS/communities-over-waku.md
Outdated
|
|
||
| - **Community messages** (channel posts, updates) must be sent and received via **Waku**. | ||
| - **Description change notifications** must be broadcast on Waku when the community description is updated via Codex. | ||
| - Only the **control node** is authorized to publish description changes. |
There was a problem hiding this comment.
I would avoid inferring a specific architecture, especially because I understand the "control node" is seen as a limitation, not something really desired.
| - Only the **control node** is authorized to publish description changes. | |
| - Only changes on the community description published by the community owner are valid. |
docs/FURPS/communities-over-waku.md
Outdated
| - **Community messages** (channel posts, updates) must be sent and received via **Waku**. | ||
| - **Description change notifications** must be broadcast on Waku when the community description is updated via Codex. | ||
| - Only the **control node** is authorized to publish description changes. | ||
| - **Partial updates** (e.g., channel edits, member changes) can be proposed by **admins**, but must be sent to the **control node** for approval before being published. |
There was a problem hiding this comment.
Similar to the above
| - **Partial updates** (e.g., channel edits, member changes) can be proposed by **admins**, but must be sent to the **control node** for approval before being published. | |
| - **admins** can proposed **Partial updates** (e.g., channel edits, member changes) to the **owner**. |
The previous sentence already states that only the owner can published finalized changes
docs/FURPS/communities-over-waku.md
Outdated
| - Only the **control node** is authorized to publish description changes. | ||
| - **Partial updates** (e.g., channel edits, member changes) can be proposed by **admins**, but must be sent to the **control node** for approval before being published. | ||
| - Communities support a **permission model**: | ||
| - **Control node**: the sole authority for publishing official community description changes. |
There was a problem hiding this comment.
| - **Control node**: the sole authority for publishing official community description changes. | |
| - **Owner**: the sole authority for publishing official community description changes. |
docs/FURPS/communities-over-waku.md
Outdated
| - **Control node**: the sole authority for publishing official community description changes. | ||
| - **Token masters**: same rights as owners except cannot manage other token masters. | ||
| - **Admins**: same rights as token masters, except cannot deploy/mint/burn tokens. | ||
| - Messages must be available on Waku **store nodes** for **at least 30 days**. |
There was a problem hiding this comment.
As per my other comments, I would move away from requirements that are imposed on specific tech, and instead, more functional requirements of the final product:
- A user who was offline must eventually be able to retrieve all messages of the community, as long as they were offline for less than 30 days.
- A user that was offline less than one week must be able to retrieve all missed messages within 5 minutes
- A user that was offline for more than one week, and less than 30 days, must be able to retrieve all missed messages within 30 minutes
docs/FURPS/communities-over-waku.md
Outdated
| - Waku must support **channel-based topics**, including: | ||
| - Public channels | ||
| - **Token-gated channels**, where messages are encrypted and sent to dedicated Waku topics | ||
| - The system must support **message encryption** using the Status protocol or none, depending on the use case. | ||
| - **Mobile clients** must operate in **light mode** (filtering by topic of interest) and not relay all Waku traffic. |
There was a problem hiding this comment.
Again, focus on the functional end goal, without referring to the current technological and architectural choices
(probably need to move bw requirements to Performance)
| - Waku must support **channel-based topics**, including: | |
| - Public channels | |
| - **Token-gated channels**, where messages are encrypted and sent to dedicated Waku topics | |
| - The system must support **message encryption** using the Status protocol or none, depending on the use case. | |
| - **Mobile clients** must operate in **light mode** (filtering by topic of interest) and not relay all Waku traffic. | |
| - Within a community, messages can be segregated by channels, for which users may have different permission access (read/write) | |
| - Permissions may be defined using onchain tokens (token-gated channels) | |
| - Users that do not have the read permissions on a channel, must not be able to read messages on this channel (encryption must be used). | |
| - A Status Desktop instance should use less than 10Mbps on download and 5Mpbs (avg per day) on upload | |
| - A Status Mobile instance should use less than 5GB per month in total data transmitted. |
docs/FURPS/communities-over-waku.md
Outdated
| - Message propagation and retrieval must be **transparent to end users**. | ||
| - Users should not experience delays when sending or receiving messages in real time. |
There was a problem hiding this comment.
Usability is for developers, as Logos/Waku are providing library.
So you need to express usability so you can easily integrate the library.
Some usability or functionality items may be derived from you trying to define your own Usability items for end users (but such Us would belong in Status' app FURPS).
| - Message propagation and retrieval must be **transparent to end users**. | |
| - Users should not experience delays when sending or receiving messages in real time. | |
| - Automated retry for message sending and retrieval should apply without additional configuration | |
| - A message sent by a user, should be received by another online user within 500ms | |
| - A message sent by a user, should be marked as acknowledged within 5 seconds if another user was online. |
docs/FURPS/communities-over-waku.md
Outdated
|
|
||
| - Message propagation and retrieval must be **transparent to end users**. | ||
| - Users should not experience delays when sending or receiving messages in real time. | ||
| - **Token-gated channel access** should require no manual topic configuration — the Status app must handle Waku topic subscriptions automatically. |
There was a problem hiding this comment.
Well, you define the Status app, so this doesn't really belong here, do you mean
| - **Token-gated channel access** should require no manual topic configuration — the Status app must handle Waku topic subscriptions automatically. | |
| - The usage of Waku content topics should be managed by the provided Chat SDK |
That's a good usability point!
jrainville
force-pushed
the
docs/waku-communities-furps
branch
from
43d1ff7 to
e7fbab5
Compare
|
@fryorcraken @jazzz thank you for the comments. I think I addressed them all. Summary: I changed the format to be agnostic of Waku and use the Logos Stack generically. I also added an annex at the bottom to describe what the Community Description contains. Later, after I've had a meeting with Patryk, I'll also add FURPS for when the community is on chain instead. |
docs/FURPS/communities.md
Outdated
| - **Community messages** (channel posts, updates) must be sent and received via the **Messaging protocol**. | ||
| - The Community will be described in the **Community Description** | ||
| - See Annex A below for the list of properties of the Community Description | ||
| - The Community Description must be stored on the **Storage Protocol** |
There was a problem hiding this comment.
| - **Community messages** (channel posts, updates) must be sent and received via the **Messaging protocol**. | |
| - The Community will be described in the **Community Description** | |
| - See Annex A below for the list of properties of the Community Description | |
| - The Community Description must be stored on the **Storage Protocol** | |
| - **Community messages** (channel posts, updates) must be exchanged between users of the community in a real-time. | |
| - The Community will be described in the **Community Description** | |
| - See Annex A below for the list of properties of the Community Description | |
| - The Community Description must be available to all users of the community. Only the community owner can update the community description. |
You just replaced Waku and Codex with "Messaging Protoocl or Storage Protocol". My suggestion was to focus on the actual functionality you want. I don't think you, or your users, care what kind of protocol is used.
jrainville
force-pushed
the
docs/waku-communities-furps
branch
from
6aa3e6d to
4e5c832
Compare
Adds FURPS for how Satus communities should work over Waku
I made them assuming the description was no longer on Waku but instead of Codex (or somewhere else magically).
Let me know if you want the current version too and I can add it