From bca9e3691ee2749d555328480cda9c4b58c3f6fd Mon Sep 17 00:00:00 2001 From: Igor Sirotin Date: Mon, 30 Mar 2026 10:48:44 +0100 Subject: [PATCH 1/5] docs: include subscribe api to developer preview milestone --- content/messaging/roadmap/index.md | 2 +- ...2026-messaging-api-general-availability.md | 33 +++---------------- 2 files changed, 6 insertions(+), 29 deletions(-) diff --git a/content/messaging/roadmap/index.md b/content/messaging/roadmap/index.md index 060e7c66c7..1add168b38 100644 --- a/content/messaging/roadmap/index.md +++ b/content/messaging/roadmap/index.md @@ -96,7 +96,7 @@ We use two release stages for developer-facing APIs and libraries: - [Support Discovery Research and Libp2p QUIC](2025-support-discovery-research-and-libp2p-quic.md) — discovery now under AnonComms; QUIC moved to v0.2 - [Enable easy C-Bindings for Desktop](2025-enable-easy-c-bindings-for-desktop.md) — absorbed into [Initial Integration to Logos Core](2025-enable-easy-c-bindings-for-desktop.md) - [Enable easy C-Bindings for Mobile](2025-enable-easy-c-bindings-for-mobile.md) — absorbed into [Support Mobile Platforms](2026-support-mobile-platforms) -- [Add Edge Mode to Messaging API](2025-add-edge-mode-to-messaging-api.md) — absorbed into [Messaging API — General Availability](2026-messaging-api-general-availability) +- [Add Edge Mode to Messaging API](2025-add-edge-mode-to-messaging-api.md) — absorbed into [Messaging API — Developer Preview](2025-api-access-to-p2p-reliability-for-desktop) - [Messaging and Chat on Mobile](2025-messaging-chat-on-mobile.md) — absorbed into [Support Mobile Platforms](2026-support-mobile-platforms) - [Add peer discovery to mixnet and support browser](2025-add-peer-discovery-to-mixnet-and-support-browser.md) - [Debugging Tools](2025-debugging-tools.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 index 367884ac94..208d027642 100644 --- a/content/messaging/roadmap/milestones/2026-messaging-api-general-availability.md +++ b/content/messaging/roadmap/milestones/2026-messaging-api-general-availability.md @@ -8,49 +8,26 @@ github: https://github.com/logos-messaging/pm/issues/403 **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: +The Developer Preview delivered the Send, Health, and Subscribe/Receive APIs, including both core and edge 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. +1. **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`. +2. **Test suite** — Messaging API is QA-approved. Involvement of DST for reliability testing. +3. **Documentation** — comprehensive developer documentation on the API. ## FURPS -- [Messaging API](/messaging/furps/core/messaging_sdk.md): F2, F6, R2, S2 +- [Messaging API](/messaging/furps/core/messaging_sdk.md): F6, 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 From f05b430b3ae4f1cfed8a12dcf94b9732ea15abff Mon Sep 17 00:00:00 2001 From: Igor Sirotin Date: Mon, 30 Mar 2026 10:52:25 +0100 Subject: [PATCH 2/5] docs: minor fixes --- .../2025-api-access-to-p2p-reliability-for-desktop.md | 9 +++------ .../milestones/2026-add-support-for-rln-on-lee.md | 2 +- .../milestones/2026-complete-reliable-channel-api.md | 2 +- 3 files changed, 5 insertions(+), 8 deletions(-) diff --git a/content/messaging/roadmap/milestones/2025-api-access-to-p2p-reliability-for-desktop.md b/content/messaging/roadmap/milestones/2025-api-access-to-p2p-reliability-for-desktop.md index abea25b208..b0b6be7351 100644 --- a/content/messaging/roadmap/milestones/2025-api-access-to-p2p-reliability-for-desktop.md +++ b/content/messaging/roadmap/milestones/2025-api-access-to-p2p-reliability-for-desktop.md @@ -14,7 +14,7 @@ github: 'https://github.com/logos-messaging/pm/issues/395' The Messaging API provides a higher-level abstraction over Logos Delivery protocols, enabling easier integration in Status, Logos Chat, and for developer experience in Logos Core. -The Developer Preview delivers the Send and Health APIs, with core mode only (relay is used to send and receive messages). The Subscribe/Receive API is in progress but may extend into v0.2. +The Developer Preview delivers the Send, Health, and Subscribe/Receive APIs. Core mode uses relay to send and receive messages. Edge mode uses light push for sending and filter for reception. RLN and RLNaaS are out of scope for this milestone. No function for store or message retrieval is exposed on the API — previous message retrieval is to be done as part of the `subscribe` function, applying P2P reliability protocol. @@ -22,7 +22,7 @@ This includes removing potential foot guns (store as CDN) and reducing learning ## FURPS -- [Messaging API](/messaging/furps/core/messaging_sdk.md): F1, F3, F4, F5, F6, U1, U2, U3, U4, U5, R1, S1 +- [Messaging API](/messaging/furps/core/messaging_sdk.md): F1, F2, F3, F4, F5, F6, U1, U2, U3, U4, U5, R1, R2, S1 ## Risks @@ -50,7 +50,4 @@ This includes removing potential foot guns (store as CDN) and reducing learning - U4. By default, auto-sharding is applied, meaning developers do not need to be concerned by sharding; pubsub topics are never exposed. - U5. Developers only need to handle errors in cases of irretrievable failure requiring end-user action. Internal errors are not bubbled up if they can be recovered internally. - R1. Sends a message using peer-to-peer reliability (service node redundancy, optional store confirmation) -- R2. Receives messages using peer-to-peer reliability (service node redundancy, periodic store query, periodic filter ping) - -For: -- S1. Nim library with Nimble. +- R2. Receives messages using peer-to-peer reliability (service node redundancy, periodic store query, periodic filter ping) \ No newline at end of file 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 6ad692c45a..be3ef0030c 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 @@ -34,7 +34,7 @@ This is important because Status will use RLN on Status Network (EVM-based, gasl ## Dependencies - **AnonComms**: RLN membership allocation LEE program deployed and functional -- **AnonComms**: Zerokit 1.0 API stable and public +- **AnonComms**: Zerokit 2.0 API stable and public - **Logos Blockchain**: LEE program model and tooling ready ## Risks 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 a6f807fd3a..f4533e0993 100644 --- a/content/messaging/roadmap/milestones/2026-complete-reliable-channel-api.md +++ b/content/messaging/roadmap/milestones/2026-complete-reliable-channel-api.md @@ -37,7 +37,7 @@ Also deprecates store hash queries as they enable linkability of participants in https://github.com/logos-messaging/pm/issues/318 -**Owner**: Chat Team +**Owner**: Chat Team + Delivery Team **Feature**: [Segmentation](/messaging/furps/application/segmentation.md) From 5929738407c8b934b1bb16d3ada744c5e675fecf Mon Sep 17 00:00:00 2001 From: Igor Sirotin Date: Tue, 7 Apr 2026 20:36:26 +0100 Subject: [PATCH 3/5] docs(messaging): defined RLN for lightpush milestone --- content/messaging/roadmap/index.md | 1 + .../milestones/2026-rln-for-lightpush.md | 60 +++++++++++++++++++ 2 files changed, 61 insertions(+) create mode 100644 content/messaging/roadmap/milestones/2026-rln-for-lightpush.md diff --git a/content/messaging/roadmap/index.md b/content/messaging/roadmap/index.md index 1add168b38..ac0ca933e0 100644 --- a/content/messaging/roadmap/index.md +++ b/content/messaging/roadmap/index.md @@ -41,6 +41,7 @@ We use two release stages for developer-facing APIs and libraries: - [ ] [Chat — Group Conversations](2025-extend-chat-sdk-with-group-conversations) - [ ] [Logos Core Integration — Phase 2](2026-logos-core-integration-phase-2) - [ ] [QUIC Transport in Logos Delivery](2025-support-discovery-research-and-libp2p-quic) +- [ ] [RLN for lightpush](2026-rln-for-lightpush.md) ### Testnet [v0.3](v03) diff --git a/content/messaging/roadmap/milestones/2026-rln-for-lightpush.md b/content/messaging/roadmap/milestones/2026-rln-for-lightpush.md new file mode 100644 index 0000000000..3307f6a661 --- /dev/null +++ b/content/messaging/roadmap/milestones/2026-rln-for-lightpush.md @@ -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. + +It's an open question, how edge not will get RLN membership. 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. + +### 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. \ No newline at end of file From 6049b047e888d74f00551aae5a75324e45bd3feb Mon Sep 17 00:00:00 2001 From: Igor Sirotin Date: Tue, 7 Apr 2026 20:37:48 +0100 Subject: [PATCH 4/5] docs(messaging): rln deliverables --- .../2026-complete-reliable-channel-api.md | 14 ++++++++++++++ .../2026-logos-core-integration-phase-2.md | 2 +- .../2026-status-logos-chat-integration.md | 7 +++++++ 3 files changed, 22 insertions(+), 1 deletion(-) 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 f4533e0993..74ba335dea 100644 --- a/content/messaging/roadmap/milestones/2026-complete-reliable-channel-api.md +++ b/content/messaging/roadmap/milestones/2026-complete-reliable-channel-api.md @@ -113,6 +113,20 @@ https://github.com/logos-messaging/pm/issues/319 - U5. Rate limit is configurable at channel creation. - U6. Rate limit "approached" state is configurable at channel creation. +### [Implement RLN membership management in `logos-delivery`](https://github.com/logos-messaging/pm/issues/353) + +**Owner:** Delivery Team + +**FURPS:** +- F1. Can generate RLN credentials. +- F2. Can insert RLN membership in smart contract, with accompanying deposit. +- F3. Can extend RLN membership on smart contract. +- F4. Can withdraw deposit from smart contract. +- F5. Membership credentials are encrypted by default on local disk. +- U1. RLN membership details can be exported and imported. +- U2. Deployment details (address, chain id) are persisted by library and in exports. +- +2. Available for Linea Sepolia Testnet contracts. + ### Deprecate store hash queries for missing messages **Owner**: Delivery Team diff --git a/content/messaging/roadmap/milestones/2026-logos-core-integration-phase-2.md b/content/messaging/roadmap/milestones/2026-logos-core-integration-phase-2.md index 3abfdecfc7..ceb43fd6cf 100644 --- a/content/messaging/roadmap/milestones/2026-logos-core-integration-phase-2.md +++ b/content/messaging/roadmap/milestones/2026-logos-core-integration-phase-2.md @@ -78,7 +78,7 @@ A single Logos Core application implemented in QML (replacing the v0.1 Qt widget - Supports identity (user with multiple installations, add/remove devices) - Uses the Chat and Delivery Logos Core modules through their APIs -### Define integration tests for Messaging modules +### Implement integration tests for Messaging modules **Owner**: Messaging Team (definition) + IFT-TS (implementation) diff --git a/content/messaging/roadmap/milestones/2026-status-logos-chat-integration.md b/content/messaging/roadmap/milestones/2026-status-logos-chat-integration.md index 0f9c32b5b6..2067bfff1c 100644 --- a/content/messaging/roadmap/milestones/2026-status-logos-chat-integration.md +++ b/content/messaging/roadmap/milestones/2026-status-logos-chat-integration.md @@ -73,3 +73,10 @@ Status switches from its current chat protocol implementation to Logos Chat, con - Token-gated access layer remains Status-owned - No separate community protocol from Messaging team - Logos Chat provides the group chat substrate; Status builds community features on top + +### [Deploy RLN Contracts to Status L2 testnet](https://github.com/logos-messaging/pm/issues/356) + +**Owner:** Delivery Team + +- RLN contracts are deployed on Status Network +- Logos Delivery in Status is uses RLN on Status Network \ No newline at end of file From 50acf3605a84a7e47255367d0c9e987656c41aa2 Mon Sep 17 00:00:00 2001 From: Igor Sirotin Date: Wed, 15 Apr 2026 17:23:26 +0100 Subject: [PATCH 5/5] Update content/messaging/roadmap/milestones/2026-rln-for-lightpush.md Co-authored-by: kaiserd <1684595+kaiserd@users.noreply.github.com> --- content/messaging/roadmap/milestones/2026-rln-for-lightpush.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/messaging/roadmap/milestones/2026-rln-for-lightpush.md b/content/messaging/roadmap/milestones/2026-rln-for-lightpush.md index 3307f6a661..e8f41930e7 100644 --- a/content/messaging/roadmap/milestones/2026-rln-for-lightpush.md +++ b/content/messaging/roadmap/milestones/2026-rln-for-lightpush.md @@ -13,7 +13,7 @@ Resolve the architectural gap where LightPush service nodes share a single RLN q 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. -It's an open question, how edge not will get RLN membership. The initial implementation should have the same approach as Relay, later versions might introduce sponsored memberships. +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) |