From f25704939182be3065693b2906f3491f797888e0 Mon Sep 17 00:00:00 2001 From: Igor Sirotin Date: Sun, 15 Mar 2026 14:53:08 +0000 Subject: [PATCH 1/4] refactor: Revamp Reliable Channel API milestones --- .../furps/application/rate_limit_manager.md | 2 - ...025-package-sds-in-reliable-channel-api.md | 48 ++++---- .../2026-complete-reliable-channel-api.md | 105 ++++++++++++++---- 3 files changed, 106 insertions(+), 49 deletions(-) diff --git a/content/messaging/furps/application/rate_limit_manager.md b/content/messaging/furps/application/rate_limit_manager.md index de2edd82a3..27422e52ff 100644 --- a/content/messaging/furps/application/rate_limit_manager.md +++ b/content/messaging/furps/application/rate_limit_manager.md @@ -28,8 +28,6 @@ tags: ## Performance -1. ... - ## Supportability 1. Nim library. diff --git a/content/messaging/roadmap/milestones/2025-package-sds-in-reliable-channel-api.md b/content/messaging/roadmap/milestones/2025-package-sds-in-reliable-channel-api.md index 8d566870ad..29427ef308 100644 --- a/content/messaging/roadmap/milestones/2025-package-sds-in-reliable-channel-api.md +++ b/content/messaging/roadmap/milestones/2025-package-sds-in-reliable-channel-api.md @@ -1,33 +1,28 @@ --- -title: Package SDS in Reliable Channel API +title: Reliable Channel API — Developer Preview tags: - - messaging-milestone + - messaging-milestone date: 2025-12-10 --- -# Package SDS in Reliable Channel API +> [!NOTE] This file will be renamed to `2026-reliable-channel-api-developer-preview` -**Estimated date of completion**: {Enter date} +# Reliable Channel API — Developer Preview -**Resources Required for 2025H2**: -- {roles and % application to it} -- {external services consumed (Vac/IFT)} -- {infrastructure} +**Estimated date of completion**: June 2026 (Testnet v0.2) -The [[Create Chat SDK MVP]] - developer preview - does include the [Scalable Data Sync](https://github.com/vacp2p/rfc-index/blob/main/vac/raw/sds.md) protocol usage. However, dedicated work is necessary to -fully leverage SDS to: -- identify and retrieved missed messages -- track acknowledge, and resend unacknowledged message +**Resources Required for 2026H1**: +- 2 Delivery engineers +- 1 Chat engineer for integration -The [Reliable Channel API](https://github.com/logos-messaging/specs/pull/89) delivers a simple API that enables those features, as well as: -- message segmentation -- Rate limit management (in preparation to future RLN integration). -- SDS-Repair, an extension to SDS that reduce reliance on Store services, and improves received anonymity from original SDS protocol. +The [Chat — Foundations](2025-create-chat-sdk-mvp.md) milestone does not include the [Scalable Data Sync](https://github.com/vacp2p/rfc-index/blob/main/vac/raw/sds.md) protocol. This milestone delivers dedicated work to fully leverage SDS to: +- Identify and retrieve missed messages +- Track, acknowledge, and resend unacknowledged messages -This milestone focuses on delivering a pre-configured SDS experience. Segmentation and rate limit manager will be delivered at a later stage. +The [Reliable Channel API](https://github.com/logos-messaging/specs/pull/89) delivers a simple API that enables those features, as well as: +- SDS-Repair, an extension to SDS that reduces reliance on Store services and improves receiver anonymity from the original SDS protocol. -Note: Dependency to logos-messaging-nim is to be handled via Nimble, meaning the Chat Logos Module would have libp2p, logos-messaging, etc embedded. It also means that there is no "reliable channel" Logos Core module as part of this milestone. -Moving to an architecture where the Chat module uses the locally available messaging module, is not yet planned. +This milestone focuses on forming the API and delivering a pre-configured SDS experience. Segmentation and rate limit manager will be delivered in the [General Availability](2026-complete-reliable-channel-api.md) milestone. ## FURPS @@ -35,15 +30,16 @@ Moving to an architecture where the Chat module uses the locally available messa ## Risks -| Risk | (Accept, Own, Mitigation) | -|--------|-------------------------------| -| [Risk] | [how to we address this risk] | +| Risk | (Accept, Own, Mitigation) | +| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| SDS maturity | SDS protocol has not been extensively tested in production. May require tuning of parameters to avoid network saturation. | +| SDS-Repair network overhead | SDS-R can quickly saturate the network with repair requests if parameters are not carefully tuned. Linear backoff should become exponential. | ## Deliverables ### Deliver Reliable Channel API -**Owner**: Nim Messaging Team +**Owner**: Delivery Team **Feature**: [Reliable Channel API](/messaging/furps/application/reliable_channel.md) @@ -65,18 +61,18 @@ Note: No segmentation or rate limit manager in this milestone. SDS messages cach ### Implement SDS Repair -**Owner**: Nim Messaging Team +**Owner**: Delivery Team **Feature**: [Reliable Channel API](/messaging/furps/application/reliable_channel.md) **FURPS**: - F9. Missing messages re-emission is requested from other channel participants -### Use Reliable Channels in Chat SDK +### Use Reliable Channels in Logos Chat **Owner**: Chat Team **Feature**: [Reliable Channel API](/messaging/furps/application/reliable_channel.md) **FURPS**: -- U2. Single cohesive interface wrapping SDS, store queries, segmentation, and rate limits. \ No newline at end of file +- U2. Single cohesive interface wrapping SDS, store queries, segmentation, and rate limits. diff --git a/content/messaging/roadmap/milestones/2026-complete-reliable-channel-api.md b/content/messaging/roadmap/milestones/2026-complete-reliable-channel-api.md index 0b9e37fa78..c5cca5574e 100644 --- a/content/messaging/roadmap/milestones/2026-complete-reliable-channel-api.md +++ b/content/messaging/roadmap/milestones/2026-complete-reliable-channel-api.md @@ -1,23 +1,25 @@ --- -title: Complete Reliable Channel API +title: Reliable Channel API — General Availability tags: - - messaging-milestone + - messaging-milestone date: 2025-12-17 --- -# Complete Reliable Channel API +> [!NOTE] This file will be renamed to `2026-reliable-channel-api-general-availability` -**Estimated date of completion**: {Enter date} +# Reliable Channel API — General Availability -**Resources Required for 2026H1**: -- {roles and % application to it} +**Estimated date of completion**: Q3 2026 (Testnet v0.3) -The [[Package SDS in Reliable Channel API]] milestone delivers the core SDS experience. This milestone completes the [Reliable Channel API](https://github.com/logos-messaging/specs/pull/89) by adding: +**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: - Message segmentation for large payloads -- Rate limit management (in preparation to future RLN integration) +- Rate limit management (in preparation for future RLN integration) -Also, deprecates store hash queries as they enable linkability of participants in same channel from a store node PoV. -Finally, prepare reliable channel to support de-MLS like encryption. +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. ## FURPS @@ -26,26 +28,83 @@ Finally, prepare reliable channel to support de-MLS like encryption. ## Risks -| Risk | (Accept, Own, Mitigation) | -|--------|-------------------------------| -| [Risk] | [how to we address this risk] | +| 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. | +| 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 + +**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**: Nim Messaging Team +**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 deliver (via event emission). +- 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**: Nim Messaging Team +**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**: Nim Messaging Team +**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 +### Support different encryption for sync messages -**Owner**: Nim Messaging Team +**Owner**: Delivery Team **Feature**: [Reliable Channel API](/messaging/furps/application/reliable_channel.md) -**FURPS:** -- F11. A different encryption mechanism can be applied for sync message (than the one for content messages). +**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 From 6b19a27b3b315bf78cbdfbb67f71330526cd5775 Mon Sep 17 00:00:00 2001 From: Igor Sirotin Date: Sun, 15 Mar 2026 14:53:08 +0000 Subject: [PATCH 2/4] feat: Introduce RLN on Logos Blockchain milestone --- .../2026-add-support-for-rln-on-lee.md | 90 ++++++++++++++++++- 1 file changed, 89 insertions(+), 1 deletion(-) diff --git a/content/messaging/roadmap/milestones/2026-add-support-for-rln-on-lee.md b/content/messaging/roadmap/milestones/2026-add-support-for-rln-on-lee.md index cd6344cc8b..aa4674c915 100644 --- a/content/messaging/roadmap/milestones/2026-add-support-for-rln-on-lee.md +++ b/content/messaging/roadmap/milestones/2026-add-support-for-rln-on-lee.md @@ -1,3 +1,91 @@ --- -github-milestone: https://github.com/logos-messaging/pm/milestone/64 +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. From 0ae7f7c1b71a8f9d2771f51b3bad17bed4ae031d Mon Sep 17 00:00:00 2001 From: Igor Sirotin Date: Sun, 15 Mar 2026 14:53:09 +0000 Subject: [PATCH 3/4] feat: Introduce Messaging API General Availability milestone --- ...2026-messaging-api-general-availability.md | 78 +++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 content/messaging/roadmap/milestones/2026-messaging-api-general-availability.md diff --git a/content/messaging/roadmap/milestones/2026-messaging-api-general-availability.md b/content/messaging/roadmap/milestones/2026-messaging-api-general-availability.md new file mode 100644 index 0000000000..284e04ab78 --- /dev/null +++ b/content/messaging/roadmap/milestones/2026-messaging-api-general-availability.md @@ -0,0 +1,78 @@ +--- +title: Messaging API — General Availability +tags: + - messaging-milestone +date: 2025-07-03 +--- + +# Messaging API — General Availability + +**Estimated date of completion**: June 2026 (Testnet v0.2) + +**Resources Required for 2026H1**: +- 1 Nim engineer for testing support and bugfixes +- 1 Nim engineer for edge mode +- 1 Nim engineer for Store API work. + +The Developer Preview delivered the Send and Health APIs in core mode. General Availability completes the Messaging API with: + +1. **Subscribe/Receive API** — complete the message reception flow with P2P reliability +2. **Edge mode** — support light push for sending, filter for reception, and peer exchange for discovery. Required for mobile support and Status integration. +3. **Store API** — Status still relies on Store nodes for history retrieval, community descriptions, profiles, and SDS-hinted missed messages. Either introduce a new Store API alongside Messaging API, or allow using low-level API from the same `liblogosdelivery`. +4. **Test suite** — Messaging API is QA-approved. Involvement of DST for reliability testing. +5. **Documentation** — comprehensive developer documentation on the API. + +## FURPS + +- [Messaging API](/messaging/furps/core/messaging_sdk.md): F2, F6, R2, S2 + +## Risks + +| Risk | (Accept, Own, Mitigation) | +| ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| P2P Reliability in edge mode | P2P reliability has only been tested in core mode. Edge mode introduces filter and light push which may require different reliability strategies. | +| Store is out of Messaging API scope | The Messaging API intentionally left the Store protocol outside to prevent foot-guns, a decision has to be made here to enable Status to use Messaging API. | + +## Deliverables + +### Add Subscribe/Receive functionality to Messaging API + +**Owner**: Delivery Team + +**Feature**: [Messaging API](/messaging/furps/core/messaging_sdk.md) + +**FURPS**: +- R2. Receives messages using peer-to-peer reliability (service node redundancy, periodic store query, periodic filter ping) + +### Support edge mode in Messaging API + +**Owner**: Delivery Team + +**Feature**: [Messaging API](/messaging/furps/core/messaging_sdk.md) + +**FURPS**: +- F2. Support edge node operation mode. +- F6. Previously discovered peers are persisted across restarts, and potentially used for future connections. + +### Provide Store API access for Status needs + +**Owner**: Delivery Team + +Status relies on Store nodes for: +1. Fetching history while being offline +2. Fetching community descriptions and profiles +3. Fetching missed messages (by SDS hints) + +Either introduce a new Store API (next to Messaging API), or allow using low-level API from the same `liblogosdelivery`. + +Note that Store protocol was intentionally left out of Messaging API. But we should provide a solution for existing apps, e.g. Status. + +### Test suite for Messaging API + +**Owner**: Delivery Team + +Messaging API should be QA-approved. Coordinate with DST for reliability and scale testing. + +### Provide comprehensive documentation on the API + +**Owner**: Delivery Team From e63e239c8ebd0b770814e2502d90ac0e75dcc580 Mon Sep 17 00:00:00 2001 From: Igor Sirotin Date: Wed, 18 Mar 2026 19:30:44 +0000 Subject: [PATCH 4/4] fix: update quic milestone --- ...port-discovery-research-and-libp2p-quic.md | 26 +++++++++---------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/content/messaging/roadmap/milestones/2025-support-discovery-research-and-libp2p-quic.md b/content/messaging/roadmap/milestones/2025-support-discovery-research-and-libp2p-quic.md index 8e32f9cde8..8aff6116ab 100644 --- a/content/messaging/roadmap/milestones/2025-support-discovery-research-and-libp2p-quic.md +++ b/content/messaging/roadmap/milestones/2025-support-discovery-research-and-libp2p-quic.md @@ -1,35 +1,35 @@ --- -title: Support Discovery Research and Libp2p QUIC +title: QUIC Transport in Logos Delivery tags: - - messaging-milestone + - messaging-milestone date: 2025-12-03 --- -# Support Discovery Research and Libp2p QUIC +# QUIC Transport in Logos Delivery -**Estimated date of completion**: {Enter date} +**Estimated date of completion**: Testnet v0.2 -**Resources Required for 2025H2**: 0.5 Nim Engineer +**Resources Required**: 0.5 Nim Engineer -Proceed with several items to support internal teams. +Replace legacy multiplexers (Yamux, Mplex) with QUIC transport. The old multiplexers are going towards deprecation — Yamux is inefficient, Mplex is outdated. QUIC should be prioritized. ## FURPS -- [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc} +- [Messaging API](/messaging/furps/core/messaging_sdk.md): S4. QUIC transport is supported for peer-to-peer message routing connections. ## Risks -| Risk | (Accept, Own, Mitigation) | -|--------|-------------------------------| -| [Risk] | [how to we address this risk] | +| Risk | (Accept, Own, Mitigation) | +| -------------------------- | -------------------------------------------------------------------------------------- | +| QUIC maturity in nim-libp2p | QUIC support in nim-libp2p may not be production-ready. Trial and evaluate early. | -## Deliverables +## Deliverables ### [Trial QUIC](https://github.com/waku-org/pm/issues/324) -**Owner**: Nim Messaging Team +**Owner**: Delivery Team -**Feature**: [nwaku](/messaging/furps/application/nwaku.md) +**Feature**: [Messaging API](/messaging/furps/core/messaging_sdk.md) **FURPS**: - S4. QUIC transport is supported for peer-to-peer message routing connections.