mirror of
https://github.com/logos-messaging/pm.git
synced 2026-05-17 07:59:34 +00:00
Feedback re RLN
This commit is contained in:
parent
40c25a2e17
commit
17fa3fe687
@ -3,13 +3,13 @@
|
|||||||
## Functionality
|
## Functionality
|
||||||
|
|
||||||
1. RLNaaS clients proceed to pay RLNaaS providers for attaching RLN proof to published messages.
|
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.
|
2. RLNaaS clients can assess 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.
|
3. RLNaaS clients can use local reputation of RLNaaS providers to select what provider to use.
|
||||||
|
|
||||||
## Usability
|
## Usability
|
||||||
|
|
||||||
1. A consumer node can pay a service node for RLNaaS.
|
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.
|
2. A consumer node can select an RLNaaS provider based on local reputation.
|
||||||
|
|
||||||
## Reliability
|
## Reliability
|
||||||
|
|
||||||
|
|||||||
@ -4,7 +4,7 @@
|
|||||||
|
|
||||||
1. RLN rate limit can be defined in terms of multiple messages per epoch.
|
1. RLN rate limit can be defined in terms of multiple messages per epoch.
|
||||||
2. RLN rate limit is set at membership insertion
|
2. RLN rate limit is set at membership insertion
|
||||||
3. RLN initialization only requires Web3 RPC `call`s, no blockchain events are needed.
|
3. RLN proof generation and validation only requires Web3 RPC `call`s, no blockchain events or initialisation are needed.
|
||||||
4. An ERC-20 token deposit is needed to insert a membership
|
4. An ERC-20 token deposit is needed to insert a membership
|
||||||
|
|
||||||
## Usability
|
## Usability
|
||||||
|
|||||||
@ -29,10 +29,10 @@ This is the first step to providing a sustainable way to scale the Status applic
|
|||||||
|
|
||||||
**FURPS**:
|
**FURPS**:
|
||||||
- F1. RLNaaS clients proceed to pay RLNaaS providers for attaching RLN proof to published messages.
|
- F1. RLNaaS clients proceed to pay RLNaaS providers for attaching RLN proof to published messages.
|
||||||
- F2. RLNaaS clients can assess of the quality of a provisioned RLNaaS and use it to build local reputation.
|
- F2. RLNaaS clients can assess the quality of a provisioned RLNaaS and use it to build local reputation.
|
||||||
- F3. RLNaaS clients can use local reputation of RLNaaS providers to select what provider to use.
|
- F3. RLNaaS clients can use local reputation of RLNaaS providers to select what provider to use.
|
||||||
- U1. A consumer node can pay a service node for RLNaaS.
|
- U1. A consumer node can pay a service node for RLNaaS.
|
||||||
- U2. A consumer node can select an RLNaaS provider based on their price and local reputation.
|
- U2. A consumer node can select an RLNaaS provider based on local reputation.
|
||||||
- R1. A consumer prefers new providers to known unreliable providers.
|
- R1. A consumer prefers new providers to known unreliable providers.
|
||||||
- R2. In a stable network, a client can find, pay and send a message via a RLNaaS provider (**Vac-QA**)
|
- R2. 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)**.
|
in 90% of cases **(Vac-DST)**.
|
||||||
|
|||||||
@ -21,7 +21,7 @@ It will then be possible to design the usage of RLN in Chat SDK.
|
|||||||
|
|
||||||
- F1. RLN rate limit can be defined in terms of multiple messages per epoch.
|
- F1. RLN rate limit can be defined in terms of multiple messages per epoch.
|
||||||
- F2. RLN rate limit is set at membership insertion
|
- F2. RLN rate limit is set at membership insertion
|
||||||
- F3. RLN initialization only requires Web3 RPC `call`s, no blockchain events are needed.
|
- F3. RLN proof generation and validation only requires Web3 RPC `call`s, no blockchain events or initialisation are needed.
|
||||||
- F4. An ERC-20 token deposit is needed to insert a membership
|
- F4. An ERC-20 token deposit is needed to insert a membership
|
||||||
- U1. Application developers can set RLN rate limit at insertion.
|
- U1. Application developers can set RLN rate limit at insertion.
|
||||||
|
|
||||||
@ -53,23 +53,6 @@ It will then be possible to design the usage of RLN in Chat SDK.
|
|||||||
- [ ] Dogfood: link to dogfooding session/artefact
|
- [ ] Dogfood: link to dogfooding session/artefact
|
||||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
||||||
|
|
||||||
## [Fallback strategy for Web3 RPC endpoints are implemented in nwaku]()
|
|
||||||
|
|
||||||
**Owner**: nwaku
|
|
||||||
|
|
||||||
**Feature**: [nwaku](/FURPS/application/nwaku.md)
|
|
||||||
|
|
||||||
**FURPS**:
|
|
||||||
|
|
||||||
- R1. Relay node can fallback to alternative RPC endpoints
|
|
||||||
if the primary Web3 RPC provider becomes unavailable.
|
|
||||||
|
|
||||||
**Checklist**:
|
|
||||||
- [ ] Specs: link to specs and/or API definition
|
|
||||||
- [ ] Code: link to GitHub issues/PRs/Epic
|
|
||||||
- [ ] Dogfood: link to dogfooding session/artefact
|
|
||||||
- [ ] Docs: links to README.md or docs.waku.org (TBD)
|
|
||||||
|
|
||||||
## [RLNv2 Web management interface](https://github.com/waku-org/pm/issues/281)
|
## [RLNv2 Web management interface](https://github.com/waku-org/pm/issues/281)
|
||||||
|
|
||||||
**Owner**: js-waku
|
**Owner**: js-waku
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user