docs(messaging): delivery track #387
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -28,8 +28,6 @@ tags: | |
|
|
||
| ## Performance | ||
|
|
||
| ## Supportability | ||
|
|
||
| 1. Nim library. | ||
|
|
||
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 |
|---|---|---|
| @@ -1,3 +1,91 @@ | ||
| --- | ||
| title: RLN on Logos Blockchain | ||
| tags: | ||
| - messaging-milestone | ||
| date: 2026-02-01 | ||
| github-milestone: 'https://github.com/logos-messaging/pm/milestone/64' | ||
| --- | ||
|
|
||
| # RLN on Logos Blockchain | ||
|
|
||
| https://github.com/logos-messaging/pm/milestone/64 | ||
|
|
||
| **Estimated date of completion**: Testnet v0.3 | ||
|
|
||
| **Resources Required**: | ||
| - 1 Delivery engineer | ||
| - Collaboration with Logos Blockchain team (LEE/LEZ) | ||
|
|
||
| Logos Delivery currently supports RLN with a hardcoded Ethereum-based membership backend. This milestone introduces a pluggable RLN membership interface and adds Logos Blockchain (LEE) as a membership backend. | ||
|
|
||
| **Pluggable RLN membership interface**: Logos Delivery should support different implementations of RLN membership management through a common interface. This enables: | ||
| - **EVM-based** (Ethereum L1/L2, including gasless Status Network) | ||
| - **Logos Blockchain** (LEE program) | ||
| - **Centralized server** (temporary, for development/testing) | ||
| - Any future backend | ||
|
|
||
| This is important because Status will use RLN on Status Network (EVM-based, gasless), while Logos Testnet will use RLN on Logos Blockchain. Both must be supported simultaneously. | ||
|
|
||
| **Context**: | ||
| - LEE (Logos Execution Environment) is the smart contract runtime. | ||
| - LEZ (Logos Execution Zone) is the zone implementation running on Logos Blockchain using LEE. | ||
| - Currently, RLN contracts are deployed on Ethereum Linea Sepolia. | ||
| - AnonComms is developing the RLN membership allocation LEE program | ||
| - AnonComms is also researching an RLN on gasless L2 transactions on Status Network. | ||
|
|
||
| ## FURPS | ||
|
|
||
| - [RLN Membership Management](/messaging/furps/application/rln_membership_management.md): adapted for pluggable backends | ||
|
|
||
| ## Dependencies | ||
|
|
||
| - **AnonComms**: RLN membership allocation LEE program deployed and functional | ||
| - **AnonComms**: Zerokit 1.0 API stable and public | ||
| - **Logos Blockchain**: LEE program model and tooling ready | ||
|
|
||
| ## Risks | ||
|
|
||
| | Risk | (Accept, Own, Mitigation) | | ||
| | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | LEE maturity | LEE is under active development. The program model and tooling may not be stable enough for RLN deployment. | | ||
| | Cross-team dependency | Requires coordination between Messaging, AnonComms, and Logos Blockchain teams. Align timelines early. | | ||
|
|
||
| ## Deliverables | ||
|
|
||
| ### Implement pluggable RLN membership interface | ||
|
|
||
| **Owner**: Delivery Team | ||
|
|
||
| Design and implement an interface in Logos Delivery that abstracts RLN membership management. Concrete implementations: | ||
| - EVM-based (existing Ethereum contract interaction, including gasless Status Network via RLN Prover) | ||
| - Logos Blockchain (LEE program, once AnonComms delivers it) | ||
| - Centralized server (for development/testing) | ||
|
|
||
| The interface covers: | ||
| - Credential generation | ||
| - Membership registration, extension, withdrawal | ||
| - Proof generation and validation | ||
| - Credential persistence and export/import | ||
|
|
||
| ### Integrate Logos Delivery with RLN on Logos Blockchain | ||
|
|
||
| **Owner**: Delivery Team | ||
|
|
||
| - Implement the Logos Blockchain backend for the pluggable interface | ||
| - Logos Delivery nodes can generate and validate RLN proofs against the LEE-deployed membership | ||
| - Transition Logos testnet fleets from Ethereum Sepolia to Logos Blockchain | ||
|
|
||
| ### Update RLN membership management library | ||
|
|
||
| **Owner**: Delivery Team | ||
|
|
||
| **Feature**: [RLN Membership Management](/messaging/furps/application/rln_membership_management.md) | ||
|
|
||
| **FURPS**: | ||
| - F1. Can generate RLN credentials. | ||
| - F2. Can insert RLN membership via pluggable backend. | ||
| - F3. Can extend RLN membership via pluggable backend. | ||
| - F4. Can withdraw deposit via pluggable backend. | ||
| - F5. Membership credentials are encrypted by default on local disk. | ||
| - U1. RLN membership details can be exported and imported. | ||
| - U2. Deployment details (backend type, address/endpoint) are persisted by library and in exports. | ||
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 |
|---|---|---|
| @@ -1,23 +1,25 @@ | ||
| --- | ||
| title: Reliable Channel API — General Availability | ||
| tags: | ||
| - messaging-milestone | ||
| date: 2025-12-17 | ||
| --- | ||
|
|
||
| > [!NOTE] This file will be renamed to `2026-reliable-channel-api-general-availability` | ||
|
|
||
| # Reliable Channel API — General Availability | ||
|
|
||
| **Estimated date of completion**: Q3 2026 (Testnet v0.3) | ||
|
|
||
| **Resources Required for 2026H2**: | ||
| - 2 Delivery engineers | ||
| - 1 Chat engineer | ||
|
|
||
| The [Developer Preview](2025-package-sds-in-reliable-channel-api.md) delivers the core SDS experience. This milestone completes the [Reliable Channel API](https://github.com/logos-messaging/specs/pull/89) by adding: | ||
|
Contributor
There was a problem hiding this comment. I didn't notice that currently ongoing PR and raised that one: logos-messaging/specs#104 I'll merge both in one so that we just handle one PR. |
||
| - Message segmentation for large payloads | ||
| - Rate limit management (in preparation for future RLN integration) | ||
|
|
||
| Also deprecates store hash queries as they enable linkability of participants in the same channel from a store node PoV. Prepares reliable channel to support de-MLS encryption. | ||
|
Contributor
There was a problem hiding this comment. I don't think we can fully deprecate store-hash queries because SDS offers the option to configure "retrieval hints" so that the app has mechanism to recover lost messages, and one possible hint is by allowing hash-based queries. We will see how the development evolves, though.
Contributor
Author
There was a problem hiding this comment. We don't need to remove this from protocol, but ideally in the future we shouldn't rely on Store nodes. |
||
|
|
||
| ## FURPS | ||
|
|
||
|
|
@@ -26,26 +28,83 @@ Finally, prepare reliable channel to support de-MLS like encryption. | |
|
|
||
| ## Risks | ||
|
|
||
| | Risk | (Accept, Own, Mitigation) | | ||
| | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | Reed-Solomon reconstruction in segementation might be reduntant | Reed-Solomon-based reconstruction in Segmentation might be redundant, because SDS-R already ensures re-transmission of messages. Consider removing, discuss with AnonComms team. | | ||
|
Contributor
There was a problem hiding this comment. I don't think we currently implement or use Reed-Solomon. I didn't see it mentioned on any spec either.
Contributor
Author
There was a problem hiding this comment. Reed-Solomon is part of Segmentation |
||
| | Rate limit UX impact | Rate limiting will cause messages to be queued or dropped. UX implications need to be communicated to Chat team and developers. | | ||
|
|
||
| ## Deliverables | ||
|
|
||
| ### Create Segmentation Library | ||
|
|
||
| https://github.com/logos-messaging/pm/issues/318 | ||
|
|
||
| **Owner**: Chat Team | ||
|
Contributor
There was a problem hiding this comment. This can be for Chat Team of course but, should its implementation live in
Contributor
Author
There was a problem hiding this comment. The segmentation library was already migrated to Nim by Chat team, this milestone was defined quite a while ago. I will add Delivery team here too, because you will need to move it to one of these repos: |
||
|
|
||
| **Feature**: [Segmentation](/messaging/furps/application/segmentation.md) | ||
|
|
||
| **FURPS**: | ||
| - F1. Outbound messages larger than the maximum message size are partitioned into several messages to fit transport constraints. | ||
| - F2. Inbound partitioned messages are reconstructed into a whole message. | ||
| - F3. A capping limit is applied to pre-segmented messages (e.g. 100MB). | ||
| - F4. Messages under the maximum message size are not modified. | ||
|
|
||
| - U1. Only takes a maximum message size as a parameter. | ||
|
|
||
| - R1. Reconstruction can be performed even when parts are received out of order. | ||
| - R2. Reconstruction can be performed as long as 87.5% of the segments is received. | ||
| - R3. If too many parts are missing to reconstruct, an informative error should be logged. | ||
|
|
||
| - P1. The payload overhead does not exceed 12.5% overall, and 100 bytes per segment. | ||
|
|
||
| - S1. Nim library. | ||
|
|
||
| - +1. Segmentation metadata should not reveal information about the original message content. | ||
| - +2. Relevant for all Logos Delivery nodes. | ||
| - +3. Nimble package manager is used to build. | ||
|
|
||
| ### Create Rate Limit Manager | ||
|
|
||
| https://github.com/logos-messaging/pm/issues/319 | ||
|
|
||
| **Owner**: Chat Team | ||
|
|
||
| **Feature**: [Rate Limit Manager](/messaging/furps/application/rate_limit_manager.md) | ||
|
|
||
| **FURPS**: | ||
| - F1. Rate limit the number of messages passed to the delivery service. | ||
| - F2. The rate limit is set in the form of number of messages per epoch; same format as RLN Relay. | ||
| - F3. Tracks current quota and usage. | ||
| - F4. Messages can be flagged with three priority levels: critical, normal, optional. | ||
| - F5. When remaining message quota is low, critical messages are sent, normal messages are queued and optional messages are dropped. | ||
| - F6. When message quota is exhausted, critical messages are queued on top, normal messages are queued, optional messages are dropped. | ||
|
|
||
| - U1. Developer can mark messages with relevant priority. | ||
| - U2. Developer can pass messages by batch; with an all-or-none sending strategy. | ||
| - U3. Developer can access total quota and remaining quota values. | ||
| - U4. Message status is available to the developer (queued, dropped, passed to delivery service). | ||
|
|
||
| - R1. Errors and status from the underlying delivery service are available to the developer. | ||
| - R2. Queued messages are persisted across restart. | ||
| - R3. Quota status is persisted across restart. | ||
|
|
||
| - S1. Nim library. | ||
| - +1. Nimble package manager is used to build. | ||
|
|
||
| ### Add Segmentation to Reliable Channel API | ||
|
|
||
| **Owner**: Delivery Team | ||
|
|
||
| **Feature**: [Reliable Channel API](/messaging/furps/application/reliable_channel.md) | ||
|
|
||
| **FURPS**: | ||
| - F10. Large messages are segmented to fit transport constraints. | ||
| - R2. Segments tracked independently and reassembled before delivery (via event emission). | ||
| - P2. Final encoded routed message stays below 150 KB routing layer limit. | ||
|
|
||
| ### Add Rate Limit Manager to Reliable Channel API | ||
|
|
||
| **Owner**: Delivery Team | ||
|
|
||
| **Feature**: [Reliable Channel API](/messaging/furps/application/reliable_channel.md) | ||
|
|
||
|
|
@@ -58,18 +117,22 @@ Finally, prepare reliable channel to support de-MLS like encryption. | |
|
|
||
| ### Deprecate store hash queries for missing messages | ||
|
|
||
| **Owner**: Delivery Team | ||
|
|
||
| **Feature**: [Reliable Channel API](/messaging/furps/application/reliable_channel.md) | ||
|
|
||
| **FURPS**: | ||
| - ~~F4. Missing messages are automatically retrieved via store hash queries.~~ | ||
|
|
||
| ### Support different encryption for sync messages | ||
|
|
||
| **Owner**: Delivery Team | ||
|
|
||
| **Feature**: [Reliable Channel API](/messaging/furps/application/reliable_channel.md) | ||
|
|
||
| **FURPS**: | ||
| - F11. A different encryption mechanism can be applied for sync messages (than the one for content messages). | ||
|
|
||
| ### Provide comprehensive documentation on the API | ||
|
|
||
| **Owner**: Delivery Team | ||
Oops, something went wrong.
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.
They recently deployed 2.0
We are currently using 0.9.0 and need to bump soon