mirror of
https://github.com/logos-messaging/pm.git
synced 2026-01-03 06:33:11 +00:00
Add incentivization FURPS and nwaku status desktop milestone
This commit is contained in:
parent
b4a72d181d
commit
b764657f21
@ -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.
|
||||
36
FURPS/core/incentivization.md
Normal file
36
FURPS/core/incentivization.md
Normal 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).
|
||||
@ -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
24
draft-roadmap/TEMPLATE.md
Normal 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)
|
||||
@ -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
|
||||
Loading…
x
Reference in New Issue
Block a user