docs(messaging): delivery track milestones fixes #414
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,60 @@ | ||
| --- | ||
| title: RLN for LightPush | ||
| tags: | ||
| - messaging-milestone | ||
| date: '2026-04-06T00:00:00.000Z' | ||
| github: 'https://github.com/logos-messaging/pm/issues/411' | ||
| --- | ||
| **Resources Required**: | ||
| - 1 Delivery engineer | ||
| - AnonComms support | ||
|
|
||
| Resolve the architectural gap where LightPush service nodes share a single RLN quota with relay traffic, making LightPush non-functional under high-volume relay conditions. | ||
|
|
||
| Once done, Logos Messaging fleets should be able to become fully RLN-protected; edge nodes are required to get an RLN membership and send lightpush requests with RLN-proof attached; RLNaaS is discontinued. | ||
|
Contributor
There was a problem hiding this comment. Also important to strengthen the membership management mechanism. Keep working on something like the following seems interesting: https://rln.waku.org/
Contributor
Author
There was a problem hiding this comment. @Ivansete-status as discussed in the call, what you describe is already part of our roadmap: logos-messaging/pm#353 We definitely need to simplify the usage of RLN. Perhaps it will be some kind of RLN membership API. But this is out of scope of |
||
|
|
||
| It's an open question, how edge nodes will get RLN memberships. The initial implementation should have the same approach as Relay, later versions might introduce sponsored memberships. | ||
| ## Risks | ||
|
|
||
| | Risk | (Accept, Own, Mitigation) | | ||
| | ----------------------------------------------- | --------------------------------------------- | | ||
| | RLN membership sponsorship model is not defined | Focus on no-sponsorship implementation first. | | ||
| ## Deliverables | ||
|
|
||
| ### Add support for RLN proofs in edge mode | ||
|
|
||
| **Owner**: Delivery Team | ||
|
|
||
| Enable light clients with their own RLN membership to generate proofs client-side and submit messages with proofs via lightpush. The service node verifies the proof and relays without consuming its own quota. | ||
|
|
||
| This decouples lightpush from service node quota entirely for clients that have their own membership, and is the long-term path to sustainable edge mode. | ||
|
|
||
| **Done when**: A light client with its own RLN membership can send a pre-proven message via lighpush, and the service node relays it without consuming its own nonce. | ||
|
|
||
| Note that this might already be possible in `logos-delivery`, in that case it needs verification. | ||
|
|
||
| ### [Improve RLN UX by reducing contract interactions](https://github.com/waku-org/pm/issues/344) | ||
|
|
||
| **Owner**: Delivery Team | ||
|
|
||
| **Feature**: [RLN Smart Contract](/messaging/furps/core/rln_smart_contract.md) | ||
|
|
||
| **FURPS**: | ||
| - U3. Application does not need to do a Web3 RPC call for every tree change to generate or validate messages. | ||
| - U4. Application can transfer tokens and register membership with a single transaction. | ||
|
Comment on lines
+43
to
+44
Contributor
There was a problem hiding this comment. We will need Annon Coms help.
Contributor
Author
There was a problem hiding this comment. AnonComms will help with this, but I'll keep @Ivansete-status do we have |
||
|
|
||
| ### Enable LightPush rate limiting in Logos Testnet | ||
|
|
||
| **Owner**: Delivery Team | ||
|
|
||
| Enable Logos Testnet fleet nodes to start verifying lightpush RLN proofs, and drop lightpush requests without RLN proofs. | ||
|
|
||
| **Done when**: Fleet deployments (`logos.dev`, `logos.test`) are updated. | ||
|
|
||
| ### Enable LightPush rate limiting in `waku.sandbox` | ||
|
|
||
| Enable `waku.sandbox` fleet nodes to start verifying lightpush RLN proofs, and drop lightpush requests without RLN proofs. | ||
|
|
||
| This must be done carefully. Node operators and users should be notified. No disturbance should occur for network users. | ||
|
|
||
| **Done when**: Fleet deployments (`logos.dev`, `logos.test`) are updated. | ||
|
Contributor
There was a problem hiding this comment. Before considering it as done I think we need to:
Contributor
Author
There was a problem hiding this comment. I think it is okay to keep existing UX for the initial version. Yes, it is difficult to start using RLN, but at least the network will be honestly protected. Currently membership management is scheduled for Testnet 0.3, but this will be one of the first things to do there. And if we have room earlier, we can consider doing it before. |
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO we should implement the current Status' store query management inside Messaging API and make Status to only use
liblogosdeliverylibrary.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll discuss and choose the approach when starting to work on this 👌