Add incentivization FURPS and nwaku status desktop milestone

This commit is contained in:
fryorcraken 2025-05-27 15:31:01 +10:00
parent b4a72d181d
commit b764657f21
No known key found for this signature in database
GPG Key ID: A82ED75A8DFC50A4
5 changed files with 86 additions and 2 deletions

View File

@ -24,4 +24,4 @@
## + (Privacy, Anonymity, Deployments)
1. Status Desktop CI builds binaries with nwaku, alongside go-waku-based binaries.
1. Status Desktop CI builds binaries with nwsaku, alongside go-waku-based binaries.

View File

@ -0,0 +1,36 @@
# Incentivization FURPS
## Functionality
1. RLNaaS clients proceed to pay RLNaaS providers for attaching RLN proof to published messages.
2. RLNaaS clients can assess of the quality of a provisioned RLNaaS and use it to build local reputation.
3. RLNaaS clients can use local reputation of RLNaaS providers to select what provider to use.
4. Payments can be done by batch.
5. Service node cannot take whole batch payment without providing the expected service.
## Usability
1. A consumer node can pay a service node for RLNaaS.
2. A consumer node can select an RLNaaS provider based on their price and local reputation.
3. A user can pay a service provider without revealing their wallet address.
## Reliability
1. A consumer prefers new providers to known unreliable providers.
2. In a stable network, a client can find, pay and send a message via a RLNaaS provider (**Vac-QA**)
in 90% of cases **(Vac-DST)**
3. A client can assess whether an RLNaaS provider has relayed their message (**Vac-QA**)
in 90% of cases **(Vac-DST)**.
## Performance
1. Assuming a block time of 5 seconds,
a user can execute an RLNaaS payment and send a message within 30 seconds (Vac-DST)
## Supportability
1. A nwaku-based CLI on a testnet, interaction with a custodial wallet is out-of-scope.
## + (Privacy, Anonymity, Deployments)
1. Wallet address and IP address are un-linkable (privacy-preserving payment streaming).

View File

@ -12,7 +12,8 @@ Testing out new format, once approved:
- [Introduce E2E Reliability in Status Communities](./introduce_e2e_reliability_in_status.md)
- Rendezvous TODO? (may be done)
- [Deploy RLN onchain tree on L2 testnet](TODO)
- [Integrate nwaku in Status Desktop, relay mode only](TODO)
- [Integrate nwaku in Status Desktop, relay mode only](/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md)
- [Define incentivization for RLNaaS](TODO)
#### P2P Reliability Implementation in the Browser

24
draft-roadmap/TEMPLATE.md Normal file
View File

@ -0,0 +1,24 @@
# <Milestone Title - use verb>
<Milestone Description - what do we get once done>
**FURPS**:
- [<Feature Name>](<path/to/furps/file>): <list of furps: F1, etc>
**deliverables**:
## <Name of deliverable 1 - eg "improve feature X for the browser">
**Owner**: <one waku subteam>
**Feature**: [<Feature Name (only 1)>](<path/to/furps/file>)
**FURPS**:
- <F1. copy-paste full furp statement>
**Checklist**:
- [ ] 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)

View File

@ -0,0 +1,23 @@
# Integrate nwaku in Status Desktop, relay mode only
With this milestone, Status Desktop builds can use nwaku instead of go-waku.
However, it should be seen as a MVP as further hardening and implementation of light client mode will be missing.
Go-waku will still be used for Status Mobile.
This strategy enables concrete steps toward sunsetting go-waku in a short period of time,
avoiding a perpetual prototyping phase where many high risk problems (e.g. mobile bundle size, etc) have to be solved before the switch can be made.
The next milestone will then focus on hardening the nwaku Desktop build
and implement missing features such as Reliability Protocol for resource-restricted.
Once done, it will reduce the scope of go-waku maintenance to light clients only and
drastically reduce the duplicate work done between nwaku and go-waku.
Note that we want to draw the line to RLN in terms of go-waku maintenance,
meaning that if Status were to use RLN (see Scale 1:1 chat messages PoC), then it should happen with nwaku.
**FURPS**:
- [nwaku](/FURPS/application/nwaku.md): F1-2, S1-2, +1
- [status-go](/FURPS/application/status_go.md): F1, U1, R1, P1, S1-2, +1
**GitHub Milestone and deliverables**: https://github.com/waku-org/pm/milestone/33