From acd58c11bb7b8159d01f00fc956b7a4f867c4c40 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 2 Dec 2025 14:05:14 +1100 Subject: [PATCH 1/2] Add deliverable check list --- .github/ISSUE_TEMPLATE/deliverable.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/.github/ISSUE_TEMPLATE/deliverable.md b/.github/ISSUE_TEMPLATE/deliverable.md index 75e34ff..629c560 100644 --- a/.github/ISSUE_TEMPLATE/deliverable.md +++ b/.github/ISSUE_TEMPLATE/deliverable.md @@ -13,3 +13,11 @@ assignees: '' ## Summary + +### 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 logos dosc +- [ ] C-API: Ensure C-API is usable \ No newline at end of file From c9d158b91465fc137c03042eaad14d4733c76929 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 16 Dec 2025 10:31:52 +1100 Subject: [PATCH 2/2] FURPS and Milestones have moved to roadmap.logos.co --- 2025H1-SUMMARY.md | 114 ---------- 2025H2-SUMMARY.md | 138 ------------- FURPS/README.md | 44 ---- FURPS/TEMPLATE.md | 25 --- FURPS/application/chat_sdk.md | 39 ---- FURPS/application/codex_archiving.md | 25 --- .../erc-20_testnet_token_for_rln_deposit.md | 22 -- FURPS/application/forum.md | 55 ----- FURPS/application/group_chat.md | 31 --- FURPS/application/js-waku.md | 17 -- FURPS/application/local_dev_rln_harness.md | 23 --- FURPS/application/local_web_dev_harness.md | 24 --- FURPS/application/network_metrics_tracker.md | 39 ---- FURPS/application/nim_ffi.md | 31 --- FURPS/application/nwaku.md | 34 --- FURPS/application/p2p_reliability.md | 22 -- FURPS/application/qaku.md | 54 ----- FURPS/application/rate_limit_manager.md | 36 ---- .../application/rln_membership_management.md | 34 --- FURPS/application/sds.md | 32 --- FURPS/application/segmentation.md | 32 --- FURPS/application/signal_network.md | 27 --- FURPS/application/status_communities.md | 34 --- FURPS/application/status_go.md | 32 --- FURPS/application/status_private_chats.md | 31 --- FURPS/core/incentivisation.md | 31 --- FURPS/core/light_push.md | 31 --- FURPS/core/mix.md | 26 --- FURPS/core/rendezvous.md | 29 --- FURPS/core/rln_relay.md | 36 ---- FURPS/core/rln_sdk.md | 29 --- FURPS/core/rln_smart_contract.md | 35 ---- FURPS/core/store.md | 42 ---- FURPS/core/store_sync.md | 23 --- FURPS/core/waku_sdk.md | 41 ---- PROCESS.md | 27 ++- draft-roadmap/README.md | 165 --------------- draft-roadmap/TEMPLATE.md | 41 ---- draft-roadmap/acquire_first_10_customers.md | 46 ----- draft-roadmap/create_chat_sdk_mvp.md | 163 --------------- .../define_incentivisation_for_rlnaas.md | 29 --- .../deploy_rln_onchain_tree_on_l2_testnet.md | 90 -------- ...xtend_chat_sdk_with_group_conversations.md | 99 --------- .../formalize_and_expand_waku_web_apps.md | 163 --------------- ...foundation_for_communities_optimisation.md | 24 --- draft-roadmap/harden_rln_testnet.md | 96 --------- ...and_scaling_foundation_for_private_chat.md | 41 ---- .../improve_devex_api_twn_metrics_docs.md | 195 ------------------ draft-roadmap/incentivisation_follow_up.md | 30 --- ...nwaku_in_status_desktop_relay_mode_only.md | 50 ----- draft-roadmap/integrate_rln_with_waku_api.md | 149 ------------- .../introduce_e2e_reliability_in_status.md | 71 ------- .../introduce_mixnet_for_message_sending.md | 49 ----- draft-roadmap/mixnet_usage_improvements.md | 68 ------ draft-roadmap/rln_mainnet.md | 80 ------- .../streamline_dev_ex_local_dev_rust.md | 166 --------------- draft-roadmap/upgrade_nim_usage.md | 108 ---------- 57 files changed, 13 insertions(+), 3255 deletions(-) delete mode 100644 2025H1-SUMMARY.md delete mode 100644 2025H2-SUMMARY.md delete mode 100644 FURPS/README.md delete mode 100644 FURPS/TEMPLATE.md delete mode 100644 FURPS/application/chat_sdk.md delete mode 100644 FURPS/application/codex_archiving.md delete mode 100644 FURPS/application/erc-20_testnet_token_for_rln_deposit.md delete mode 100644 FURPS/application/forum.md delete mode 100644 FURPS/application/group_chat.md delete mode 100644 FURPS/application/js-waku.md delete mode 100644 FURPS/application/local_dev_rln_harness.md delete mode 100644 FURPS/application/local_web_dev_harness.md delete mode 100644 FURPS/application/network_metrics_tracker.md delete mode 100644 FURPS/application/nim_ffi.md delete mode 100644 FURPS/application/nwaku.md delete mode 100644 FURPS/application/p2p_reliability.md delete mode 100644 FURPS/application/qaku.md delete mode 100644 FURPS/application/rate_limit_manager.md delete mode 100644 FURPS/application/rln_membership_management.md delete mode 100644 FURPS/application/sds.md delete mode 100644 FURPS/application/segmentation.md delete mode 100644 FURPS/application/signal_network.md delete mode 100644 FURPS/application/status_communities.md delete mode 100644 FURPS/application/status_go.md delete mode 100644 FURPS/application/status_private_chats.md delete mode 100644 FURPS/core/incentivisation.md delete mode 100644 FURPS/core/light_push.md delete mode 100644 FURPS/core/mix.md delete mode 100644 FURPS/core/rendezvous.md delete mode 100644 FURPS/core/rln_relay.md delete mode 100644 FURPS/core/rln_sdk.md delete mode 100644 FURPS/core/rln_smart_contract.md delete mode 100644 FURPS/core/store.md delete mode 100644 FURPS/core/store_sync.md delete mode 100644 FURPS/core/waku_sdk.md delete mode 100644 draft-roadmap/README.md delete mode 100644 draft-roadmap/TEMPLATE.md delete mode 100644 draft-roadmap/acquire_first_10_customers.md delete mode 100644 draft-roadmap/create_chat_sdk_mvp.md delete mode 100644 draft-roadmap/define_incentivisation_for_rlnaas.md delete mode 100644 draft-roadmap/deploy_rln_onchain_tree_on_l2_testnet.md delete mode 100644 draft-roadmap/extend_chat_sdk_with_group_conversations.md delete mode 100644 draft-roadmap/formalize_and_expand_waku_web_apps.md delete mode 100644 draft-roadmap/foundation_for_communities_optimisation.md delete mode 100644 draft-roadmap/harden_rln_testnet.md delete mode 100644 draft-roadmap/hardening_and_scaling_foundation_for_private_chat.md delete mode 100644 draft-roadmap/improve_devex_api_twn_metrics_docs.md delete mode 100644 draft-roadmap/incentivisation_follow_up.md delete mode 100644 draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md delete mode 100644 draft-roadmap/integrate_rln_with_waku_api.md delete mode 100644 draft-roadmap/introduce_e2e_reliability_in_status.md delete mode 100644 draft-roadmap/introduce_mixnet_for_message_sending.md delete mode 100644 draft-roadmap/mixnet_usage_improvements.md delete mode 100644 draft-roadmap/rln_mainnet.md delete mode 100644 draft-roadmap/streamline_dev_ex_local_dev_rust.md delete mode 100644 draft-roadmap/upgrade_nim_usage.md diff --git a/2025H1-SUMMARY.md b/2025H1-SUMMARY.md deleted file mode 100644 index 864468e..0000000 --- a/2025H1-SUMMARY.md +++ /dev/null @@ -1,114 +0,0 @@ -# Execution Summary (Half-Year to June-2025): Waku - -## 🧭 Key Outcome(s) - -- Integrated nwaku in Status Desktop, progress towards decommissioning go-waku and pave the way for nim libraries to be integrated in any native desktop application. -- Stabilized store performance for Status Communities usage, understood the best usage patterns and design around limitations. -- Delivered an end-to-end reliability protocol adapted to Waku's restriction (RLN), applicable for large group chat (Communities) and extensible to small chats (1:1s); progressed on integration in Status Communities and delivered browser library. -- Understood the limitations of in-app, centralized, telemetry and delivered sustainable local metrics approach to analyse usage behaviour. -- Understood working and limitation of existing Status Private Chat protocol. Line out work to use Waku securely and at scale (RLN) and various security limitations and inadequacies -- Delivered new peer discovery protocol (rendezvous) to enable further scaling of Waku applications in terms of number of nodes and node capabilities. -- Integrated local DoS protection mechanisms to all Waku service node, fleet and Status Desktop apps. -- Waku integration started in at least 2 new projects: [chrom.ar](https://x.com/McGee_noodle/status/1915893489151447269), [Portrait](https://openinternetprotocol.com/networking-layer/waku); commitment from 2 other projects (stealth mode). -- Greatly improved RLN UX with onchain tree reducing resource costs on Waku Nodes, actioning lessons from previous dogfooding in The Waku Network. Deployed on Linea Sepolia. -- Defined and delivered first economic cost for RLN membership acquisition via stable coin deposits; including a web app for membership management to allow further dogfooding https://rln.waku.org/. -- Defined first incentivisation mechanism including payment and local reputation (PoC incomplete as of H1) -- Delivered 11 new Waku PoC Applications, as part of Waku internal hackathon (6) and Dev Rel effort to show how to build over Waku (5). This includes PoC Opchan Forum over Waku (FURPS not complete as of H1). -- Collaborated with Vac-QA to migrate status-lib chat testing to status-backend, and include more mobile environment scenarios to improve QA of Waku and Chat protocols. -- Delivered mixnet PoC (partial functionality) to increase sender anonymity, collaborating closely with Vac to mature nim-libp2p implementation. -- Delivered Waku Rust SDK PoC and handed over to a couple community projects. -- 3 winning projects at Web3Privacy hackathon in Berlin used Waku organically, Waku did not sponsor any prizes. - -## 🚩 Key Achievement(s) - -| Milestone Headline | Strategic Objective | Realised Value (0/10) | -|-----------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------|-----------------------| -| Direct Message Reliability | Improve p2p reliability of edge nodes | 8/10 | -| End-to-end reliability protocol | Provide agnostic protocol for reliability in group chats | 5/10 | -| Foundation for Communities Optimization | Simplify use of Waku to enable cheap optimization if needed | 8/10 | -| Scale up number of Communities | Introduce rendezvous as additional peer discovery mechanism | 1/10 | -| Nwaku in Status Desktop (Relay mode) | Demonstrate usage of nwaku/nim-library in Status Desktop/Golang Application | 10/10 | -| RLN Mainnet | Introduce economics to DoS protection smart contract and improve UX | 7/10 | -| Hardening and scaling foundations for private chats | Understand chat protocol to define roadmap, increase QA coverage for chat protocols | 7/10 | -| Upgrade Waku for the Web | Delivered end-to-end reliability protocol and improved peer management to Web applications | 5/10 | -| Logos Web apps | Decentralized Forum PoC, Qaku library, demonstration of Codex integration w/ Waku and more resilience to Web3 RPC outages for nwaku | 7/10 | -| Explore Peer Discovery Gap | Partial Mixnet PoC, dogfooding store sync for network message consistency | 6/10 | -| Debugging Tools | Local metrics dashboard to enable study of software behaviour and usage of Waku | 5/10 | -| BD - Acquire first 10 Customers | 1 additional project has been secured (#5), 2 more are to come out of stealth | 5/10 | - -## 🧩 Strategic Benefits Realised - -- Network DoS Protection: Improved UX and defined economic parameters -- P2P reliability: Improve recovery on network disconnection -- E2E reliability: Introduced scalable protocol for large group chat, that can extended to 1:1 chats. Both for native and browser applications. -- Nwaku in Golan application: Open the path to multi-language SDKs to fulfill needs of any application developers, including Logos Core. -- Various Waku Apps: teach them how to hunt by demonstrating potential Waku use-cases in different platforms and context. -- Mixnet PoC: Pave the path to increase anonymity property of Waku to a TOR-like (or above) level. - -## 🚩 Non-Realised Item(s) - -| Headline | Reason for not being realised | Carry(Yes/No) | -|---------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------|------------------| -| Local rate limit in Status Chat | No clear pathway to Status integration, new Chat SDK makes it irrelevant | No | -| Formal specs for Status chat protocols | New Chat SDK means new protocols, making proper documentation of existing protocols unnecessary | No | -| E2e reliability integration in Status Communities | Underestimation of effort to onboard developer to Nim, challenges to build FFI API (now solved), staffing issues | Yes | -| RLN audited and deployed on mainnet | Gross underestimation of the work needed, should have instead focus on needs to proceed with next dogfooding iteration | Yes with caveats | -| Incentivise running a Waku infrastructure | Onboarding to Nim, staffing issue which led to re-prioritizing RLN work instead of this | Yes | -| Global network metrics | Under-estimation + time to bootstrap collaboration with BI | Yes | -| Improved browser boostrap | TWN old RLN contract (no deposit) being spammed, blocking progress on this item | Yes | -| Browser simulations | Does not fit Vac-DST initial framework, increasing effort | Unclear | -| Formalize Codex integration with Waku | Unclear of benefit to progress beyond the current working integration in Qaku, refining needed, new FURPS to be proposed for H2 | Unclear | -| Mixnet PoC and MVP Roadmap | Dependency on Vac to complete libp2p-mixnet library | Yes | -| Nwaku in Status Mobile and Light Mode MVP | Underestimated work for desktop integration, reprioritized for H2 behind Chat SDK work | Yes | -| Debugging tools, log parser | Handed over to Vac-DST who already have similar log tool and just need to extend its functionality | No | -| Messaging API | Work was expected to only start in H1, which it did. Milestone was re-worked for H2 to better fit team resources | Yes | -| BD - Acquire first 10 Customers | Engineering focus on Status over community needs, meaning known gaps (e.g. Rust SDK) creating friction for integration. | Yes | - -## 🛠️ FURPS Execution Snapshot - -| Headline 1 | FURPS Doneness | Link | -|-----------------------------------------------------|--------------------------------------|---------------------------------------------------------------------------------------------------------------------| -| Direct Message Reliability | F(8/9) U(4/4) R(2/3) P(0/2) S(1/2) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1498f96fb65c8042b6d6d9fadb0ddcef | -| End-to-End Reliability Protocol | F(0/2) U(0/2) R(0/2) P(0/2) S(1/2) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1498f96fb65c803ca2acf006cd9aa6bd | -| Scale Up Number of Communities | F(2/2) U(2/2) R(2/2) P(0/1) S(2/3) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1498f96fb65c8017bf15c825908fca8d | -| RLN Mainnet | F(4/5) U(4/4) R(2/3) P(1/4) S(1/3) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1498f96fb65c80309c8dddc660273baa | -| Nwaku in Status Desktop (Relay mode) | F(2/2) U(1/2) R(0/2) P(0/1) S(1/2) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1498f96fb65c8012916fe63b1a244df1 | -| Incentivise running a Waku infrastructure node | F(0/6) U(0/3) R(0/3) P(0/1) S(0/1) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1498f96fb65c805e9345f2c1e59da62f | -| Foundation for Communities Optimization | F(1/4) U(1/3) R(1/1) P(2/3) S(0/1) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1858f96fb65c803cbc0ddb6cbde6282f | -| Hardening and scaling foundations for private chats | F(0) U(0) R() P(0) S(0) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1518f96fb65c801383e4c0a65b9ae5f5 | -| Global network metrics deliverable | F(0) U(0) R(0) P(0) S(0) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1518f96fb65c8014b396c39edf300af7 | -| Upgrade Waku for the Web | F(1/3) U(1/2) R(2/2) P(2/3) S(1/1) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1898f96fb65c80bf9614d520301a1e60 | -| Logos Web apps: Qaku | F(22/22) U(6/6) R(1/1) P(1/1) S(4/4) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1828f96fb65c80db9d98d5f2f8aaef52 | -| Logos Web apps: Forum | F(9/11) U(6/9) R(1/2) P(0/0) S(1/1) | https://www.notion.so/Community-Draft-Logos-Opchan-1c18f96fb65c8082921aedf43a040466 | -| Explore Peer Discovery Gap: Store Sync | F(1/1) U(2/2) R(1/1) P(1/1) S(1/1) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1508f96fb65c80d88942cbd0bfb91ce5 | -| Explore Peer Discovery Gap: Mixnet | F(0/5) U(0/0) R(0/0) P(0/0) S(0/2) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1898f96fb65c8045bc67c5fa7d806bd9 | -| Nwaku in Status Mobile and Light Mode | F(0) U(0) R(0) P(0) S(0) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1508f96fb65c808abb35d6242895d72e | -| Debugging Tools: log parser | F(0) U(0) R(0) P(0) S(0) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1508f96fb65c80a8abd6f5d37a273657 | -| Debugging Tools: local metrics | F(7/7) U(2/2) R(0/0) P(0/0) S(0/1) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1538f96fb65c8029b5b1fd0054c78bb4 | -| Messaging API | F(0) U(0) R(0) P(0) S(0) | https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00?source=copy_link#1578f96fb65c80c3afb3d6538a98139a | - -## Funding and Resources - -https://notes.status.im/E_bcw7cLR36QKI39k-PlMg# - -## ⚠️ Keys Risks & Controls - -| Risk | Control | -|----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------| -| FFI for Nim libraries | Drive collaboration, share knowledge and push more experience devs to jump in for assistance | -| Departure of RLN experts | Close collaboration with Vac-ACZ, dedicated 3 engineers to the task to work collaboratively and unblock each others. | -| Status' undefined strategy | Focus on foundational work that has value no matter the direction, building in a modular manner to deliver re-usable components over specialized delivery. | -| RLN's challenging UX | Focus on tight feedback loops, push for integration wherever possible (eg Status AND web apps), | -| Store centralization | Reduce importance of store with e2e reliability, tweak API to avoid usage of store as CDN by developers, continue progressing on Codex integration. | - -## ✅ Key Observations - -- "RLN Mainnet" was too premature of a goal, the focus has shifted to focus on the next iteration of dogfooding (to be started soon). Next goals will be pushing on Status L2 Sepolia and continue iterating on UX, to provide accompanying library to Chat SDK. -- We aimed to be flexible with Status' dynamic strategy, by dropping items whose value became unclear, and focusing on modular, long-term, sustainable and re-usable work. -- It was too early to formalize integration with Codex. Nonetheless, Waku apps produced by app/chat team have Codex integration and dogfooding of Waku x Codex will continue. -- We attempted to put in place a process with Vac-QA and Vac-DST respectively "certify" `R`s and `P`s. While good on principle, the tracking processes are not there. -- It was a first round of planning with FURPS. Lessons have been learned and being applied for H2. -- The Waku internal hackathon was a great experiment to identify use-case but also improvements to the Waku dev ex. With a focus on building (developer) tribes, its strategic value has increased. -- Milestones that involved breaking changes were dragged across several Status release; need to review how this is planned to not postpone milestone completion dates by months. -- Some research items took time to wrap-up, sort bindings, etc. Will discuss with the team on how we can be better are getting research PoC ready for dogfooding. -- With a refocus on community, need to improve tracking of BD results. \ No newline at end of file diff --git a/2025H2-SUMMARY.md b/2025H2-SUMMARY.md deleted file mode 100644 index 0837519..0000000 --- a/2025H2-SUMMARY.md +++ /dev/null @@ -1,138 +0,0 @@ -# Milestones Presentation (Half-Year to Dec-2025): Waku - -## 🧭 Key Outcome(s) of Vision you are supporting - -- Developers can use a Chat SDK to enable secure conversations, for one-to-one chat and private groups, that scales over Waku, including RLN. -- Onboarding on Waku is improved by simplifying the API of the Waku SDK, including RLN, as well as other developer experience improvements. -- Several applications PoC are built over Waku to demonstrate how to use Waku to developers. -- Progress on privacy and sustainability tracks with research on mixnet and incentivisation. -- Deliver nwaku in mobile as the last step to deprecating go-waku. - -Strategy changes: - -- New Chat protocol over adapting existing code and protocol ([justification](https://forum.vac.dev/t/chatsdk-motivations/501)) -- Prioritized simplifying Waku API, to enable Chat SDK but also "make it easy to integrate" -- Prioritized RLN SDK, to use with Chat SDK and have early RLN integration in the Chat stack (this time) -- De-prioritized nwaku on mobile in favour of Waku SDK and RLN SDK -- Increased commitment to build applications over Waku (Web and Logos Core), to "teach them how to hunt" -- Introduced Developer Experience items: to support Chat SDK, and "make it easy to integrate" -- Nim Usage Improvement: increased priority to support new chat sdk, and "make it easy to contribute" -- De-scoped any Communities or existing Status chat protocol work, apart from e2e reliability as it is a re-usable block for Chat SDK. -- RLN Mainnet is a long term goal, focus instead of smaller, achievable items that enable integration and dogfooding of RLN. - -## 🚩 Proposed Milestones(s) - -| Milestone Headline | Strategic Objective | Capacity✱ | Business Val (0/10) | FURPS | -|-------------------------------------------------------------------------------------------------------|---------------------------------------------------------|-----------|---------------------|--------| -| [Define Incentivisation for RLNaaS](draft-roadmap/define_incentivisation_for_rlnaas.md) | Logos Vision: Core Values Alignment | 0.4 | 7 | FURPS_ | -| [Improve DevEx: API, TWN, Metrics, Docs](draft-roadmap/improve_devex_api_twn_metrics_docs.md) | Logos Movement Community Enabling via Dev-X + Telemetry | 2.1 | 10 | FURPS_ | -| [Introduce mixnet for message sending](draft-roadmap/introduce_mixnet_for_message_sending.md) | Logos Vision: Core Values Alignment | 0.7 | 4 | F___S_ | -| [Formalize and Expand Waku Web Apps](draft-roadmap/formalize_and_expand_waku_web_apps.md) | Logos Movement Community Enabling | 2.1 | 7 | FURPS_ | -| [Create Chat SDK MVP](draft-roadmap/create_chat_sdk_mvp.md) | Logos Movement Module Build Out | 2.1 | 8 | FURPS+ | -| [Integrate RLN with Waku API](draft-roadmap/integrate_rln_with_waku_api.md) | Logos Movement Module Build Out | 1.7 | 9 | FUR_S+ | -| [Streamline DevEx: Mobile, Rust and Web dev](draft-roadmap/streamline_dev_ex_local_dev_rust.md) | Logos Movement Community Enabling via Dev-X | 1.2 | 7 | FU__S+ | -| [Extend Chat SDK with Group Conversations](draft-roadmap/extend_chat_sdk_with_group_conversations.md) | Logos Movement Module Build Out | 1.4 | 8 | F_RPS+ | -| [Incentivisation Follow-up Outline](draft-roadmap/incentivisation_follow_up.md) | Logos Vision: Core Values Alignment | 3 | 7 | TBD | -| [Nim Usage Improvements](draft-roadmap/nim_usage_improvements.md) | Logos Movement Community Enabling: Dev Journey | 0.5 | 5 | FU____ | -| [BD - Acquire first 10 customers](draft-roadmap/acquire_first_10_customers.md) | Logos Movement Community Enabling: Growth | 2.1 | 7 | N/A | - -✱ Capacity: How many people assigned in a 6 months window. -- 3.5 are applied across all milestones (Franck, Aaron, 1/2 Hanno, Tanya), 1 core research cc was awol for 5 weeks. - -## 🧩 Strategic Benefits Realisable from coming Half-Year (Top 5) - -- **Logos Vision - Core Values Alignment**: Progress on making Waku sustainably scalable, resilient, private and censorship-resistant. Increase anonymity properties. -- **Logos Movement Community Enabling**: Simplify APIs to reduce cost of onboarding and deliver them in demanded languages, build application as examples and demonstrations of the technology, provide telemetry to track success and improve Dev-X for contributors. -- **Logos Movement Module Build Out**: Deliver a Chat SDK that can scale over Waku, supporting secure one-to-one and group chats, with early integration of DoS protection. - -## 🚩 Key Cross Project Alignments (Top-5) - -| Project / Community | Specific | Confirmed with Project(Yes/No) | -|---------------------|-----------------------------------------------------------------|--------------------------------| -| Status Application | Create Chat SDK MVP, Extend Chat SDK, Integrate RLN w/ Waku API | Yes | -| Logos Core | Formalize and Expand Waku Web Apps: Logos core app | Yes | -| Logos Movement | Formalize and Expand Waku Web Apps: Forum | Yes | -| Status Application | Streamline DevEx: Mobile | Yes | -| Codex | Formalize and Expand Waku Web Apps: More Codex Integrations | Yes | -| Status L2 | Integrate RLN With the Waku API: Deploy SC on Sepolia | Yes | - - -## 🚩 Key Cross Project/Shared Service Dependency (Top-5) - -| Project | Specific | Confirmed with Project(Yes/No) | -|----------------|-----------------------------------------------------------------------------------------|--------------------------------| -| Vac-DST | Proceed with status-backend benchmarks for nwaku and new chat sdk migration | Yes | -| Vac-QA | Proceed with status-backend non-regression testing for nwaku and new chat sdk migration | Yes | -| Status Network | Support usage of Sepolia | Yes | -| Vac-ACZ | Assist with using zerokit in the Browser | Yes | -| Vac-ACZ | Assist in determining best libraries to use for cryptography in new Chat SDK | Yes | -| Vac-ACZ | mix protocol development | Yes | -| Infra | Maintain Waku fleet, apply config changes requests, deploy new nodes for metrics | Yes | -| Vac-SC | Support of functional extension of RLN Smart Contract | Yes | - -## Funding and Resources (By Strategic Objective) - -### Rolled-Up By Strategic Objective - -https://notes.status.im/E_bcw7cLR36QKI39k-PlMg# - -3.5 are applied across all milestones (Franck, Aaron, 1/2 Hanno, Tanya), 1 core research cc is awol. -Not full 6 months planned, see above for contingency. - -| Strategic Objective | People† | -|--------------------------------------|---------| -| Logos Vision - Core Values Alignment | 4 | -| Logos Movement Community Enabling | 8 | -| Logos Movement Module Build Out | 5 | - -† Rounded to express relative allocation to the different objectives. - -### Budget Consultation - -| Headline Activity | Status | -|-------------------------|-----------------------------------| -| Financial Review Status | [new,renew,review,approved] | -| Finance Comments | please add comment rows as needed | | - -### By Resource - -| Resource Headline Item | People | Comment | -|-------------------------|--------|-----------------------------------------------| -| Present Resource | 20 | | -| Additional Resource Ask | 1 | backfill - Logos Movement Community Enabling‡ | -| PeopleOps Informed | Yes | | - -‡ This would enable tackling following deliverables earlier: - -- Porting new chat protocols to the browser -- NodeJS SDK, second most demanded SDK - and stabilizing usage of JS in desktop and mobile -- Dev Ex improvement on Web API (e.g. local first message caching) - -### PeopleOps Consultation - -| Review Status | [new,renew,review,approved]| -| Review Comments | [new,renew,review,approved]| - -## ⚠️ Keys Risks Identified & Controls - -| Risk | (Accept, Own, Mitigation) | -|-------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Cryptographic primitives in Nim | Expect to nim-wrap existing Rust/C libraries - will consult with Vac to lean towards libraries already used in Nim/IFT ecosystem. | -| Timeline uncertainties for research items | Focus on iterative delivery of usable deliverables, to get early feedback and direction and lower cost of failure. | -| Nim ecosystem and tooling maturity | New initiative to foster Nim community within IFT, work closely with Vac/Nim re tooling, block time to migrate to Nimble. | -| RLN UX | Integrate in web apps, continue dogfooding and iteration, close collaboration with Status. | -| Readiness of status-go for Chat SDK integration | Weekly sync up on chat sdk and status-go refactoring topics between Waku and Status teams, collaborative planning done to align goals and API. | -| nwaku performance in Status/Chat context | benchmarks are still wip, we are prepared for potential performance improvement needs in mobile context, as it is a critical point for Status application. | - -## ✅ Key Observations - -- Exciting 6 months ahead with clear path on how to deliver value to both Status and the Logos Community with the same effort. -- Improving work tracking with Vac-DST/Vac-QA, discussion is ongoing to better integrate Waku FURPS in Vac planning. -- We now have a breaking change strategy for Status items. -- Aiming more of a team rally behind milestones, dev milestones are now larger and contain more items that can be done in parallel, so that most of the team work on same milestone together. -- Focus on more frequent milestone delivery, by avoiding intra-dependency of items in milestone. -- Increasing collaboration between research and engineering teams, to ensure early unblocking and neat wrap-up of items. -- The "Waku (Messaging) API" was initially a tidy up task, as Waku was already integrated in Status. With a focus towards Chat SDK and growing a developer community, it became an urgent-important item. -- Intent to continue internal hackathon initiative with 2 more occurrences in 2025 (tentatively July and October). -- Will attempt to secure one grant with minimum extra commitments (foreseeable commitments are wrapper for a specific language or writing RLN smart contract in non-EVM language). -- Moving one js-waku developer to chat/app team to develop Forum/OpChan app and library for H2. \ No newline at end of file diff --git a/FURPS/README.md b/FURPS/README.md deleted file mode 100644 index 541d221..0000000 --- a/FURPS/README.md +++ /dev/null @@ -1,44 +0,0 @@ -# Waku FURPS - -Some FURPS statement may contain the following postfixes: - -- (**Vac-DST**): Simulations to attest of this statement. -- (**Vac-QA**): Additional test coverage by Vac-QA to verify this statement. - -All Waku core FURPS are assumed to be deployed and enabled on The Waku Network. - -## Core Protocols - -- [Incentivisation](core/incentivisation.md) -- [Light Push](core/light_push.md) -- [Mix](core/mix.md) -- [Rendezvous](core/rendezvous.md) -- [RLN Relay](core/rln_relay.md) -- [RLN SDK](core/rln_sdk.md) -- [RLN Smart Contract](core/rln_smart_contract.md) -- [Store](core/store.md) -- [Store Sync](core/store_sync.md) -- [Waku SDK](core/waku_sdk.md) - -## Application Protocols - -- [Chat SDK](application/chat_sdk.md) -- [Codex Archiving](application/codex_archiving.md) -- [Forum](application/forum.md) -- [Group Chat](application/group_chat.md) -- [js-waku](application/js-waku.md) -- [Local Dev RLN Harness](application/local_dev_rln_harness.md) -- [Local Web Dev Harness](application/local_web_dev_harness.md) -- [Network Metrics Tracker](application/network_metrics_tracker.md) -- [nwaku](application/nwaku.md) -- [P2P Reliability](application/p2p_reliability.md) -- [Qaku](application/qaku.md) -- [Rate Limit Manager](application/rate_limit_manager.md) -- [RLN Membership Management](application/rln_membership_management.md) -- [Scalable Data Sync](application/sds.md) -- [Segmentation](application/segmentation.md) -- [Signal Network](application/signal_network.md) -- [Status Communities](application/status_communities.md) -- [status-go](application/status_go.md) -- [Status Private Chats](application/status_private_chats.md) -- [ERC-20 Testnet Token for RLN Deposit](application/erc-20_testnet_token_for_rln_deposit.md) \ No newline at end of file diff --git a/FURPS/TEMPLATE.md b/FURPS/TEMPLATE.md deleted file mode 100644 index 4c2a722..0000000 --- a/FURPS/TEMPLATE.md +++ /dev/null @@ -1,25 +0,0 @@ -# {Feature Name} FURPS - -## Functionality - -1. ... - -## Usability - -1. ... - -## Reliability - -1. ... - -## Performance - -1. ... - -## Supportability - -1. ... - -## + (Privacy, Anonymity, Censorship-Resistance, Deployments) - -1. ... \ No newline at end of file diff --git a/FURPS/application/chat_sdk.md b/FURPS/application/chat_sdk.md deleted file mode 100644 index 8258f87..0000000 --- a/FURPS/application/chat_sdk.md +++ /dev/null @@ -1,39 +0,0 @@ -# Chat SDK - -## Functionality - -1. Accounts can be created in a permission-less way, to communicate on the network. -2. Accounts can send messages to conversations with one other participant. -3. All conversations benefit from forward secrecy and post-compromise security. -4. Sender gets confirmation of message reception by recipient device. -5. Developers can create their own payload types or use supplied basic types. -6. Sdk contains a default message database for developers. -7. Sdk contains a default secrets database for developers. - -## Usability - -1. Secure session setups are non-interactive, allowing messages to be sent without waiting for the recipient's device to come online. -2. Conversations are initiated by sharing invite links out-of-band. -3. Minimal example of the ChatSDK is no more than 25 lines of code. - -## Reliability - -1. Participants in a conversation can eventually determine whether they missed messages. - -## Performance - -1. 10K active SDK users on a single shard add no more than an average of 10Mbps to the total bandwidth; based on clients generating 100 character chat messages, 4 times per minute. - -## Supportability - -1. Messaging integrates RLN-like rate limit, limiting outbound messages per epoch. -2. Payload definitions are versioned to support future protocol updates. -3. library can be used in Go applications; available on pkg.go.dev. -4. library can be used in Rust applications; import via git path. - -## + (Privacy, Anonymity, Deployments) - -1. Non-participants in the conversation cannot correlate individual messages to a sender. -2. Non-participants in the conversation cannot correlate conversation to participants. -3. Network observers cannot aggregate account holder activity. -4. Nimble package manager is used to build. \ No newline at end of file diff --git a/FURPS/application/codex_archiving.md b/FURPS/application/codex_archiving.md deleted file mode 100644 index 090c86e..0000000 --- a/FURPS/application/codex_archiving.md +++ /dev/null @@ -1,25 +0,0 @@ -# Codex Archiving PoC FURPS - -## Functionality - -1. Any end user can publish a backup snapshot of the entire SDS log to Codex. -2. End user (may be privileged) can publish the corresponding Codex CID with metadata over Waku to a dedicated snapshot content topic. -3. Participants can query the Waku snapshot topic for the latest CID. -4. Participants can retrieve the archived messages from Codex. -5. Participants can perform a store Query for more recent messages following the snapshot timestamp and SDS state. - -## Usability - -1. Workflow should be conceptually identical, whether the Codex interaction is via a local node or Codex gateway. -2. Publishing or retrieving via Codex should be optional. - -## Reliability - -## Performance - - -## Supportability - -1. Developers can use this protocol in web applications. - -## + (Privacy, Anonymity, Deployments) diff --git a/FURPS/application/erc-20_testnet_token_for_rln_deposit.md b/FURPS/application/erc-20_testnet_token_for_rln_deposit.md deleted file mode 100644 index 62fd249..0000000 --- a/FURPS/application/erc-20_testnet_token_for_rln_deposit.md +++ /dev/null @@ -1,22 +0,0 @@ -# ERC-20 Testnet Token for RLN Deposit - -## Functionality - -1. Contract owner can mint tokens to any address for free. -2. White-listed wallet addresses can mint tokens to any address for free. -3. Contract owner can add or remove wallet addresses to the white-list. -4. Eth (Sepolia) is burnt to mint tokens to any address. - -## Usability - -1. Token name is `TST`. -2. Usage of Metamask Faucet (usually 0.1 Linea Sepolia Eth) should enable enough `TST` token minting to acquire 2-3 RLN memberships. - -## Reliability - -## Supportability - -## + (Privacy, Anonymity, Censorship-Resistance, Deployments) - -1. Deployed on Linea Sepolia. -2. Used as ERC-20 deposit token for Linea Sepolia RLN smart contract deployment. \ No newline at end of file diff --git a/FURPS/application/forum.md b/FURPS/application/forum.md deleted file mode 100644 index 46bee15..0000000 --- a/FURPS/application/forum.md +++ /dev/null @@ -1,55 +0,0 @@ -# Waku Forum FURPS - -## Functionality - -1. Users can identify themselves by signing with their Bitcoin key. -2. Only users owning Logos ordinal or an ENS can create a cell. -3. Any user (authenticated or not) can see the content; basic encryption functionality. -4. Existing cells can be listed. -5. Cell can be created with a name, description, icon; icon size will be restricted; created is solo admin. -6. Post can be created in a cell with a title and body; text only. -7. Comments can be made on posts and other comments; text only. -8. Posts can be upvoted. -9. Users can setup a call sign; bitcoin identity operator unique name - remains - ordinal used as avatar; OP number out-of-scope (not onchain). -10. Cell admin can mark posts and comments as moderated. -11. Cell admin can mark users as moderated. -12. Users can identify themselves by signing with their Web3 key. -13. Posts, comments and cells have a relevance index, which can be used to order or hide them in the UX. -14. The relevance index is lowered for post and comments which are moderated, or from a moderated user. -15. The relevance index is increased if the author owns an ENS or Logos ordinal. -16. The relevance index is increased if the post or comment is upvoted by an ENS or Logos ordinal owner. -17. The relevance index is increased if the post has a comment from an ENS or Logos ordinal owner. -18. Anonymous users can upvote, comments and post. - -## Usability - -1. A user can see all topics through all cells. -2. A user can see the number of active members per cell; deduced from retrievable activity. -3. Users can bookmark posts and topics; local only. -4. Users can sort topics per new or top. -5. The ordinal picture and information are used to identify user, in addition to the custom nickname. -6. Moderated users, comments, and posts are hidden. -7. Users do not need to sign every message with their wallet. -8. Users do not need any software beyond a browser to use the forum. -9. This includes a prototype UI to dogfood the PoC; Nice UI will be handled by Comms Hubs team. -10. A library with clear API is produced to enable frontend developers to use it with a nice UI. -11. ENS holders can choose to use an ENS for display purposes. -12. The relevance index is used to push most relevant posts and comments on top. - -## Reliability - -1. Data is ephemeral; and will disappear after some time; No effort spent on topic or comment durability, out of scope for now. -2. End-to-end reliability strategy will be employed to enable app instance to know about missing messages and attempt to retrieve them. - -## Performance - -None - -## Supportability - -1. Web app; bitcoin and ethereum wallets optional. - -## + (Privacy, Anonymity, Deployments) - -1. A centralised API is used to get Bitcoin ordinal information. -2. The Forum uses The Waku Network. \ No newline at end of file diff --git a/FURPS/application/group_chat.md b/FURPS/application/group_chat.md deleted file mode 100644 index 69acd0f..0000000 --- a/FURPS/application/group_chat.md +++ /dev/null @@ -1,31 +0,0 @@ -# Group Chat - -## Functionality - -1. Accounts can receive a message in multiple locations (e.g. devices) by registering new installations. -2. Accounts can view and remove installations as needed. -3. Accounts can create GroupChats between multiple accounts. -4. Participants can set a group name and description for all participants in the group. -5. Account can view all provisioned installations. -6. Account can revoke other installations in case of a lost device. - -## Usability - -## Reliability - -1. Group Participants in a conversation can tell if a message is missing, and who sent it. - -## Performance - -1. The number of network messages for a single outbound group message does not scale with the number of group members. - -## Supportability - -1. Developers can create group conversations from Go Applications; available on pkg.go.dev. -2. Developers can create group conversations from Rust Applications; available on crates.io. -3. SDK can be instantiated with a RLN-enabled Waku node. - -## + (Privacy, Anonymity, Deployments) - -1. Non-participants cannot correlate a group conversation to any of its participants. -2. No identifying information is visible when registering an installation. \ No newline at end of file diff --git a/FURPS/application/js-waku.md b/FURPS/application/js-waku.md deleted file mode 100644 index 47e2d6b..0000000 --- a/FURPS/application/js-waku.md +++ /dev/null @@ -1,17 +0,0 @@ -# JS-Waku FURPS - -## Functionality - -## Usability - -## Reliability - -1. From an operating state, a node can resume transmitting messages within 1 second after disconnection; in a network with 1 bootstrap node, 100 service nodes and 500 browser nodes (**Vac-DST**) - -## Performance - -1. From a cold start, a node can start transmitting messages within 5 seconds; in a network with 1 bootstrap node, 100 service nodes and 500 browser nodes (**Vac-DST**) - -## Supportability - -## + (Privacy, Anonymity, Deployments) diff --git a/FURPS/application/local_dev_rln_harness.md b/FURPS/application/local_dev_rln_harness.md deleted file mode 100644 index f86c6fb..0000000 --- a/FURPS/application/local_dev_rln_harness.md +++ /dev/null @@ -1,23 +0,0 @@ -# Local Dev RLN Harness FURPS - -## Functionality - -1. Runs local Ethereum environment. -2. Deploys ERC-20 and RLN smart contract. -3. Utility to fund wallet addresses with necessary tokens for deposit for RLN membership registration. - -## Usability - -1. Developer only need to run a script to setup local blockchain environment. -2. Developers can run documented RPC calls to fund wallet addresses. -3. Developers can run documented RPC calls to interact with RLN smart contract. - -## Reliability - -## Performance - -## Supportability - -1. Linux and Mac development environments. - -## + (Privacy, Anonymity, Deployments) diff --git a/FURPS/application/local_web_dev_harness.md b/FURPS/application/local_web_dev_harness.md deleted file mode 100644 index 65f303f..0000000 --- a/FURPS/application/local_web_dev_harness.md +++ /dev/null @@ -1,24 +0,0 @@ -# Local Web Dev Harness FURPS - -## Functionality - -1. Runs local Waku node to test Web application without relying on external connectivity. -2. js-waku runs in NodeJS for testing and CI purposes. - -## Usability - -1. Developer only need to run a script or preset to start local Waku node and have their web app connect to it. -2. Potential WSS/HTTPS issues are worked around so that developers do not need to manually generate or import SSL certificates. -3. There is an easy option for the developer to bootstrap and connect to local node, instead of external peers. - -## Reliability - -## Performance - -## Supportability - -1. Linux and Mac development environments. -2. Local network without RLN. -3. Chrome and Firefox browsers. - -## + (Privacy, Anonymity, Deployments) diff --git a/FURPS/application/network_metrics_tracker.md b/FURPS/application/network_metrics_tracker.md deleted file mode 100644 index d740bd1..0000000 --- a/FURPS/application/network_metrics_tracker.md +++ /dev/null @@ -1,39 +0,0 @@ -# Network Metrics Tracker FURPS - -## Functionality - -1. Metrics that can be learned from network observations are available -2. Display number of nodes discovered over discv5, by shard -3. Display number of nodes successfully connected to, by shard and user agent, in last hour, day, week -4. Display number of light protocol clients fleet nodes had a inbound connection of, by libp2p protocol, user agent, libp2p transport, and shard, in last hour, day, week; using unique peer id as identifier -5. Number of messages unique messages seen, by shard -6. Inbound and outbound bandwidth, by shard -7. Number of different content topics in last hour, day and week; considering full content topic and application name. -8. Average and max message size by shard -9. Messages stored by fleet store nodes: total size, number, oldest timestamp, by shard - -## Usability - -1. Metrics above are available publicly for the network of major integrations (Status, RAILGUN, TWN). - -## Reliability - -1. Metrics should be available 90% of the time. - -## Performance - -1. The data is updated at least hourly -2. At least 3 months of data is available - -## Supportability - -1. Grafana dashboards -2. Some metrics may be retrieved by a Waku monitor node with aggressive parameters, other from existing fleet nodes; - this includes running limited fleet nodes for other networks. - -## + (Privacy, Anonymity, Deployments) - -1. No IP or Peer Ids are tracked or displayed. -2. Dashboard deployed for The Waku Network -3. Dashboard deployed for Status Waku Network -4. Dashboard deployed for RAILGUN Waku Network \ No newline at end of file diff --git a/FURPS/application/nim_ffi.md b/FURPS/application/nim_ffi.md deleted file mode 100644 index cb865dd..0000000 --- a/FURPS/application/nim_ffi.md +++ /dev/null @@ -1,31 +0,0 @@ -# Nim-FFI FURPS - -## Functionality - -1. Provides the core logic needed to expose any synchronous or asynchronous Nim library to a C-FFI library. - -## Usability - -1. Introduce new pragma definitions, such as `{.ffi.}`, to appropriately annotate types and procedures. -2. Any Nim project can use it and can be installed using Nimble, - similarly to how nim-chronos is imported. -3. The interaction with the exposed C library can be done using JSON. -4. The interaction with the exposed C library can be done using protobuf. - -## Reliability - -1. Nim-FFI does not leak memory. -2. The exposed C library never hangs when working asynchronously. - -## Performance - -## Supportability - -1. The exposed C library can be used in Golang. -2. The exposed C library can be used in Rust. -3. The exposed C library can be used in Python. - -## + (Privacy, Anonymity, Deployments) - -1. `nwaku` repository uses `nim-ffi` to expose the existing `libwaku` functionality. - diff --git a/FURPS/application/nwaku.md b/FURPS/application/nwaku.md deleted file mode 100644 index 1cc6dd0..0000000 --- a/FURPS/application/nwaku.md +++ /dev/null @@ -1,34 +0,0 @@ -# nwaku FURPS - -## Functionality - -1. nwaku can be compiled as a library, `libwaku`. -2. libwaku exposes c-bindings. -3. Metrics can be enabled in libwaku. - -## Usability - -1. Uses nimble for package management and build. -2. Can be imported as a nim library using nimble. - -## Reliability - -1. ... - -## Performance - -1. ... - -## Supportability - -1. libwaku, wakunode2 can build on Windows -2. libwaku supports relay node functionalities. -3. TCP transport is supported for peer-to-peer message routing connections. -4. QUIC transport is supported for peer-to-peer message routing connections. -5. libwaku builds on Android and iOS -6. libwaku support edge node functionalities. - -## + (Privacy, Anonymity, Deployments) - -1. Every nwaku release includes a Windows binary for wakunode2. - \ No newline at end of file diff --git a/FURPS/application/p2p_reliability.md b/FURPS/application/p2p_reliability.md deleted file mode 100644 index 592be05..0000000 --- a/FURPS/application/p2p_reliability.md +++ /dev/null @@ -1,22 +0,0 @@ -# P2P Reliability - -## Functionality - -1. Improves probability of message propagation through redundant publishing and receiving. -2. Enables detection and remedy of message losses between peers using Store or Filter based reliability strategies. -3. Enhances Light Push reliability through service node pooling, redundant publishing, and failure detection. -4. Improves Filter reliability through redundant subscriptions and subscription health monitoring. - -## Usability - -1. Provides feedback on message delivery status leveraging store protocol. -2. Automatically handles reconnection and retransmission when failures are detected. - -## Reliability - -## Performance - -## Supportability - -1. Within browser environments (edge node mode) -2. Integrated in Status applications \ No newline at end of file diff --git a/FURPS/application/qaku.md b/FURPS/application/qaku.md deleted file mode 100644 index 74dffbe..0000000 --- a/FURPS/application/qaku.md +++ /dev/null @@ -1,54 +0,0 @@ -# Qaku FURPS - -## Functionality - -1. An owner can create public Q&As. -2. An owner can create a private Q&As where only selected participants can read the data, and participate. -3. Owner can close a Q&A, no more questions or answers are accepted. -4. Owner can schedule a Q&A to be opened in the future, allowing questions and answer only from then. -5. Owner can answer questions from a Q&A, an answer is attached to one and only one question; multiple answers per question are allowed. -6. Owner can moderate user questions by hiding them to users, such questions are still accessible as “moderated” to owner. -7. Owner can add a poll to an existing Q&A. -8. Users can answer polls, limited to one answer per poll per user. -9. Owners can close poll, stopping further answers to be accepted. -10. Owner can add and delete admins for a given Q&A. -11. Admins have same permissions as owners on Q&A, apart from adding and deleting admins. -12. All users are identified by an in-browser key pair generated upon first interaction. -13. Users can post questions on a Q&A they have access to. -14. Questions have a published timestamp, upvotes, related answers properties. -15. Users can upvote questions (1 upvote per user). -16. Users can export & import their in-browser identifying key pair (e.g. to multiple devices). -17. Owner have a list of Q&As they created. -18. Users have a list of Q&As they visited. -19. Owner can use ENS to prove they created a given Q&A. -20. Owner’s app backups data on Codex via local Codex node. -21. Data is automatically retrieved from Codex via local Codex node. -22. User can retrieve data from Codex network if missing from Waku (PoC). - -## Usability - -1. Users participating in a Q&A only need the Q&A ID and password (if encrypted). -2. Web3/wallet integration is optional for developers. -3. Developers do not need to understand or know about Waku to integrate Qaku. -4. Developers and Users do not need to understand Codex beyond local node setup to integrate Qaku. -5. Qaku Library API informs whether an outbound message (question, answer, poll, vote, etc) irremediably failed to send. -6. Qaku Library API informs whether an inbound message is missing from a Q&A. -7. The Qaku JS library contains all the functionality and exposes clean API. - -## Reliability - -1. The app connects within 30 seconds of starting. - -## Performance - -1. A user can load previously visited Q&A with a max of 100 questions+responses within 10 seconds. - -## Supportability - -1. The Qaku JS library works in both browser and NodeJS environments, desktop and mobile browser. -2. Codex local node related features are only supported on desktop. -3. Retrieval of data from Codex network from browser mobile and desktop (PoC). - -## + (Privacy, Anonymity, Deployments) - -1. Qaku's deployment uses The Waku Network \ No newline at end of file diff --git a/FURPS/application/rate_limit_manager.md b/FURPS/application/rate_limit_manager.md deleted file mode 100644 index 34042e8..0000000 --- a/FURPS/application/rate_limit_manager.md +++ /dev/null @@ -1,36 +0,0 @@ -# Rate Limit Manager FURPS - -## Functionality - -1. Rate limit the number of messages passed to the delivery service. -2. The rate limit is set in a form of number of messages per epoch; same format as RLN Relay. -3. Tracks current quota and usage. -4. Messages can be flagged with three priorities level: critical, normal, optional. -5. When remaining message quota is low, critical messages are sent, normal messages are queued and optional messages are dropped. -6. When message quote is exhausted, critical messages are queued on top, normal messages are queued, optional messages are dropped. -7. Can consume RLN API to access rate limit and current quota. - -## Usability - -1. Developer can mark messages with relevant priority. -2. Developer can pass messages by batch; with an all-or-none sending strategy. -3. Developer can access total quota and remaining quota values. -4. Message status is available to the developer (queued, dropped, passed to delivery service). - -## Reliability - -1. Errors and status from the underlying delivery service are available to the developer. -2. Queued messages are persisted across restart. -3. Quota status is persisted across restart. - -## Performance - -1. ... - -## Supportability - -1. Nim library. - -## + (Privacy, Anonymity, Deployments) - -1. Nimble package manager is used to build. \ No newline at end of file diff --git a/FURPS/application/rln_membership_management.md b/FURPS/application/rln_membership_management.md deleted file mode 100644 index dbff9d4..0000000 --- a/FURPS/application/rln_membership_management.md +++ /dev/null @@ -1,34 +0,0 @@ -# RLN Membership Management FURPS - -## Functionality - -1. Can generate RLN credentials. -2. Can insert RLN membership in smart contract, with accompanying deposit. -3. Can extend RLN membership on smart contract. -4. Can withdraw deposit from smart contract. -5. Membership credentials are encrypted by default on local disk. - -## Usability - -1. RLN membership details can be exported and imported. -2. Deployment details (address, chain id) are persisted by library and in exports. - -## Reliability - -1. Import and exports are interoperable across all implementations. - -## Performance - -1. ... - -## Supportability - -1. Browser application, using web3 wallet browser extensions. -2. library can be used in Go applications; available on pkg.go.dev. -3. library can be used in Rust applications; import via git path. - -## + (Privacy, Anonymity, Deployments) - -1. Web version deployed on https://rln.waku.org -2. Available for Linea Sepolia Testnet contracts. -3. Proof generation and validation is out of scope for this FURPS. \ No newline at end of file diff --git a/FURPS/application/sds.md b/FURPS/application/sds.md deleted file mode 100644 index a2ad43d..0000000 --- a/FURPS/application/sds.md +++ /dev/null @@ -1,32 +0,0 @@ -# Scalable Data Sync - -## Functionality - -1. Ability to know that a published message has been received by at least one member of the group (and could therefore eventually be retrieved by other members). -2. Ability for participants to know when they have missed a message -3. Ability to resend unacknowledged messages -4. Ability to retrieve missed messages using Waku store protocol - -## Usability - -1. When sending a message to a large group, the application learns whether it was received by other group members. -2. When being part of a large group, the application is able to know whether they are missing messages. -3. When being part of a large group, the application is able to retrieve missed messages. - -## Reliability - -1. When sending a message in a group, the publisher can ascertain the message was received by at least one recipient **(Vac-QA)**. -2. When receiving messages in a group, the receiver can ascertain most missed messages by receiving one recent message from the group. **(Vac-QA)** - -## Performance - -Assuming messages in a group are sent at least every `S` seconds, with `S` being no longer than `5 sec`. - -1. When sending a message in a group, the publisher can ensure the message was received by at least one recipient within `S` seconds **(Vac-DST)**. -2. When receiving messages in a group, the receiver can detect 90% of missed messages within `3*S` seconds. -3. When receiving messages in group, the receiver can reach eventual consistency within `6*S` seconds **(Vac-DST)**. - -## Supportability - -1. Applied to Communities channels on Status Desktop -2. For Web apps as a developer library. \ No newline at end of file diff --git a/FURPS/application/segmentation.md b/FURPS/application/segmentation.md deleted file mode 100644 index c6ac752..0000000 --- a/FURPS/application/segmentation.md +++ /dev/null @@ -1,32 +0,0 @@ -# Segmentation FURPS - -## Functionality - -1. Outbound messages larger than the maximum Waku message size are partitioned in several messages to fit in Waku messages. -2. Inbound partitioned messages are reconstructed in a whole message. -3. A capping limit is applied to pre-segmented messages (e.g. 100MB). -4. Messages under the maximum message size are not modified. - -## Usability - -1. Only takes a maximum message size as a parameter. - -## Reliability - -1. Reconstruction can be performed even when parts are received out or order. -2. Reconstruction can be performed as long as 87.5% of the segments is received. -3. If too many parts missing to reconstruct an informative error should be logged. - -## Performance - -1. The payload overhead does not exceed 12.5% overall, and 100 bytes per segment. - -## Supportability - -1. Nim library. - -## + (Privacy, Anonymity, Deployments) - -1. Segmentation metadata should not reveal information about the original message content -2. Relevant for all Waku nodes. -3. Nimble package manager is used to build. diff --git a/FURPS/application/signal_network.md b/FURPS/application/signal_network.md deleted file mode 100644 index 446a90b..0000000 --- a/FURPS/application/signal_network.md +++ /dev/null @@ -1,27 +0,0 @@ -# Signal Network PoC FURPS - -## Functionality - -1. Establish direct connection to remote peer using their public key as identifier. - -## Usability - -1. Developers can implement their own application-level discovery method. -2. Only remote peer's public key is needed to initiate connection. -3. Hook is provided for developer to filter inbound connection requests. - -## Reliability - -1. End-to-end reliability is implemented for the signaling conversation. -2. No provided reliability for established connections, left to the developer (e.g. keep alive). - -## Supportability - -1. Developers can use this protocol in web application, imported from npmjs.com. -2. Developers can use this protocol to initiate WebRTC connections. -3. Only 1:1 direct connections are supported. - -## + (Privacy, Anonymity, Deployments) - -1. Network observers cannot retrieve node connection details; forward secrecy is **not** included. -2. STUN and TURN servers may be required for WebRTC usage. \ No newline at end of file diff --git a/FURPS/application/status_communities.md b/FURPS/application/status_communities.md deleted file mode 100644 index 1936d25..0000000 --- a/FURPS/application/status_communities.md +++ /dev/null @@ -1,34 +0,0 @@ -# Status Communities FURPS - -Waku specific FURPS, before Chat SDK integration. - -## Functionality - -1. Waku traffic from Communities protocol is segregated from other traffic. -2. Waku traffic from all Communities is routed through a common set of shards. -3. Communities user content traffic is segregated from other Communities traffic. -4. The usage of Waku content topic by Status Communities protocol is simplified. - -## Usability - -1. Users with Communities features deactivated are not impacted by Communities traffic of other users. -2. It is possible to setup different Waku store databases, and different retention time for user content and other Communities messages. -3. Store responsiveness and edge node readiness are improved. - -## Reliability - -1. No regression on Communities feature (Vac-QA). - -## Performance - -1. Time to setup filter subscriptions for Communities has improved by >20% (**Vac-DST**). -2. Time to retrieve 24 hours of Communities messages has improved by >20% (**Vac-DST**). -3. Increased community traffic does not increase bandwidth usage of 1:1 chat (**Vac-DST**). - -## Supportability - -1. Status Mobile, Desktop, Light and relay modes. - -## + (Privacy, Anonymity, Deployments) - -1. ... \ No newline at end of file diff --git a/FURPS/application/status_go.md b/FURPS/application/status_go.md deleted file mode 100644 index b4cc2d8..0000000 --- a/FURPS/application/status_go.md +++ /dev/null @@ -1,32 +0,0 @@ -# Status-go FURPS - -## Functionality - -1. Nwaku is the used Waku implementation for relay mode. -2. Nwaku is the used Waku implementation for light mode. - -## Usability - -1. Status Desktop CI run additional builds that uses nwaku. - -## Reliability - -1. status-backend built with nwaku can pass the status-cli tests **(Vac-QA)**. - -## Performance - -1. status-backend built with nwaku has similar performance than go-waku based status-backend within 10% margin, - on metrics measured by existing simulations (Vac-DST). - -## Supportability - -1. Status Desktop binary for Linux, Mac and Windows. -2. Relay mode is supported. -3. Light mode is supported. -4. Status Mobile binary for Android and iOS. -5. Status Tablet binary for Android and iOS. - -## + (Privacy, Anonymity, Deployments) - -1. Status Desktop CI builds binaries with nwaku, alongside go-waku-based binaries. -2. Status Mobile and Tablet CI builds binaries with nwaku, alongside go-waku-based binaries. \ No newline at end of file diff --git a/FURPS/application/status_private_chats.md b/FURPS/application/status_private_chats.md deleted file mode 100644 index 77bd0d9..0000000 --- a/FURPS/application/status_private_chats.md +++ /dev/null @@ -1,31 +0,0 @@ -# Status Private Chats FURPS - -Waku specific FURPS, **before** integration of the Chat SDK. - -## Functionality - -1. Features other than one-to-one chats are either removed or can be disabled. -2. One-to-one chat’s traffic is not impacted by other features. -3. One-to-one chats are functional when rate limited by 100 msg per 10min over Waku or less. - -## Usability - -1. Features other than one-to-one chat can be removed or disabled. -2. A user with only one-to-one chat enabled can expect limited bandwidth and resource usage and a smooth experience. - -## Reliability - -1. One-to-one chat’s implementation behaves as specified (**Vac-QA**). - -## Performance - -1. 99% of one-to-one user messages are eventually received by their recipient, within 5 minutes of being online (**Vac-DST**). -2. One-to-one chat’s non-user messages do not consume over 20% of the allocated quota (**Vac-DST**). - -## Supportability - -1. status-cli/backend - -## + (Privacy, Anonymity, Deployments) - -1. ... \ No newline at end of file diff --git a/FURPS/core/incentivisation.md b/FURPS/core/incentivisation.md deleted file mode 100644 index 4bf76a3..0000000 --- a/FURPS/core/incentivisation.md +++ /dev/null @@ -1,31 +0,0 @@ -# Incentivisation FURPS - -## Functionality - -1. RLNaaS clients proceed to pay RLNaaS providers for attaching RLN proof to published messages. -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. - -## Usability - -1. A consumer node can pay a service node for RLNaaS. -2. A consumer node can select an RLNaaS provider based on local reputation. - -## Reliability - -1. A consumer prefers new providers to known unreliable providers. -2. 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)** -3. A client can assess whether an RLNaaS provider has relayed their message (**Vac-QA**) - in 90% of cases **(Vac-DST)**. - -## Performance - -1. Assuming a block time of 5 seconds, - a user can execute an RLNaaS payment and send a message within 30 seconds (Vac-DST) - -## Supportability - -1. A nwaku-based CLI on a testnet, interaction with a custodial wallet is out-of-scope. - -## + (Privacy, Anonymity, Deployments) diff --git a/FURPS/core/light_push.md b/FURPS/core/light_push.md deleted file mode 100644 index 76075a6..0000000 --- a/FURPS/core/light_push.md +++ /dev/null @@ -1,31 +0,0 @@ -# Light Push FURPS - -## Functionality - -1. Enables light nodes to push messages to service nodes for relay to the network. -2. Requests service nodes to publish messages to WAKU2-RELAY shards. -3. Provides confirmation that a message has been received by at least one node. -4. Supports comprehensive error codes for various failure scenarios. - -## Usability - -1. Implements simple async request/response pattern. -2. Uses standard Waku Message format. -3. Only requires an established libp2p connection. -4. Provides descriptive error messages in responses. - -## Reliability - -1. Implements DoS protection through request rate limitation. -2. Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure). -3. 80% message transmission success rate on live Status network (service node from both Status Desktop and fleet Waku instances) - -## Performance - -1. Only one network round trip is required per operation; including both configuration and message transmission. -2. Minimizes protocol overhead for efficient resource usage. - -## Supportability - -1. Linux amd64 CLI as service node -2. Browser as client \ No newline at end of file diff --git a/FURPS/core/mix.md b/FURPS/core/mix.md deleted file mode 100644 index 00929ae..0000000 --- a/FURPS/core/mix.md +++ /dev/null @@ -1,26 +0,0 @@ -# Mixnet FURPS - -## Functionality - -1. Relay nodes can mount mixnet protocol, acting as sender, intermediary or exit nodes. -2. Nodes can connect to other nodes that support mix using static configuration. -3. Client nodes can send light push requests over the mixnet before delivery to a service node. -4. Client nodes can receive a response to a light push request over the mixnet. -5. Nodes can discover other nodes that support mix using available peer discovery mechanisms. - -## Usability - -## Reliability - -## Performance - -- P1. Payloads are limited to 4kB - -## Supportability - -1. `wakunode2` for intermediary and exit nodes. -2. nwaku CLI for sender nodes. -3. Browser based apps built using js-waku support acting as entry nodes. -4. Browser based apps built using js-waku support discovering mix nodes using available peer discovery mechanisms. - -## + (Privacy, Anonymity, Deployments) diff --git a/FURPS/core/rendezvous.md b/FURPS/core/rendezvous.md deleted file mode 100644 index 296b302..0000000 --- a/FURPS/core/rendezvous.md +++ /dev/null @@ -1,29 +0,0 @@ -# Rendezvous FURPS - -## Functionality - -1. libp2p-rendezvous peer discovery protocol is used - -## Usability - -1. Relay nodes discover additional peers via libp2p-rendezvous - -## Reliability - -1. Relay nodes finds new peers when solely using rendezvous **(Vac-QA)**. - -## Performance - -1. In an established network of 1k relay nodes on 10 shards with 1 bootstrap node, - 100 new relay nodes (relay + discv5 + Waku PX + rendezvous) - can connect to 20 relay peers in the right shard within 1 minute (**Vac-DST**) - ; run simulation without rendezvous to see the difference - -## Supportability - -1. Enabled in status-go using nwaku c-bindings -2. Enabled in nwaku-compose - -## + (Privacy, Anonymity, Deployments) - -N/A \ No newline at end of file diff --git a/FURPS/core/rln_relay.md b/FURPS/core/rln_relay.md deleted file mode 100644 index 73c95d1..0000000 --- a/FURPS/core/rln_relay.md +++ /dev/null @@ -1,36 +0,0 @@ -# RLN Relay FURPS - -## Functionality - -1. Light push service node can attach RLN proof for clients. -2. Relay node can attach RLN proof for outbound messages. -3. Relay node can verify RLN proof for inbound messages. -4. Light push client can be configured to generate proof for outbound messages. -5. Filter client can be configured to verify proof for inbound messages. - -## Usability - -1. Light push clients do not need RLN logic when using RLNaaS. - -## Reliability - -1. Relay node can fallback to alternative RPC endpoints - if the primary Web3 RPC provider becomes unavailable. - -## Performance - -1. In a network of 10k RLN Relay nodes with each node sending one 1-100KB message every 10-30s, - messages are propagated within 500ms, with 99.9% success **(Vac-DST)**. -2. In a network of 10k RLN Relay nodes, - a spamming node will be disconnected from its peers in under 1 min. **(Vac-DST)** - -## Supportability - -1. Service node proof generation for light push clients is available in `wakunode2` for browser clients. -2. Browser edge nodes can be configured to verify and generate proofs. - -## + (Privacy, Anonymity, Deployments) - -1. Service node proof generation for light push clients is deployed on TWN. -2. Service node proof generation for light push clients is enabled by default in nwaku-compose. - diff --git a/FURPS/core/rln_sdk.md b/FURPS/core/rln_sdk.md deleted file mode 100644 index fc7baa4..0000000 --- a/FURPS/core/rln_sdk.md +++ /dev/null @@ -1,29 +0,0 @@ -# Waku RLN SDK FURPS - -## Functionality - -1. Accepts RLN network configuration at initialization. -2. API to pass messages for proof validation. -3. API to import RLN credentials, compatible with RLN Membership management. -4. API to accept Waku Message and generate proof. -5. API to inform on configured rate limit parameters and remaining quota. - -## Usability - -1. TWN RLN configuration is applied by default. -2. No boilerplate code beyond initialization is necessary to pass RLN instance in a Waku API implementation. -3. Rate usage is persisted across restarts. - -## Reliability - -## Performance - -## Supportability - -1. library can be used in Go applications; available on pkg.go.dev. -2. library can be used in Rust applications; import via git path. -3. library can be used in Nim applications; import via git path. - -## + (Privacy, Anonymity, Deployments) - -1. Only one set of credentials can be used at a given time. \ No newline at end of file diff --git a/FURPS/core/rln_smart_contract.md b/FURPS/core/rln_smart_contract.md deleted file mode 100644 index 62925f6..0000000 --- a/FURPS/core/rln_smart_contract.md +++ /dev/null @@ -1,35 +0,0 @@ -# RLN Smart Contract FURPS - -## Functionality - -1. RLN rate limit can be defined in terms of multiple messages per epoch. -2. RLN rate limit is set at membership insertion -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 - -## Usability - -1. Application developers can set RLN rate limit at insertion. -2. User does not need to wait for merkle tree synchronization and building to start relaying - or sending messages. -3. Application does not need to do a Web3 RPC call for every tree change to generate or validate messages. -4. Application can transfer tokens and register membership with a single transaction. - -## Reliability - -1. ... - -## Performance - -1. New node setup with an RLN membership can be ready to verify RLN proof within 5s, - no matter the size of the membership set **(Vac-DST)**. -2. Rate limit variables, in combination with good defaults on software side, enable around 5,000 registrations. - -## Supportability - -1. ... - -## + (Privacy, Anonymity, Deployments) - -1. Smart Contracts are deployed on ~Linea Sepolia~ Status L2 Sepolia. -2. TWN uses smart contracts deployed on ~Linea Sepolia~ Status L2 Sepolia. diff --git a/FURPS/core/store.md b/FURPS/core/store.md deleted file mode 100644 index 0c91f3b..0000000 --- a/FURPS/core/store.md +++ /dev/null @@ -1,42 +0,0 @@ -# Store - -## Functionality - -1. Provides historical message retrieval from the relay network, enabling nodes to query for messages they missed while offline. -2. Supports multiple query types: time-based, content-topic filtered, and message hash lookups. -3. Enables message presence verification without retrieving full message content. -4. Supports pagination for efficient retrieval of large message sets, and resuming retrieval after disconnection. -5. Supports comprehensive error codes for various failure scenarios. -6. Industry practices are applied to PostgreSQL setup to reach appropriate performance -7. Provides a retention policy mechanism that allows keeping the disk occupation constant. - -## Usability - -1. Implements simple async request/response pattern. -2. Uses standard Waku Message format. -3. Only requires an established libp2p connection. -4. Provides descriptive error messages in responses. -5. Supports query filtering to retrieve only relevant messages by content topic. - -## Reliability - -1. Implements DoS protection through request rate limitation. -2. (limitation) No guarantees in terms of message presence or retention duration. -3. Store node always provide a response; thanks to DoS protection. - -## Performance - -1. Only one network round trip is required for operation. -2. Implements pagination to manage resource usage on both client and server. -3. Allows presence queries to verify message existence without transferring full content. -4. Targets query response times under 2 seconds for typical requests. -5. 95th percentile of hash queries are served in less than 10ms of less than 10 hashes; for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**. -6. 90th percentile of time range queries are served in less than 10ms; if the query is less than 1 hour, using up to 10 content topics, for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**. - -See [dashboards](https://grafana.infra.status.im/goto/kxraQIuNR?orgId=1) - -## Supportability - -1. Linux amd64 CLI as service node -2. PostgreSQL as database engine. -3. Browser support as client. \ No newline at end of file diff --git a/FURPS/core/store_sync.md b/FURPS/core/store_sync.md deleted file mode 100644 index 335b6cb..0000000 --- a/FURPS/core/store_sync.md +++ /dev/null @@ -1,23 +0,0 @@ -# Store Sync FURPS - -## Functionality - -1. Store nodes synchronize recent messages with each other. -2. Store node to store node synchronization happens on a periodic manner. -3. Store node to store node synchronization happens after re-connection is detected. - -## Usability - -1. Remote store peer selection is done automatically. - -## Reliability - -1. No message discrepancies at any time, for time windows of 5 minutes to 60 minutes ago. - -## Performance - -1. A sync of a 60 minutes time window happens under 60 seconds, assuming 15 msgs/second (total), 150KB message size and a maximum of 10% pre-existing message discrepancy (**Vac-DST**). - -## Supportability - -1. nwaku store service node \ No newline at end of file diff --git a/FURPS/core/waku_sdk.md b/FURPS/core/waku_sdk.md deleted file mode 100644 index 0841220..0000000 --- a/FURPS/core/waku_sdk.md +++ /dev/null @@ -1,41 +0,0 @@ -# Waku SDK FURPS - -## Functionality - -1. Setup, start and stop a Waku node. -2. Support edge node operation mode. -3. Support relay node operation mode. -4. Does automatic peer discovery based on the node platform and operation mode. -5. Returns health and connectivity information using proven heuristics. -6. Previously discovered peers are persisted across restarted, and potentially used for future connections. -7. When wrapping the C API, conversion from native types to JSON is needed by the wrapper. -8. When wrapping the C API, conversion from native types to Protobuf is needed by the wrapper (PoC). - -## Usability - -1. When setting up a Waku node, no need to specify what protocols to mount, only an operational mode (edge or relay). -2. Disconnection detection and recovery, and other peer management matters are automatically handled. -3. Developers do not need to specify the protocols used to send and receive messages; it is deduced from the mode of operation. -4. Developers pass and receive data to the API in types native to the wrapping language. -5. By default, auto-sharding is applied, meaning developers do not need to be concerned by sharding; pubsub topics are never exposed. -6. 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. -7. When wrapping the C API, a protobuf definition can be used to generate native types for the host language (PoC). - -## Reliability - -1. Sends a message using peer-to-peer reliability (service node redundancy for edge, optional store confirmation) -2. Receives messages using peer-to-peer reliability (service node redundancy for edge, periodic store query, periodic filter ping) - -## Performance - -## Supportability - -1. Developers can use the SDK in nim software, importing it via git path. -2. Developers can use the SDK in Golang software, importing it from on pkg.go.dev. -3. Developers can use the SDK in Browser software, importing it from npmjs.com. -4. Developers can use the SDK in Rust software, importing it from crates.io. - -## + (Privacy, Anonymity, Deployments) - -1. C API uses JSON format for data passing. -2. C API uses Protobuf format for data passing. \ No newline at end of file diff --git a/PROCESS.md b/PROCESS.md index 689b40e..77cf998 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -20,17 +20,14 @@ See [Waku Methodology](https://www.notion.so/Waku-Mission-and-Methodology-1a58f9 The Waku team is currently organized in the following subteams: -- Core Research -- nwaku -- js-waku -- Chat/App Dev -- Chat/App Research -- Business Dev +- Nim: Looking after [logos-messaging-nim](https://github.com/logos-messaging/logos-messaging-nim/), [nim-sds](https://github.com/logos-messaging/nim-sds), and other components below the Reliable Channel API. +- Chat: Looking after the [Chat SDK](https://github.com/logos-messaging/nim-chat-poc). +- Messaging Logos Core: ensuring messaging libraries are available as Logos Core modules. ## Documents -- [Waku FURPS](https://www.notion.so/Waku-FURPS-1498f96fb65c803faedef2a591c22c00) -- [Waku Milestones](https://roadmap.logos.co/waku/waku-milestones) +- [Logos Messaging FURPS](https://roadmap.logos.co/messaging/furps) +- [Logos Messaging Milestones](https://roadmap.logos.co/messaging/milestones) ## Terminology and Scope @@ -74,8 +71,10 @@ For example: To track the work to achieve these FURPS, two deliverables should be created: -1. [nwaku] Support error code in light push: Implement Light Push FURPS F1, S1. -2. [js-waku] Support error code in light push: Implement Light Push FURPS F1, S2. +1. `[nim] Support error code in light push: Implement Light Push FURPS F1, S1.` +2. `[js] Support error code in light push: Implement Light Push FURPS F1, S2.` + +Note: `[chat]` and `[nim]` are the current valid teams. When the **work** is not related to software behaviour (e.g. a contributor guide, some BD activities), then a deliverable is used to define the expected output, without referring to specific FURPS. @@ -105,12 +104,12 @@ Here are some rules to ensure the efficacy of our process. What is not explicitly defined is left to the subteam's choice. A _Milestone_: -- MUST have a GitHub Milestone in https://github.com/waku-org/pm repo, to which relevant _FURPS_ statements or _Deliverables_ are added. +- MUST have a GitHub Milestone in https://github.com/logos-messaging/pm repo, to which relevant _FURPS_ statements or _Deliverables_ are added. - MUST have an *estimated date of completion* - MUST have an effort estimate, stating how many CCs are needed to work on this for a given half-year (e.g. one research, half an engineer) A _Deliverable_: -- MUST be defined as an issue in the https://github.com/waku-org/pm repo. +- MUST be defined as an issue in the https://github.com/logos-messaging/pm repo. - MUST be included in its parent _Milestone_. - MUST have an _Output_ section in the description detailing the result of work of the Deliverable, this may be a list of FURPS. - If tracking FURPS, the FURPS only belong to one feature aka FURPS set. @@ -143,5 +142,5 @@ Finally, for _Tasks_ or _PRs_ that do not belong to a _Deliverable_: - Waku Lead: @fryorcraken - Program Manager: @chair28980 -- Team Lead: @plopezlpz @Ivansete-status @jm-clius @weboko @jazzz -- VAC PoC: @jm-clius, @stubbsta for Vac-DST \ No newline at end of file +- Team Lead: @Ivansete-status @jazzz +- DST/QA PoC: @stubbsta \ No newline at end of file diff --git a/draft-roadmap/README.md b/draft-roadmap/README.md deleted file mode 100644 index a8b126d..0000000 --- a/draft-roadmap/README.md +++ /dev/null @@ -1,165 +0,0 @@ -# Waku Draft Roadmap - -**Most of the below is being moved to [2025H2 Summary](../2025H2-SUMMARY.md)**, which is now the master document. - -Finalised roadmap and milestones can be found on the [Logos roadmap](https://roadmap.logos.co/waku/). - -Period in planning: 2025 H2 - -## Proposed Priorities - -### Whole Team - -1. **Support Status application**: continue integration of nwaku and provide new chat protocol stack. -2. **Support Logos Core**: ensure that any library and API we push to developers can be consumed in Logos Core; review and prioritize any requirements coming from Logos Core project contributors and developers. -3. **Developer and Contributor Experience:** Review and improve dev assets (docs) and set quality expectation across the team (docs provided with deliverables, etc); Review and take action to improve developer and contributor experience (nimble usage, vscode plugin, etc). - -### Core Team - -1. **Complete integration of nwaku in Status Desktop** (H1) -2. **Simplify a reliable Waku API:** aka Messaging API, make it easier to consume Waku library; critical to enable easy development of Chat SDK. -3. **Upgrade Waku for the Web**: Ensure web applications built on The Waku Network are reliable. -4. **RLN mainnet and API:** Continue RLN migration to onchain tree + L2 testnet, and necessary steps to get RLN on mainnet; provide simple API for Chat SDK. -5. **[Nwaku in Status Mobile and Light Mode MVP](https://github.com/waku-org/pm/milestone/39)**: de-prioritised in favour of cleaning up Waku and RLN APIs for Chat SDK first. -6. **nwaku performance improvement**: Performance on mobile is critical, hence we will review benchmarks and potentially dedicate effort to this topic -(note there is some ongoing effort from Status fleet behaviour). - -#### Research Items - -1. RLN (as above) -2. **Incentivisation:** Deliver incentivisation PoC for reliability, scalability, risk (running own fleet) and sustainability. -3. **Decentralisation and privacy**: continue research work to further decentralised Waku protocols, specifically store, and increase anonymity properties with libp2p-mixnet - -### Chat/App Team - -1. **Chat SDK:** Build a chat SDK (new protocol), learning from Status’ experience. Focus for an iterative delivery of the foundational blocks. Targeting private chats and early RLN integration. - 1. Note that building blocks such as identity mgmt are being built for demos app like Qaku - alignment to define and provide common protocols is expected as we are not limited by existing Status chat protocol. - 2. Work in close partnership with the status-backend developers, to ensure that post-refactoring the SDK can be integrated with the least effort possible. Aim for early and iterative integration. - 3. Note that early Status backend design position chat SDK as backend for Communities too; early iteration may not provide the scale in terms of members per communities; but Status' requirement is noted. - 4. Minimum deliverable will be usability of Chat SDK in Logos Core; need to review the architecture expectation in terms of Logos Core plugin interaction chat sdk <> nwaku. -2. **Build demos and PoC apps**: Continue building PoC apps to teach how to hunt, dogfood and battle test libraries; as well as throwing ideas in the wild, experimenting and seeing what sticks; promising apps will have lib and specs implemented (e.g. Qaku and Logos Forum). - 1. Potentially expand the relevant platforms: from Web to Logos core, Nim/seaqt, Rust, etc. - 2. Integration with Codex still planned under this umbrella - 3. Review Logos Forum (Opchan) requirements; the 2025 Logos Movement Strategy is the new customer. - -### Business and Ecosystem Development Team (BD + Solution Eng) - -1. **Measure Success:** Develop and deploy tools to measure Waku success in terms of users, developers and contributors across all known Waku networks (Status, RAILGUN, TWN, etc) - 1. In partnership with BI. -2. **Waku Chat MVP:** Proceed with the same exercise done for [Waku MVP](https://www.notion.so/Waku-MVP-1838f96fb65c8039acabf8a6a1e689e7?pvs=21). - Consult with current and new leads on their *ideal* Chat SDK. - Understand how confident we are they would onboard on Waku if it is delivered and feedback to Chat/App team to take in account for prioritization. -3. **Support integrations**: support projects that want to build with Waku SDK and Chat SDK. -4. **Foster and join Nim ecosystem (nwaku):** Foster and participate in the Nim developer community inside and outside IFT. -5. **Join FOSS ecosystem:** Be an active part of the FOSS developer community. -6. **Continue planned Rust SDK work**: Messaging API and stable nwaku integration in Status Desktop and pre-requisites to a quality Rust SDK. - -### Status Priorities Review - -**Existing milestones**: - -- [Hardening and Scaling Foundations for Private Chats](https://roadmap.logos.co/waku/milestones/open/2025-hardening-and-scaling-foundations-for-private-chats): finishing off the work and descoping items that have been identified as unneeded. -- [Nwaku in Status Desktop (Relay only)](https://roadmap.logos.co/waku/milestones/open/2024-nwaku-in-status-desktop): work continues, close to completion. -- [Nwaku in Status Mobile](https://roadmap.logos.co/waku/milestones/open/2025-nwaku-in-status-mobile): deprioritized in favour of improving API for new Chat SDK -- [e2e reliability protocol](https://roadmap.logos.co/waku/milestones/open/2024-e2e-reliability-protocol): work continues, close to completion. -- [Foundation for Communities Optimization](https://github.com/waku-org/pm/milestone/31): this includes finishing a migration, and move community traffic away from 1:1 chat so we complete the work. - -**New work and priorities**: - -1. New Chat SDK (nim) and protocol stack - -## Draft Milestones - -Testing out new format, once approved: - -- Milestones are copied to Logos roadmap -- Deliverables are copied to GitHub issues -- Waku FURPS remains in [FURPS](/FURPS/README.md) - -In order of priority. - -### To finish in H1 - -| Milestone | End Date | core res | js-waku | nwaku | app-chat | -|------------------------------------------------------------------------------------------------------------|----------------|----------|---------|-------|----------| -| [Introduce E2E Reliability in Status Communities](introduce_e2e_reliability_in_status.md) | 31 Aug | | | | 1 | -| [Foundation for Communities Optimisation](foundation_for_communities_optimisation.md) | 31 Oct | | | | 1 | -| [Hardening and Scaling Foundations for Private Chat](hardening_and_scaling_foundation_for_private_chat.md) | Completed/Drop | | | | | -| [Integrate nwaku in Status Desktop, relay mode only](integrate_nwaku_in_status_desktop_relay_mode_only.md) | 30 Jun | | | 2 | | -| [Deploy RLN Onchain Tree on L2 Testnet](deploy_rln_onchain_tree_on_l2_testnet.md) | 30 Jun | | | | | - -### H2 Milestones - -Total people-month available `16.5 p(eople) * 6 m(onths) = 99 p-m`. -(Franck, Aaron full time mgmt/leadership/eco dev/comms, Hanno half-time, Tanya as test engineer) -✧ One core research CC AWOL. - -| | core res p/p-m | js-waku p/p-m | nwaku p/p-m | app-chat p/p-m | BD p/p-m | -|--------------|----------------|---------------|-------------|----------------|----------| -| Available | 3.5/21✧ | 2/12 | 4/24 | 5/30 | 1/6 | -| Work planned | 3.2/19 | 1.5/9 | 2.25/13.5 | 4.7/28 | 1/6 | - -Note: low allocation on nwaku due to -- high risk on nim activities -- general support to research and now chat team. -- performance uncertainty, especially for mobile (benchmarks in status are wip) - -| Priority | Milestone | End Date | core res | js-waku | nwaku | app-chat | BD | Capacity✱ | -|----------|-----------------------------------------------------------------------------------------|----------|----------|---------|--------|----------|------|-----------| -| 1 | [Define Incentivisation for RLNaaS](define_incentivisation_for_rlnaas.md) | 31 Jul | 1.5*1m | | | | | 0.4 | -| 2 | [Improve DevEx: API, TWN, Metrics, Docs](improve_devex_api_twn_metrics_docs.md) | 31 Aug | 1*1m | 2*2m | 1.5*2m | 1*1m | | 2.1 | -| 3 | [Introduce mixnet for message sending](introduce_mixnet_for_message_sending.md) | 30 Sep | 1*3m | | | | | 0.7 | -| 4 | [Formalize and Expand Waku Web Apps](formalize_and_expand_waku_web_apps.md) | 19 Dec | | | | 1.5*6m | | 2.1 | -| 5 | [Create Chat SDK MVP](create_chat_sdk_mvp.md) | 30 Sep | | | | 3*3m | | 2.1 | -| 6 | [Harden RLN Testnet Deployment](harden_rln_testnet.md) | 30 Sep | 1*1.5m | 1*1m | | | TODO | -| 7 | [Integrate RLN with Waku API](integrate_rln_with_waku_api.md) | 30 Sep | 1*1m | 1*2m | 2*2m | | | 1.7 | -| 8 | [Streamline DevEx: Mobile, Rust and Web dev](streamline_dev_ex_local_dev_rust.md) | 30 Nov | | 2*6w | 3*6w | | | 1.2 | -| 9 | [Extend Chat SDK with Group Conversations](extend_chat_sdk_with_group_conversations.md) | 19 Dec | | | | 2*3m | | 1.4 | -| 10 | [Incentivisation and Marketplace Follow-up Outline](incentivisation_follow_up.md) | TBD | 2.5*5m | | | | | 3 | -| 11 | [Nim Usage Improvements](nim_usage_improvements.md) | 19 Dec | | | 1*2m | | | 0.5 | -| 12 | [BD - Acquire 10 Customers](acquire_first_10_customers.md) | 19 Dec | | | | 0.5*6m | 1*6m | 2.1 | - -✱ Capacity: How may people assigned in a 6 months window. Adjusted to 70% allocation for support. - -Pushed to 2026H1/Next on the list -- WebTransport: depending on nim-libp2p (delivery Q4) -- Implementing Waku API in REST: Useful for DST/QA, but let's focus on Status, Chat SDK, and Rust first -- Delivering NodeJS SDK. -- nwaku performance on mobile: depending on benchmark results -- New entry points for RLN, in addition to deposit (e.g. Karma holder or SNT staker) -- Message caching/database within Waku SDK -- Migration strategy and compliance layer for Status protocol vs Chat SDK - -## Gantt - -```mermaid -gantt - title Waku 2025H2 - dateFormat YYYY-MM-DD - axisFormat %b - section core research (6) - Define Incentivisation for RLNaaS: 2025-07-01, 2025-08-01 - Improve DevEx: 2025-08-01, 2025-08-31 - Harden RLN Testnet Deployment: 2025-08-01, 2025-09-30 - Integrate RLN with Waku API: 2025-09-01, 2025-09-30 - Mixnet: 2025-07-01, 2025-09-30 - Incentivisation and Marketplace Follow-up: 2025-08-01, 2025-12-31 - section js-waku - Improve DevEx (API): 2025-07-01, 2025-08-31 - Improve DevEx (TWN): 2025-07-01, 2025-08-31 - RLN Library: 2025-08-01, 2025-09-30 - Streamline DevEx: 2025-10-01, 2025-11-30 - section nwaku - Improve DevEx (API): 2025-07-01, 2025-08-31 - Improve DevEx (TWN): 2025-07-01, 2025-08-31 - RLN Library: 2025-08-01, 2025-09-30 - Streamline DevEx (Mobile, Rust): 2025-10-01, 2025-11-30 - Nim Usage Improvements: 2025-11-01, 2025-12-31 - section app-chat - E2E Reliability: 2025-07-01, 2025-08-01 - Communities Opt: 2025-07-01, 2025-08-01 - Improve DevEx (metrics): 2025-08-01, 2025-09-01 - Create Chat SDK: 2025-07-01, 2025-09-30 - Extend Chat SDK: 2025-10-01, 2025-12-31 - Formalize and Expand Waku Web Apps: 2025-07-01, 2025-12-31 -``` \ No newline at end of file diff --git a/draft-roadmap/TEMPLATE.md b/draft-roadmap/TEMPLATE.md deleted file mode 100644 index 4388e45..0000000 --- a/draft-roadmap/TEMPLATE.md +++ /dev/null @@ -1,41 +0,0 @@ -# {Milestone Title - use verb} - -**Estimated date of completion**: {Enter date} - -**Resources Required for 2025H2**: -- {roles and % application to it} -- {external services consumed (Vac/IFT)} -- {infrastructure} - -{Milestone Narrative - what do we get once done} - -## Strategic Objective - -Logos xxx - -## FURPS - -- [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc} - -## Risks - -| Risk | (Accept, Own, Mitigation) | -|--------|-------------------------------| -| [Risk] | [how to we address this risk] | - -## Deliverables - -### {Name of deliverable 1 - eg "improve feature X for the browser"} - -**Owner**: {one waku subteam} - -**Feature**: [{Feature Name (only 1)}]({path/to/furps/file}) - -**FURPS**: -- {F1. copy-paste full furps statement} - -**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) \ No newline at end of file diff --git a/draft-roadmap/acquire_first_10_customers.md b/draft-roadmap/acquire_first_10_customers.md deleted file mode 100644 index 828da27..0000000 --- a/draft-roadmap/acquire_first_10_customers.md +++ /dev/null @@ -1,46 +0,0 @@ -# Business Dev - Acquire First 10 Customers - -**Estimated date of completion**: 2025H2 Period - -**Resources Required for 2025H2**: -- 1 Business Development Lead -- 0.5 Solution Engineer -- Comms Hubs Support - -Onboard Waku first 10 customers. Customers are projects using Waku for their peer-to-peer communication stack, or conversation/chat. -First 10 customers assume involvement from the engineering team to get things right and help co-design. - -Status, Railgun, TheGraph, Portrait and Chrom.ar should count as the first five. - -A couple of projects are in stealth mode and can be counted in once they go public. - -## Strategic Objective - -Logos Movement Community Enabling: Growth - -## Risks - -| Risk | (Accept, Own, Mitigation) | -|--------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| No dedicated Dev Rel | Work closely with Logos Movement to funnel developers to Waku. Apply guerilla tacting to leverage current Waku team members. Use Solution Engineer for conference talk and presence. | -| No dedicated Growth Lead | Rely on Comms Hubs for Social Media presence, event organization, content and other initiatives. Leverage keen Waku team members to roll out dev community growth initiatives. | - -## KPIs for 2025H2 - -TODO: These are proposed KPI, need to iterate on them. Will review by EOW (13 June.) - -- [ ] Identify 15 Highly Qualified Leads -- [ ] Discuss solution engineering with 10 leads -- [ ] Bring 5 leads into Discord bridge (will to connect and discuss) -- [ ] 3 new integrations started -- [ ] Identify 3 ecosystem grants, and secure initial calls - -## Deliverables - -### Chat SDK MVP Definition - -**Owner**: BD - -Based on customer interviews and co-design sessions, identify the potential Waku Chat SDK USPs and outline an MVP. - -Communicate with targeted customers on MVP. \ No newline at end of file diff --git a/draft-roadmap/create_chat_sdk_mvp.md b/draft-roadmap/create_chat_sdk_mvp.md deleted file mode 100644 index 99112cb..0000000 --- a/draft-roadmap/create_chat_sdk_mvp.md +++ /dev/null @@ -1,163 +0,0 @@ -# Create Chat SDK MVP - -**Estimated date of completion**: 30 Sep 2025 - -**Resources Required for 2025H2**: -- 1 App/Chat Researcher -- 2 App/Chat Engineers - -The SDK is intentionally minimal—focused solely on proving the usability of the core approach. It supports 1:1 chat with -out-of-band contact discovery and includes supporting implementations to help developers get up and running quickly. - -The primary goal is to deliver a usable library that developers can build with today, while laying a flexible foundation -for future extensions such as group chats and identity. Releasing early as possible maximizes feedback time and -interaction speed. - -Motivations for development of a new chat protocol are described [here](https://forum.vac.dev/t/chatsdk-motivations/501). - -This milestone is complete when a development preview of the Chat SDK is published and made available to the community. - -## Strategic Objective - -Logos Movement Module Build Out - -## Risks - -| Type/Level | Risk | (Accept, Own, Mitigation) | -|-----------------------|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Schedule/High | Lack of Nim experience | Nim is a new language to many who will be performing this work, and will require skill-up to be effective. Delays and high bug counts are possible due to underestimating effort required to become proficient. Leveraging existing Nim knowledge in the team will help mitigate this risk. | -| Organisational/Medium | Direction Alignment | Currently the chat use case does not have a Security Model and Privacy Model defined from which to drive development. These will need to be drafted while work begins. Given these documents will have wider impact in the org and community there is a risk that consensus will take longer than anticipated, stalling development. Mitigation involves documenting the targeted approach and socializing it as early as possible. Following the Protocol Design Framework outlined for chat use cases will help decompose work areas making partial consensus easier to reach. | -| Schedule/Medium | Cryptographic Primitives | There is an assumption that the cryptographic libraries needed for the success of this project are available and in a usable state. To mitigate, early tasks will involve spikes to find appropriate libraries and de-risk their usage their state. Collaboration with ACZ Think Tank. Extra time spent preparing crypto libraries / porting will result in delays. | -| Technical/Low | Uncertain Performance | Performance targets for bandwidth are hard to quantify at this stage. They are listed as `P1` in the FURPS. While these targets appear reasonable (125 bytes per second per user) that remains to be seen. This is hard to mitigate as the SDK cannot be profiled until late in the development cycle, making adjustments difficult. | - -## FURPS - -[ChatSDK](/FURPS/application/chat_sdk.md) - -## Risks - -| Risk | (Accept, Own, Mitigation) | -|--------|-------------------------------| -| [Risk] | [how to we address this risk] | - -## Deliverables - -### [ChatSDK Developer Preview](https://github.com/waku-org/pm/issues/316) - -**Owner**: App/Chat Research - -**Feature**: [Chat SDK](/FURPS/application/chat_sdk.md) - -**FURPS**: -- F1. Accounts can be created in a permission-less way, to communicate on the network. -- F2. Accounts can send messages to conversations with one other participant. -- F3. All conversations benefit from forward secrecy and post-compromise security. -- F4. Sender gets confirmation of message reception by recipient device. -- F5. Developers can create their own payload types or use supplied basic types. -- F6. Sdk contains a default message database for developers. -- F7. Sdk contains a default secrets database for developers. - -- U1. Secure session setups are non-interactive, allowing messages to be sent without waiting for the recipient's device to come online. -- U2. Conversations are initiated by sharing invite links out-of-band. -- U3. Minimal example of the ChatSDK is no more than 25 lines of code. - -- R1. Participants in a conversation can eventually determine whether they missed messages. - -- P1. 10K active SDK users on a single shard add no more than an average of 10Mbps to the total bandwidth; based on clients generating 100 character chat messages, 4 times per minute. - -- S1. Messaging integrates RLN-like rate limit, limiting outbound messages per epoch. -- S2. Payload definitions are versioned to support future protocol updates. - -- +4. Nimble package manager is used to build. - -**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) - -### [ChatSDK Bindings](https://github.com/waku-org/pm/issues/317) - -**Owner**: App/Chat Dev - -**Feature**: [Chat SDK](/FURPS/application/chat_sdk.md) - -**Dependencies**: [ChatSDK - Developer Preview ] - -**FURPS**: - -For library ChatSDK: -- U3. Minimal example of the ChatSDK is no more than 25 lines of code. - -- S3. library can be used in Go applications; available on pkg.go.dev. -- S4. library can be used in Rust applications; import via git path. - -**Checklist**: -- [ ] Specs: API definition -- [ ] Code: link to GitHub issues/PRs/Epic -- [ ] Dogfood: link to dogfooding session/artefact -- [ ] Docs: links to README.md or docs.waku.orgAPI definition? (TBD) - -### [Create Segmentation Library](https://github.com/waku-org/pm/issues/318) - -**Owner**: App/Chat Dev - -**Feature**: [Segmentation](/FURPS/application/segmentation.md) - -**FURPS**: -- F1. Outbound messages larger than the maximum Waku message size are partitioned in several messages to fit in Waku messages. -- F2. Inbound partitioned messages are reconstructed in 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 or order. -- R2. Reconstruction can be performed as long as 87.5% of the segments is received. -- R3. If too many parts 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 Waku nodes -- +3. Nimble package manager is used to build. - -**Checklist**: -- [ ] Specs: link to specs -- [ ] Code: link to GitHub issues/PRs/Epic -- [ ] Dogfood: link to dogfooding session/artefact -- [ ] Docs: links to README.md or docs.waku.org (TBD) - -### [Create Rate Limit Manager](https://github.com/waku-org/pm/issues/319) - -**Owner**: App/Chat Dev - -**Feature**: [Rate Limit Manager](/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 a 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 priorities level: 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 quote 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. - -**Checklist**: -- [ ] Specs: link to specs -- [ ] Code: link to GitHub issues/PRs/Epic -- [ ] Dogfood: link to dogfooding session/artefact -- [ ] Docs: links to README.md or docs.waku.org (TBD) \ No newline at end of file diff --git a/draft-roadmap/define_incentivisation_for_rlnaas.md b/draft-roadmap/define_incentivisation_for_rlnaas.md deleted file mode 100644 index b0222f5..0000000 --- a/draft-roadmap/define_incentivisation_for_rlnaas.md +++ /dev/null @@ -1,29 +0,0 @@ -# [Define Incentivisation for RLNaaS](https://github.com/waku-org/pm/milestone/35) - -**Estimated date of completion**: 31 July 2025 - -**Resources Required for 2025H2**: -- 1.5 core researchers for 1 month - -By the end of this milestone, we will have defined a roadmap and implemented a working proof of concept to incentivise node operators running Waku infrastructure for shared shards. - -In general, Waku infrastructure consists of RLN Relay nodes both forming the decentralised routing backbone for Waku messages and providing a set of services on top of Waku that might be useful for applications. -A sustainable Waku infrastructure is necessary within Status to achieve scalability for 1:1 chats and permissionless communities. -These Status features use RLN rate-limiting on shared shards as supported by the RLN relay nodes -and require a set of decentralised services for Status Mobile and resource-restricted clients, -including RLN proofs as a service, Store, Filter and Lightpush. -This milestone encapsulates the efforts to distribute rewards for running RLN Relay nodes and getting paid for providing Waku services. -This is the first step to providing a sustainable way to scale the Status application. - -## Strategic Objective - -Logos Vision: Core Values Alignment - -## FURPS -- [Incentivisation](/FURPS/core/incentivisation.md): F1-3, U1-2, R1-3, P1, for S1 - -## Risks - -| Risk | (Accept, Own, Mitigation) | -|--------------------------------------------|-----------------------------------------------| -| Heavy on research and unknowns, UX impacts | Identify concrete deliverables, dogfood early | \ No newline at end of file diff --git a/draft-roadmap/deploy_rln_onchain_tree_on_l2_testnet.md b/draft-roadmap/deploy_rln_onchain_tree_on_l2_testnet.md deleted file mode 100644 index 8854c31..0000000 --- a/draft-roadmap/deploy_rln_onchain_tree_on_l2_testnet.md +++ /dev/null @@ -1,90 +0,0 @@ -# Deploy RLN onchain tree on L2 Testnet - -**Estimated date of completion**: 30 June 2025 - -**Resources Required for 2025H2**: -- 1 nwaku engineer -- 1 js-waku engineer -- 1 core research engineer -All for maintenance and dogfooding related activities. - -This is a split of RLN mainnet milestone which grew too large in scope. - -Once complemented, the economical behaviour of RLN will have been specified, -implemented and discussed with the Status team. -An implementation of RLN for light clients will also be done, to demonstrate RLN’s UX with onchain Merkle tree. -Finally, the smart contract will be deployed on a Linea-based L2 testnet and used by The Waku Network. - -It will then be possible to design the usage of RLN in Chat SDK. - -**deliverables**: https://github.com/waku-org/pm/milestone/34 - -## [Implement RLN smart contract for paid, multilevel memberships](https://github.com/waku-org/pm/issues/228) - -**Owner**: research - -**Feature**: [RLN Smart Contract](/FURPS/core/rln_smart_contract.md) - -**FURPS**: - -- F1. RLN rate limit can be defined in terms of multiple messages per epoch. -- F2. RLN rate limit is set at membership insertion -- 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 -- U1. Application developers can set RLN rate limit at insertion. - -**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) - -## [TWN supports RLN onchain tree and deposits, existing memberships only](https://github.com/waku-org/pm/issues/286) - -**Owner**: nwaku - -**Feature**: [RLN Smart Contract](/FURPS/core/rln_smart_contract.md) - -**FURPS**: - -- F3. RLN initialization only requires Web3 RPC `call`s, no blockchain events are needed. -- U2. User do not need to wait for merkle tree synchronization and building to start relaying - or sending messages. -- P1. New node setup with an RLN membership can be ready to verify RLN proof within 5s, - no matter the size of the tree **(Vac-DST)**. -- +1. Smart Contracts are deployed on Linea Testnet. -- +2. TWN uses smart contracts deployed on Linea Testnet. - -**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) - -**Owner**: js-waku - -**Feature**: [RLN Membership Management](/FURPS/application/rln_membership_management.md) - -**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. -- R1. Import and exports are interoperable across all implementations. -- +1. Deployed on https://rln.waku.org -- +2. Available for Linea Sepolia Testnet contracts. -- +3. Proof generation and validation is out of scope. - -For S1. Browser application, using web3 wallet browser extensions. - -**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) diff --git a/draft-roadmap/extend_chat_sdk_with_group_conversations.md b/draft-roadmap/extend_chat_sdk_with_group_conversations.md deleted file mode 100644 index 279e4a7..0000000 --- a/draft-roadmap/extend_chat_sdk_with_group_conversations.md +++ /dev/null @@ -1,99 +0,0 @@ -# Extend Chat SDK with Group Conversations - -**Estimated date of completion**: 19 Dec 2025 - -**Resources Required for 2025H2**: -- 1 App/Chat Research -- 1 App/Chat Engineer - -Once done, apps like Status can build a chat experience which includes support for multiple device, and multiple -participants in a given group chat. - -The features to said group chat will be limited, and extended with further milestones. - -Support to plug Status Communities on top of this SDK is **not** expected. -Further group size scaling and extension of membership management API would be needed. - -## Strategic Objective - -Logos Movement Module Build Out - -## FURPS - -[Group Chat](/FURPS/application/group_chat.md) - -## Risks - -| Type/Level | Risk | (Accept, Own, Mitigation) | -|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Schedule/Medium | Milestone Dependency | This milestone is dependent on [ChatSDK - Developer Preview](create_chat_sdk_mvp.md). Delays there will translate into delays to this milestone. | -| Technical/Medium | Lack of NimLibraries | There currently does not exist the required libraries in Nim to build group chat. This will involve evaluating the potential of calling an existing library via FFI or implementing it from scratch. This can be mitigated by vetting existing library potential should occur early or finding security reviewers for nim implemented cryptography. | -| Technical/Low | Group chat is prone to bugs, even when using existing encryption protocols. Extra time has been allocated to testing and debugging in an effort to mitigate this, however it still remains a risk. | - -## Deliverables - -### [Add Group Chat](https://github.com/waku-org/pm/issues/346) - -**Owner**: App/Chat Research - -**Feature**: [Group Chat](/FURPS/application/group_chat.md) - -**FURPS**: - -- F1. Accounts can receive a message in multiple locations (e.g. devices) by registering new installations. -- F2. Accounts can view and remove installations as needed. -- F3. Accounts can create GroupChats between multiple accounts. -- F4. Participants can set a group name and description for all participants in the group. -- F5. Account can view all provisioned installations. -- F6. Account can revoke other installations in case of a lost device. - -- R1. Group Participants in a conversation can tell if a message is missing, and who sent it. - -- P1. The number of network messages for a single outbound group message does not scale with the number of group members. - -- +PRIV1. Non-participants cannot correlate a group conversation to any of its participants. -- +PRIV2. No identifying information is visible when registering an installation. - -**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) - -### [Group Chat Bindings](https://github.com/waku-org/pm/issues/348) - -**Owner**: App/Chat Dev - -**Feature**: [Bindings](/FURPS/application/group_chat.md) - -**FURPS**: - -- S1. Developers can create group conversations from Go Applications; available on pkg.go.dev. -- S2. Developers can create group conversations from Rust Applications; available on crates.io. - -**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) - -### [Enable usage with RLN SDK](https://github.com/waku-org/pm/issues/347) - -**Owner**: App/Chat Dev - -#### **Feature**: [Rate Limit Manager](/FURPS/application/rate_limit_manager.md) - -**FURPS**: -- F7. Can consume RLN API to access rate limit and current quota. - -#### **Feature**: [Group Chat](/FURPS/application/group_chat.md) - -**FURPS**: -- S3. SDK can be instantiated with a RLN-enabled Waku node. - -**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) \ No newline at end of file diff --git a/draft-roadmap/formalize_and_expand_waku_web_apps.md b/draft-roadmap/formalize_and_expand_waku_web_apps.md deleted file mode 100644 index 80e9f27..0000000 --- a/draft-roadmap/formalize_and_expand_waku_web_apps.md +++ /dev/null @@ -1,163 +0,0 @@ -# Logos Web Apps - -**Estimated date of completion**: 19 Dec 2025 - -**Resources Required for 2025H2**: -- 1.5 engineers for 6 months - -Harden select Waku Web apps by extracting libraries and writing protocol specifications: - -- Qaku (Q&A over Waku): harden Waku to MVP level, so it can be used for IFT Town Halls, and Logos physical events. - - Integrate SDS and write specs. -- Logos Operators Forum: Build a web forum PoC over Waku to serve as a basis for a decentralized Logos forum (opchan). - - Added: Extend the Forum PoC to new FURPS, to align with Logos Movement needs. - -Explore Codex x Waku integration, in Qaku and one other application. - -Develop 10 Waku Web Apps PoC, and push them to the community to "teach them how to hunt" as well as inspire developers -to build over Waku. - -## Strategic Objective - -Logos Movement Community Enabling - -## FURPS - -## Risks - -| Risk | (Accept, Own, Mitigation) | -|----------------------------------------------------|----------------------------------------------------------------| -| Logos Core Readiness | Get involed early with Logos Core, tinker and provide feedback | -| Experimental application spam protection for Forum | Focus on MVP to get user feedback early | -| Spec writing by non-researchers | Push for early specs, to enabling feedback and mentoring | - -## Deliverables - -### [Forum PoC](https://github.com/waku-org/pm/issues/292) - -**Owner**: App/Chat Dev - -**Feature**: [Waku Forum](/FURPS/application/forum.md) - -**FURPS**: -- F1-11 -- U1-10 -- R1-2 - -**Checklist**: -- [ ] Specs: link to specs -- [ ] Code: link to GitHub issues/PRs/Epic -- [ ] Dogfood: link to dogfooding session/artefact -- [ ] Docs: links to README.md or docs.waku.org (TBD) - -### [Codex for Message Archival PoC](https://github.com/waku-org/pm/issues/293) - -**Owner**: App/Chat Dev - -**Feature**: [Codex Archiving PoC](/FURPS/application/codex_archiving.md) - -**FURPS**: - -- F1. Any end user can publish a backup snapshot of the entire SDS log to Codex. -- F2. End user (may be privileged) can publish the corresponding Codex CID with metadata over Waku to a dedicated snapshot content topic. -- F3. Participants can query the Waku snapshot topic for the latest CID. -- F4. Participants can retrieve the archived messages from Codex. -- F5. Participants can perform a store Query for more recent messages following the snapshot timestamp and SDS state. - -- U1. Workflow should be conceptually identical, whether the Codex interaction is via a local node or Codex gateway. -- U2. Publishing or retrieving via Codex should be optional. - -- S1. Developers can use this protocol in web applications. - -**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) - -### [Reliable Qaku & library](https://github.com/waku-org/pm/issues/287) - -**Owner**: App/Chat Dev - -**Feature**: [Qaku](/FURPS/application/qaku.md) - -**FURPS**: (see GitHub [issue](https://github.com/waku-org/pm/issues/292)) -- F1-21 -- U1-7 -- R1 -- P1 -- S1-3 - -**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) - -### [Build Ten Waku Web Apps](https://github.com/waku-org/pm/issues/349) - -**Owner**: App/Chat Dev - -**No FURPS** - -**Output**: 10 working Waku Web apps of various sort. - -- The apps need to be functioning and deployed, PoC level. -- Broadcast to the community must happen (Logos/Waku Discord, Logos/Vac Forums, conference talks, Twitter, etc). -- Codex integration should be considered for each app. - -**Checklist**: - -- [ ] Code: a public GitHub repo -- [ ] Dogfood: link to dogfooding session/artefact -- [ ] Promote the app - - [ ] Logos Forum Post - - [ ] Walkthrough Video - - [ ] Social media post for re-broadcast - -### [Build One Waku Logos Core App](https://github.com/waku-org/pm/issues/350) - -**Owner**: App/Chat Dev - -**No FURPS** - -**Output**: 1 working Logos Core App. - -- The app needs to be functioning, PoC level. -- Broadcast to the community must happen (Logos/Waku Discord, Logos/Vac Forums, conference talks, Twitter, etc). -- May use Waku SDK or Chat SDK. - -**Checklist**: - -- [ ] Code: a public GitHub repo -- [ ] Dogfood: link to dogfooding session/artefact -- [ ] Promote the app - - [ ] Logos Forum Post - - [ ] Walkthrough Video - - [ ] Social media post for re-broadcast - -### [Open Forum to Web3 Users and Anons](https://github.com/waku-org/pm/issues/351) - -**Owner**: App/Chat Dev - -**Feature**: [Waku Forum](/FURPS/application/forum.md) - -**FURPS**: -- F2. Only users owning Logos ordinal or an ENS can create a cell. -- F12. Users can identify themselves by signing with their Web3 key. -- F13. Posts, comments and cells have a relevance index, which can be used to order or hide them in the UX. -- F14. The relevance index is lowered for post and comments which are moderated, or from a moderated user. -- F15. The relevance index is increased if the author owns an ENS or Logos ordinal. -- F16. The relevance index is increased if the post or comment is upvoted by an ENS or Logos ordinal owner. -- F17. The relevance index is increased if the post has a comment from an ENS or Logos ordinal owner. -- F18. Anonymous users can upvote, comments and post. - -- U11. ENS holders can choose to use an ENS for display purposes. -- U12. The relevance index is used to push most relevant posts and comments on top. - - -**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) diff --git a/draft-roadmap/foundation_for_communities_optimisation.md b/draft-roadmap/foundation_for_communities_optimisation.md deleted file mode 100644 index fcb02cd..0000000 --- a/draft-roadmap/foundation_for_communities_optimisation.md +++ /dev/null @@ -1,24 +0,0 @@ -# [Foundation for Communities Optimisation](https://github.com/waku-org/pm/milestone/31) - -**Estimated date of completion**: 31 Oct 2025 (Final clean-up to be merged after a few Status app releases) - -**Resources Required for 2025H2**: -- 1 App/Chat engineer for 2 weeks (only work will be to rebase and merge an existing clean-up PR) -- Vac/QA to run status-backend tests -- Status/QA and dev for reviews and testing - -Once completed, the usage of content topics by Communities will be simplified, -enabling both improvements in terms of store queries and light mode message reception, -but also enabling future optimization and improvements at a lower cost. -Moreover, Communities traffic will be separated from other functionalities. -This enables easy bandwidth and performance improvements (remove usage of relay for large messages, -reduce message retention and hence DB size for control messages), as well as protecting users that do not -use communities from Communities traffic. -Finally, Communities traffic will be segregated in a few shards, per message types; -enabling future bandwidth or performance optimization such as setting up different DB per message type, -reducing retention time for control messages, or disabling the usage of relay for large messages. - - -**FURPS**: [Status Communities](/FURPS/application/status_communities.md): all. - -**Milestone and deliverables**: https://github.com/waku-org/pm/milestone/31 \ No newline at end of file diff --git a/draft-roadmap/harden_rln_testnet.md b/draft-roadmap/harden_rln_testnet.md deleted file mode 100644 index 00510f4..0000000 --- a/draft-roadmap/harden_rln_testnet.md +++ /dev/null @@ -1,96 +0,0 @@ -# Harden RLN Testnet Deployment - -**Estimated date of completion**: 30 Sep 2025 - -**Resources Required for 2025H2**: -- 1 js-waku dev for 4 weeks. -- 1 core researcher for 6 weeks. - -The recent deployment and dogfooding of the [new RLN smart contract](https://github.com/waku-org/pm/milestone/34) on Linea Sepolia has unveiled several issues: - -- Attempt to use a JavaScript RLN library in https://rln.waku.org for credential generation led to interop issue with nwaku/zerokit -- Some zerokit quirk around endianness that is different from Web3 RPC practice -- Spamming of the contract due to "free mint" of the Sepolia ERC-20 token (representing DAI for test purposes) - -With this milestone, we tackle the lesson learned from dogfooding by: - -- Using zerokit in the browser, and working with Vac-ACZ team to reach adequate UX -- Apply restrictions on testnet contract to allow dogfooding, without exhausting the rate limit due to the fact that testnet is free (as in cheap). - -## Strategic Objective - -Logos Vision: Core Values Alignment - -## FURPS - -- [RLN Membership Management](/FURPS/application/rln_membership_management.md): R1 - -## Risks - -| Risk | (Accept, Own, Mitigation) | -|------------------------|------------------------------------------------------------------------------------------------------------------| -| Smart contract Changes | Iterative delivery of smart contract changes to allow dogfooding without excessive smart contract logic | -| Zerokit | Close collaboration with Vac-ACZ and clear expression of [requirements](https://github.com/waku-org/pm/pull/329) | - -## Deliverables - -### [Zerokit is used in the Browser for Credentials Management](https://github.com/waku-org/pm/issues/341) - -**Owner**: js-waku - -**Feature**: [RLN Membership Management](/FURPS/application/rln_membership_management.md) - -**FURPS**: -- R1. Import and exports are interoperable across all implementations. - -**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) - -### [Minting of (Sepolia) ERC-20 Tokens for RLN Deposits is permissioned](https://github.com/waku-org/pm/issues/334) - -**Owner**: core research - -**Feature**: [ERC-20 Testnet Token for RLN Deposit](/FURPS/application/erc-20_testnet_token_for_rln_deposit.md) - -**FURPS**: -- F1. Contract owner can mint tokens to any address for free. -- F2. White-listed wallet addresses can mint tokens to any address for free. -- F3. Contract owner can add or remove wallet addresses to the white-list. - -- U1. Token name is `TST`. - -- +1. Deployed on Linea Sepolia. -- +2. Used as ERC-20 deposit token for Linea Sepolia RLN smart contract deployment. - -**Feature**: [RLN Smart Contract](/FURPS/core/rln_smart_contract.md) - -- P2. Rate limit variables, in combination with good defaults on software side, enable around 5,000 registrations. - -**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) -- -### [Minting of (Sepolia) ERC-20 Tokens for RLN Deposits Burns Sepolia Eth](https://github.com/waku-org/pm/issues/335) - -**Owner**: core research - -**Feature**: [ERC-20 Testnet Token for RLN Deposit](/FURPS/application/erc-20_testnet_token_for_rln_deposit.md) - -**FURPS**: -- F4. Eth (Sepolia) is burnt to mint tokens to any address. - -- U2. Usage of Metamask Faucet (usually 0.1 Linea Sepolia Eth) should enable enough `TST` token minting to acquire 2-3 RLN memberships. - -- +1. Deployed on Linea Sepolia. -- +2. Used as ERC-20 deposit token for Linea Sepolia RLN smart contract deployment. - -**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) diff --git a/draft-roadmap/hardening_and_scaling_foundation_for_private_chat.md b/draft-roadmap/hardening_and_scaling_foundation_for_private_chat.md deleted file mode 100644 index cc80266..0000000 --- a/draft-roadmap/hardening_and_scaling_foundation_for_private_chat.md +++ /dev/null @@ -1,41 +0,0 @@ -# [Hardening and Scaling Foundations for Private Chats](https://github.com/waku-org/pm/milestone/40) - -**Estimated date of completion**: Completed with reduced scope - -**Resources Required for 2025H2**: -- Waku App/Chat engineer: support Vac-DST and Vac-QA -- Vac-DST: status-backend benchmarks -- Vac-QA: Mobile specific scenarios done on status-backend - -With this milestone, we establish a foundation for scaling one-to-one and private group chats to support a larger -number of users. Additionally, we will harden the underlying protocols by studying and refining the current -specifications, as well as isolating user traffic from other features. - -Our approach to RLN integration will involve two initial steps. First, we will implement a low rate limit and -collaborate with the Status team to address the user experience challenges that arise. By combining this with clear -specifications, we will be able to better understand scalability for one-to-one chats, including the relationships -between user count, usage, and bandwidth/resource utilization. - -Furthermore, the enhanced specifications will enable the Vac-QA team to expand test coverage, increasing confidence in -reliability and facilitating any future refactoring efforts. - -To achieve this milestone successfully, it is essential that one-to-one chats are isolated from other features using -Waku, such as Communities, user settings backup, and device pairing/synchronization. Ideally, these features should be -either removed or disabled by default to ensure accurate testing and evaluation. - -**Private chats refers to both one-to-one and private group chats.* - -**FURPS**: - -- [Status Private Chats](/FURPS/application/status_private_chats.md): all - -**Milestone and deliverables**: https://github.com/waku-org/pm/milestone/40 - -## Scope Changes - -1. **Specify Private Chat Protocol**: We stop the exercise here, meaning that we don't formally update/add to Status specs/RFC. - A justification to write a new protocol stack has been [published](https://forum.vac.dev/t/chatsdk-motivations/501). -2. **Private chat rate limit PoC**: Dropped due to higher effort and lower value than anticipated, due to the move towards a new chat protocol. -3. **Global Network Metrics**: Moved to a new milestone - [Improve DevEx: API, TWN, Metrics, Docs](improve_devex_api_twn_metrics_docs.md). -4. **Baseline benchmarks**: Handing over to Vac/DST -5. **status-cli**: Handing over to Vac/QA \ No newline at end of file diff --git a/draft-roadmap/improve_devex_api_twn_metrics_docs.md b/draft-roadmap/improve_devex_api_twn_metrics_docs.md deleted file mode 100644 index 7bf5035..0000000 --- a/draft-roadmap/improve_devex_api_twn_metrics_docs.md +++ /dev/null @@ -1,195 +0,0 @@ -# Improve DevEx: API, TWN, Metrics, Docs - -**Estimated date of completion**: 31 Aug - -**Resources Required for 2025H2**: -- 2 js-waku engineers -- 1.5 nwaku eng -- 1 core research for 1 month -- 1 app chat eng for 1 month - - -Proceed with a number of improvements to the developer experience on Waku, for both internal and external purposes. -This includes: - -- Improving The Waku Network reliability for Logos apps and other web apps -- Simplifying the Waku API -- Measuring Waku usage across all integrations -- Review and setting strategy for Waku documentation -- Testing quic as new transport - -## Strategic Objective - -Logos Movement Community Enabling via Dev-X + Telemetry - -## FURPS - -See deliverables. - -## Risks - -| Risk | (Accept, Own, Mitigation) | -|---------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------| -| Define collaboration with BI for metrics | Communicate | -| Browser reliability is a multi-prong problem (js-waku/libp2p, nwaku/nim-libp2p) | Strong collaboration | -| No "documentation" expert or dedicated resources | outsource help from doc experts in IFT, focus on setting guidelines for all Waku CCs to follow | - - -## Deliverables - -### [Global Network Metrics](https://github.com/waku-org/pm/issues/295) - -**Owner**: App/Chat Dev - -**Feature**: [Network Metrics Tracker](/FURPS/application/network_metrics_tracker.md) - -**FURPS**: -- all - -**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) - -### [Scalable Data Sync in Browser](https://github.com/waku-org/pm/issues/280) - -**Owner**: js-waku - -**Feature**: [SDS](/FURPS/application/sds.md) - -**FURPS**: -- all - -For S2. For Web apps as a developer library. - -**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) - -### Implement Light Push Error codes in The Browser - -**Owner**: js-waku - -**Feature**: [Light Push](/FURPS/core/light_push.md) - -**FURPS**: -- F4. Supports comprehensive error codes for various failure scenarios. -- U4. Provides descriptive error messages in responses. -- R2. Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure). - -For S2. Browser as client -Spec delivery not included. - -**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) - -### [Introduce Waku API in the Browser](https://github.com/waku-org/pm/issues/283) - -**Owner**: js-waku - -**Feature**: [Waku SDK](/FURPS/core/waku_sdk.md) - -**FURPS**: -- F1. Setup, start and stop a Waku node. -- F2. Support edge node operation mode. -- F4. Does automatic peer discovery based on the node platform and operation mode. -- F5. Returns health and connectivity information using proven heuristics. -- F6. Previously discovered peers are persisted across restarted, and potentially used for future connections. -- U1. When setting up a Waku node, no need to specify what protocols to mount, only an operational mode (edge or relay). -- U2. Disconnection detection and recovery, and other peer management matters are automatically handled. -- U3. Developers do not need to specify the protocols used to send and receive messages; it is deduced from the mode of operation. -- U4. Developers pass and receive data to the API in types native to the wrapping language. -- U5. By default, auto-sharding is applied, meaning developers do not need to be concerned by sharding; pubsub topics are never exposed. -- U6. 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 S3. Browser; distribution via npmjs.com. - -**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) - -### [Introduce Waku API in nwaku](https://github.com/waku-org/pm/issues/305) - -**Owner**: nwaku - -**Feature**: [Waku SDK](/FURPS/core/waku_sdk.md) - -**FURPS**: -- F1. Setup, start and stop a Waku node. -- F3. Support relay node operation mode. -- F4. Does automatic peer discovery based on the node platform and operation mode. -- F5. Returns health and connectivity information using proven heuristics. -- F6. Previously discovered peers are persisted across restarted, and potentially used for future connections. -- U1. When setting up a Waku node, no need to specify what protocols to mount, only an operational mode (edge or relay). -- U2. Disconnection detection and recovery, and other peer management matters are automatically handled. -- U3. Developers do not need to specify the protocols used to send and receive messages; it is deduced from the mode of operation. -- U4. Developers pass and receive data to the API in types native to the wrapping language. -- U5. By default, auto-sharding is applied, meaning developers do not need to be concerned by sharding; pubsub topics are never exposed. -- U6. 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; import via git path. -- S2. Golang library; available on pkg.go.dev. - -**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) - -### [Review Documentation and Define Guidelines](https://github.com/waku-org/pm/issues/323) - -**Owner**: core research - -(No FURPS) - -- [ ] Review the current developer documentation - - [ ] And contributor doc -- [ ] Define a guideline for Waku teams to - - [ ] Minimum requirements to consider "doc done" for any future deliverable - - [ ] How to contribute to documentation: location, format -- [ ] Setup an initial structure to enable the guideline - -### [Trial QUIC](https://github.com/waku-org/pm/issues/324) - -**Owner**: nwaku - -**Feature**: [nwaku](/FURPS/application/nwaku.md) - -**FURPS**: -- S4. QUIC transport is supported for peer-to-peer message routing connections. - -**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) - -### [Optimise Browser Bootstrapping](https://github.com/waku-org/pm/issues/290) - -**Owner**: js-waku - -**Feature**: [js-waku](/FURPS/application/js-waku.md) - -**FURPS**: - -- R1. From an operating state, a node can resume transmitting messages within 1 second after disconnection; in a network with 1 bootstrap node, 100 service nodes and 500 browser nodes (**Vac-DST**) -- P1. From a cold start, a node can start transmitting messages within 5 seconds; in a network with 1 bootstrap node, 100 service nodes and 500 browser nodes (**Vac-DST**) - -**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) diff --git a/draft-roadmap/incentivisation_follow_up.md b/draft-roadmap/incentivisation_follow_up.md deleted file mode 100644 index 579e4f7..0000000 --- a/draft-roadmap/incentivisation_follow_up.md +++ /dev/null @@ -1,30 +0,0 @@ -# Incentivisation and Marketplace Follow-Up Outline - -**Estimated date of completion**: TBD - -**Resources Required for 2025H2**: -- 2.5 core research engineer for 5 months - -Proceed with follow-up step once the [incentivisation light push PoC](https://github.com/waku-org/pm/issues/245) is delivered. - -The exact commitments and deliverables are to be defined as part of the [incentivisation roadmap output](https://github.com/waku-org/pm/issues/246) - -This includes progress towards both incentivisation and marketplace problems. - -## Strategic Objective - -Logos Vision: Core Values Alignment - -## FURPS - -TBD - -## Risks - -| Risk | (Accept, Own, Mitigation) | -|--------|-------------------------------| -| [Risk] | [how to we address this risk] | - -## Deliverables - -TBD \ No newline at end of file diff --git a/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md b/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md deleted file mode 100644 index 2ac1d95..0000000 --- a/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md +++ /dev/null @@ -1,50 +0,0 @@ -# [Integrate nwaku in Status Desktop, relay mode only](https://github.com/waku-org/pm/milestone/33) - -**Estimated date of completion**: 30 June - -**Resources Required for 2025H2**: -- 1 nwaku engineer for maintenance and support -- Vac-QA to run status-backend tests on a nwaku-based build -- Vac-DST to complete benchmark works and proceed with nwaku-based vs go-waku-based status-backend comparisons -- Status-QA to include nwaku-based builds in tests - -With this milestone, Status Desktop builds can use nwaku instead of go-waku. -However, it should be seen as a MVP as further hardening and implementation of light client mode will be missing. -Go-waku will still be used for Status Mobile. - -This strategy enables concrete steps toward sunsetting go-waku in a short period of time, -avoiding a perpetual prototyping phase where many high risk problems (e.g. mobile bundle size, etc) have to be solved before the switch can be made. - -The next milestone will then focus on hardening the nwaku Desktop build -and implement missing features such as Reliability Protocol for resource-restricted. -Once done, it will reduce the scope of go-waku maintenance to light clients only and -drastically reduce the duplicate work done between nwaku and go-waku. - -Note that we want to draw the line to RLN in terms of go-waku maintenance, -meaning that if Status were to use RLN (see Scale 1:1 chat messages PoC), then it should happen with nwaku. - -**FURPS**: - -- [nwaku](/FURPS/application/nwaku.md): F1-3, S1-2, +1 -- [status-go](/FURPS/application/status_go.md): F1, U1, R1, P1, S1-2, +1 - -**GitHub Milestone and deliverables**: https://github.com/waku-org/pm/milestone/33 - -## Enable Waku Metrics in libwaku - -**Owner**: nwaku - -**Feature**: [nwaku](/FURPS/application/nwaku.md) - -**FURPS**: -- F3. Metrics can be enabled in libwaku. - -https://github.com/waku-org/nwaku/issues/3202 - -**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) - -https://github.com/waku-org/nwaku/issues/3202 \ No newline at end of file diff --git a/draft-roadmap/integrate_rln_with_waku_api.md b/draft-roadmap/integrate_rln_with_waku_api.md deleted file mode 100644 index 0e3184e..0000000 --- a/draft-roadmap/integrate_rln_with_waku_api.md +++ /dev/null @@ -1,149 +0,0 @@ -# Integrate RLN With the Waku API - -**Estimated date of completion**: 30 Sep - -**Resources Required for 2025H2**: -- 2 nwaku engineer for 2 months -- 1 js-waku engineer for 2 months -- 1 core research for 1 month -- Support from Vac/ACZ to get zerokit working in the browser. - -Deliver a native RLN library with a deliberate API to manage RLN memberships, as well as proof verification and generation. -This includes extracting RLN Relay as a relay plugin validation strategy, that can then be passed internally to nwaku node -as any other strategy. - -Once delivered, usage of Chat SDK of RLN becomes possible, with clear API to instantiate nwaku library with RLN, as well -as API to manage RLN membership. - -Introduce RLN proof generation and validation in the Browser. RLN API should be similar across all implementations. - -Finally, migrate to Status network L2 testnet and improve UX issues discovered via dogfooding such as rate of RPC Calls. - -## Strategic Objective - -Logos Movement Module Build Out - -## FURPS - -See deliverables. - -## Risks - -| Risk | (Accept, Own, Mitigation) | -|-------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Not all required improvements are yet identified | Dogfooding of the H1 delivery will enable identification of needed improvements, meaning this milestone may change in term of scope and schedule. | -| Dependencies on Nim Web3 library | Previous upgrade of nim web3 libraries have lead to various issues. The dependencies of said library is increasing, meaning potential delay in development. | -| Uncertainty regarding zerokit and wasm in the browser | UX-related property are yet to be explored with the new RLN smart contract. WASM loading and execution may have considerable impact on UX. Collaboration with Vac/ACZ will be required to adapt zerokit for the browser. | -| Smart Contract Changes & Expertise | We expect functional extension of RLN smart contract to potentialy store multiple roots, and maybe other improvement depending on dogfooding. The Solidity knowledge in the team is limited/non-existent so we would need to rely on Vac-SC or upskill. | -| API Refactoring | Extracting RLN as a validation plugin may ensue some API refactoring that may take longer than initially estimated. A conservative estimate will be done. | -| FFI to FFI interaction | The intent will be to have RLN and Waku SDK as 2 separate libraries that can be initialized in any language (e.g Golang). The nim to nim via FFI may raise unforeseen issues . | - -## Deliverables - -### [Implement RLN membership management in nwaku library](https://github.com/waku-org/pm/issues/353) - -**Owner**: nwaku - -**Feature**: [RLN Membership Management](/FURPS/application/rln_membership_management.md) - -**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. - -- R1. Import and exports are interoperable across all implementations. - -- S2. library can be used in Go applications; available on pkg.go.dev. -- S3. library can be used in Rust applications; import via git path. - -- +2. Available for Linea Sepolia Testnet contracts. - -**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) - -### [Implement RLN Onchain Tree Proof generation and verification in the Browser](https://github.com/waku-org/pm/issues/354) - -**Owner**: js-waku - -**Feature**: [RLN Relay](/FURPS/core/rln_relay.md) - -**FURPS**: -- F4. Light push client can be configured to generate proof for outbound messages. -- F5. Filter client can be configured to verify proof for inbound messages. - -- S2. Browser edge nodes can be configured to verify and generate proofs. - -**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) - -### [Extract RLN as a plug-in library from nwaku](https://github.com/waku-org/pm/issues/355) - -**Owner**: nwaku - -**Feature**: [Waku RLN API](/FURPS/core/rln_sdk.md) - -**FURPS**: -- F1. Accepts RLN network configuration at initialization. -- F2. API to pass messages for proof validation. -- F3. API to import RLN credentials, compatible with RLN Membership management. -- F4. API to accept Waku Message and generate proof. -- F5. API to inform on configured rate limit parameters and remaining quota. - -- U1. TWN RLN configuration is applied by default. -- U2. No boilerplate code beyond initialization is necessary to pass RLN instance in a Waku API implementation. -- U3. Rate usage is persisted across restarts. - -- S1. library can be used in Go applications; available on pkg.go.dev. -- S2. library can be used in Rust applications; import via git path. -- S3. library can be used in Nim applications; import via git path. - -- +1. Only one set of credentials can be used at a given t - -**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) - -### [Deploy RLN Contracts to Status L2 testnet](https://github.com/waku-org/pm/issues/356) - -**Owner**: nwaku - -**Feature**: [RLN Smart Contract](/FURPS/core/rln_smart_contract.md) - -**FURPS**: -- +1. Smart Contracts are deployed on Status L2 Sepolia. -- +2. TWN uses smart contracts deployed on Status L2 Sepolia. - -**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) - -### [Improve RLN UX by reducing contract interactions](https://github.com/waku-org/pm/issues/344) - -**Owner**: core research - -**Feature**: [RLN Smart Contract](/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. - -**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) \ No newline at end of file diff --git a/draft-roadmap/introduce_e2e_reliability_in_status.md b/draft-roadmap/introduce_e2e_reliability_in_status.md deleted file mode 100644 index 535ed51..0000000 --- a/draft-roadmap/introduce_e2e_reliability_in_status.md +++ /dev/null @@ -1,71 +0,0 @@ -# Introduce E2E Reliability in Status Communities - -**Estimated date of completion**: 31 Aug 2025 - -**Resources Required for 2025H2**: -- 1 app chat engineer for 2 months -- Status dev for review support -- Status-QA and Vac-QA for new tests -- (core research work finishes by end of June) - -(Renamed "e2e reliability protocol " milestone, but work as per scope, only split a deliverable) - -To solve reliability is to solve two problems: - -1. High heuristic that messages are received and sent -2. Ability to know whether messages are received or sent - -Problem (1) can never be 100% reliable in a network environment. The previous milestones focused on it. -To solve (2), is to create an end-to-end protocol, sender to recipient, that enables the ability to know whether recipient(s) have received messages. - -With this milestone, we design and deliver a first PoC for an end-to-end reliability protocol. -This protocol will be specified and implemented in the Status app for Status Communities chat rooms; -as well as in the browser for PoC Web Apps such as Qaku and Logos Forum. - -**FURPS** (see deliverables) - -**GitHub Milestone and deliverables**: https://github.com/waku-org/pm/milestone/29 - -## [SDS protocol in Status - basic integration](https://github.com/waku-org/pm/issues/194) - -**Owner**: core research - -**Feature**: [SDS](/FURPS/application/sds.md) - -**FURPS**: -- F1. Ability to know that a published message has been received by at least one member of the group (and could therefore eventually be retrieved by other members). -- F2. Ability for participants to know when they have missed a message -- U1. When sending a message to a large group, the application knows whether it was received by other group members, with high probability -- U2. When being part of a large group, the application is able to know whether they are missing messages -- R1. When sending a message in a group, the publisher can ascertain the message was received by at least one recipient **(Vac-QA)** -- R2. When receiving messages in a group, the receiver can ascertain most missed messages by receiving one recent message from the group. **(Vac-QA)** -- P1. When sending a message in a group, the publisher can ensure the message was received by at least one recipient within `S` seconds **(Vac-DST)** -- P2. When receiving messages in a group, the receiver can detect 90% of missed messages within `3*S` seconds - -For S1. Applied to Communities channels on Status Desktop - -**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) - -## [SDS protocol in Status - basic recovery](https://github.com/waku-org/pm/issues/304) - -**Owner**: chat app dev - -**Feature**: [SDS](/FURPS/application/sds.md) - -**FURPS**: -- F3. Ability to resend unacknowledged messages -- F4. Ability to retrieve missed messages using Waku store protocol -- U3. When being part of a large group, the application is able to retrieve missed messages -- P3. When receiving messages in group, the receiver can reach eventual consistency within `6*S` seconds **(Vac-DST)** - -For S1. Applied to Communities channels on Status Desktop - -**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) diff --git a/draft-roadmap/introduce_mixnet_for_message_sending.md b/draft-roadmap/introduce_mixnet_for_message_sending.md deleted file mode 100644 index 6bcc8e3..0000000 --- a/draft-roadmap/introduce_mixnet_for_message_sending.md +++ /dev/null @@ -1,49 +0,0 @@ -# Introduce Mixnet For Message Sending - -**Estimated date of completion**: 10 Oct 2025 - -**Resources Required for 2025H2**: - -- 1 core research engineer for 3 months - -A PoC implementation to improve anonymity in Waku message publishing by mixing Waku Lightpush requests and responses. - -## Strategic Objective - -Logos Vision: Core Values Alignment - -## FURPS - -See deliverables. - -## Risks - -| Risk | (Accept, Own, Mitigation) | -| --------------------------------------- | ------------------------------------------------------------------ | -| Dependency on mix library | Strong collaboration, integrate early, get involved behind the API | -| Impact on latency and other UX elements | Run simulations and studies to understand impact | - -## Deliverables - -### [Integrate libp2p mix into lightpush](https://github.com/waku-org/pm/issues/291) - -**Owner**: core research - -**Feature**: [Mix](/FURPS/core/mix.md) - -**FURPS**: - -- F1. Relay nodes can mount mixnet protocol, acting as sender, intermediary or exit nodes. -- F2. Nodes can connect to other nodes that support mix using static configuration. -- F3. Client nodes can send light push requests over the mixnet before delivery to a service node. -- F4. Client nodes can receive a response to a light push request over the mixnet. - -- S1. `wakunode2` for intermediary and exit nodes. -- S2. nwaku CLI for sender nodes. - -**Checklist**: - -- [ ] Specs: link to specs -- [ ] Code: link to GitHub issues/PRs/Epic -- [ ] Dogfood: link to dogfooding session/artefact -- [ ] Docs: links to README.md or docs.waku.org (TBD) diff --git a/draft-roadmap/mixnet_usage_improvements.md b/draft-roadmap/mixnet_usage_improvements.md deleted file mode 100644 index 519d97c..0000000 --- a/draft-roadmap/mixnet_usage_improvements.md +++ /dev/null @@ -1,68 +0,0 @@ -# Add peer discovery to mixnet and support browser - -**Estimated date of completion**: 31 March 2026 - -**Resources Required for 2025H2**: - -- 1 core research engineer for 5 months - -Peer discovery for mixnet was descoped from the previous milestones due to upcoming challenges around ENR usage and modification to libp2p needed to support mix peers in rendezvous. - -Web apps have been a strong dogfooding and adoption driver for Waku, especially for edge nodes. Adding mix will not only enable wider dogfooding, but also increase anonymity for browser users. - -## Strategic Objective - -Logos Vision: Core Values Alignment - -## FURPS - -See deliverables. - -## Risks - -| Risk | (Accept, Own, Mitigation) | -| --------------------------------------- | ------------------------------------------------------------------ | -| Impact on latency and other UX elements | Run simulations and studies to understand impact | -| Unknowns in implementing js-mix | Further study and understanding of js-libp2p internals | -| Possible `exit==destination` in dependency library impact existing implementation | Frequent syncing with Vac and p2p team to understand impact and progress | - -## Deliverables - -### [Implement and integrate libp2p mix in js-waku for light push](https://github.com/waku-org/pm/issues/365) - -**Owner**: Core Research - -**Feature**: [Mix](/FURPS/core/mix.md) - -**FURPS**: - -- P1. Payloads are limited to 4kB - -- S3. Browser based apps built using js-waku support acting as entry nodes. - -**Checklist**: - -- [ ] Specs: link to specs -- [ ] Code: link to GitHub issues/PRs/Epic -- [ ] Dogfood: link to dogfooding session/artefact -- [ ] Docs: links to README.md or docs.waku.org (TBD) - -### [Implement basic discovery for mix](https://github.com/waku-org/pm/issues/366) - -**Owner**: Core Research - -**Feature**: [Mix](/FURPS/core/mix.md) - -**FURPS**: - -- F5. Nodes can discover other nodes that support mix using available peer discovery mechanisms. - -- S4. Browser based apps built using js-waku support discovering mix nodes using available peer discovery mechanisms. - -**Checklist**: - -- [ ] Specs: link to specs -- [ ] Code: link to GitHub issues/PRs/Epic -- [ ] Dogfood: link to dogfooding session/artefact -- [ ] Docs: links to README.md or docs.waku.org (TBD) - diff --git a/draft-roadmap/rln_mainnet.md b/draft-roadmap/rln_mainnet.md deleted file mode 100644 index 15c9c6b..0000000 --- a/draft-roadmap/rln_mainnet.md +++ /dev/null @@ -1,80 +0,0 @@ -# RLN Mainnet - -**Estimated date of completion**: 30 June 2025 - -Once complemented, the economical behaviour of RLN will have been specified, implemented and discussed with the Status team. An implementation of RLN for light clients will also be done, to demonstrate RLN’s UX with onchain Merkle tree. Finally, the smart contract will be deployed on mainnet. - -It will then be possible to design the usage of RLN in Status. - - -**deliverables**: https://github.com/waku-org/pm/milestone/34 - -## [Implement RLN smart contract for paid, multilevel memberships](https://github.com/waku-org/pm/issues/228) - -**Owner**: research - -**Feature**: [RLN Smart Contract](/FURPS/core/rln_smart_contract.md) - -**FURPS**: - -- F1. RLN rate limit can be defined in terms of multiple messages per epoch. -- F2. RLN rate limit is set at membership insertion -- 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 -- U1. Application developers can set RLN rate limit at insertion. - -**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) - -## [TWN supports RLN onchain tree and deposits, existing memberships only](https://github.com/waku-org/pm/issues/286) - -**Owner**: nwaku - -**Feature**: [RLN Smart Contract](/FURPS/core/rln_smart_contract.md) - -**FURPS**: - -- F3. RLN initialization only requires Web3 RPC `call`s, no blockchain events are needed. -- U2. User do not need to wait for merkle tree synchronization and building to start relaying - or sending messages. -- P1. New node setup with an RLN membership can be ready to verify RLN proof within 5s, - no matter the size of the tree **(Vac-DST)**. -- +1. Smart Contracts are deployed on Linea Testnet. -- +2. TWN uses smart contracts deployed on Linea Testnet. - -**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) - -**Owner**: js-waku - -**Feature**: [RLN Membership Management](/FURPS/application/rln_membership_management.md) - -**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. -- R1. Import and exports are interoperable across all implementations. -- +1. Deployed on https://rln.waku.org -- +2. Available for Linea Sepolia Testnet contracts. -- +3. Proof generation and validation is out of scope. - -For S1. Browser application, using web3 wallet browser extensions. - -**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) diff --git a/draft-roadmap/streamline_dev_ex_local_dev_rust.md b/draft-roadmap/streamline_dev_ex_local_dev_rust.md deleted file mode 100644 index 6a825c2..0000000 --- a/draft-roadmap/streamline_dev_ex_local_dev_rust.md +++ /dev/null @@ -1,166 +0,0 @@ -# Streamline DevEx: Mobile, Rust and Web dev - -**Estimated date of completion**: 30 Nov - -**Resources Required for 2025H2**: -- nwaku 3 eng during 6 weeks -- js-waku 2 eng 6 Week Sep - -Complete the Waku API implementation in nwaku by implementing edge node mode (Status' Light Mode). - -Streamline the Developer Experience by delivering a Rust SDK that implements the full Waku API and is available on crates.io. -As well as building an easy-to-use local dev environment from the browser, enabling developers to build web apps without -relying on external connectivity. Provide a similar harness to deploy a local RLN dev environment. - -Finalize the integration of nwaku in Status application by setting up nwaku-based build for Mobile platforms. - -Lastly, develop a PoC protocol to demonstrate the usage of Waku as a Signal network, using WebRTC as example. -This was identified as a demanded demonstration of Waku's capabilities as part of the [Waku MVP analysis](https://www.notion.so/Waku-MVP-1838f96fb65c8039acabf8a6a1e689e7). - -## Strategic Objective - -Logos Movement Community Enabling via Dev-X - -## FURPS - -See deliverables. - -## Risks - -| Risk | (Accept, Own, Mitigation) | -|-------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| nwaku performance | Performance of nwaku in comparison to go-waku will be measured by DST during H2 and may raise issues that will become blockers for pratical usage of nwaku in Mobile. | -| Publishing to crates.io | One of the challenge to publish libwaku on crates.io is the package size. Several strategy may be developed and tried to find a way to distribute Nim-based Rust crates. | -| Local dev harness | Creating a local dev environment may be a challenge due to the nature of Waku and RLN, as we would need to locally coordinate bootstrap and blockchain emulation. | - -## Deliverables - -### [Edge Mode in Nwaku](https://github.com/waku-org/pm/issues/357) - -**Owner**: nwaku - -#### **Feature**: [status-go](/FURPS/application/status_go.md) - -**FURPS**: -- F2. Nwaku is the used Waku implementation for light mode. -- S3. Light mode is supported. - -#### **Feature**: [nwaku](/FURPS/application/nwaku.md) - -**FURPS**: -- S6. libwaku support edge node functionalities. - -**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) - -### [Nwaku in Status Mobile](https://github.com/waku-org/pm/issues/358) - -**Owner**: nwaku - -**Feature**: [status-go](/FURPS/application/status_go.md) - -**FURPS**: -- S4. Status Mobile binary for Android and iOS. -- S5. Status Tablet binary for Android and iOS. - -- +2. Status Mobile and Tablet CI builds binaries with nwaku, alongside go-waku-based binaries. - -**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) - -### [Waku Rust SDK](https://github.com/waku-org/pm/issues/289) - -**Owner**: nwaku - -**Feature**: [Waku SDK(/FURPS/core/waku_sdk.md) - -**FURPS**: -- S4. Rust; available on crates.io. - -**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) - -### [Local Web Dev Harness](https://github.com/waku-org/pm/issues/359) - -**Owner**: js-waku - -**Feature**: [Local Web Dev Harness](/FURPS/application/local_web_dev_harness.md) - -**FURPS**: - -- F1. Runs local Waku node to test Web application without relying on external connectivity. -- F2. js-waku runs in NodeJS for testing and CI purposes. - -- U1. Developer only need to run a script or preset to start local Waku node and have their web app connect to it. -- U2. Potential WSS/HTTPS issues are worked around so that developer does need to manually generate or import SSL certificates. -- U3. There is an easy option for the developer to bootstrap and connect to local node, instead of external peers. - -- S1. Linux and Mac development environments. -- S2. Local network without RLN. -- S3. Chrome and Firefox browsers. - -**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) - -### [Local Dev RLN Harness](https://github.com/waku-org/pm/issues/360) - -**Owner**: nwaku - -**Feature**: [Local Dev RLN Harness](/FURPS/application/local_dev_rln_harness.md) - -**FURPS**: -- F1. Runs local Ethereum environment. -- F2. Deploys ERC-20 and RLN smart contract. -- F3. Utility to fund wallet addresses with necessary tokens for deposit for RLN membership registration. - -- U1. Developer only need to run a script to setup local blockchain environment. -- U2. Developers can run documented RPC calls to fund wallet addresses. -- U3. Developers can run documented RPC calls to interact with RLN smart contract. - -**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) - -### [Waku as a Signal Network (WebRTC) PoC](https://github.com/waku-org/pm/issues/298) - -**Owner**: js-waku - -**Feature**: [Waku as a Signal Network](/FURPS/application/signal_network.md) - -**FURPS**: - -- F1. Establish direct connection to remote peer using their public key as identifier. - -- U1. Developers can implement their own application-level discovery method. -- U2. Only remote peer's public key is needed to initiate connection. -- U3. Hook is provided for developer to filter inbound connection requests. - -- R1. End-to-end reliability is implemented for the signaling conversation. -- R2. No provided reliability for established connections, left to the developer (e.g. keep alive). - -- S1. Developers can use this protocol in web application, imported from npmjs.com. -- S2. Developers can use this protocol to initiate WebRTC connections. -- S3. Only 1:1 direct connections are supported. - -- +1. Network observers cannot retrieve node connection details; forward secrecy is **not** included. -- +2. STUN and TURN servers may be required for WebRTC usage. - -**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) \ No newline at end of file diff --git a/draft-roadmap/upgrade_nim_usage.md b/draft-roadmap/upgrade_nim_usage.md deleted file mode 100644 index aa9ff44..0000000 --- a/draft-roadmap/upgrade_nim_usage.md +++ /dev/null @@ -1,108 +0,0 @@ -# Upgrade Nim Usage - -**Estimated date of completion**: 19 Dec - -**Resources Required for 2025H2**: -- 2 nwaku eng for 3 months -- Support from Vac/Nim team - -Improve usage of Nim related tooling and design patterns by proceedings with PoCs to discover potential gains and caveats. -This includes adoption of Nimble, dogfooding VSCode plugin and iteration on C-Binding methodology. - -## Strategic Objective - -Logos Movement Community Enabling: Dev Journey - -## FURPS - -See deliverables. - -## Risks - -| Risk | (Accept, Own, Mitigation) | -|---------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| Maturity of tooling | This milestone focusing on trying out fresh Nim tooling, hence it may not be possible to output a PoC, but instead raising a series of upstream issues. | -| Actual value/impact | The direct value on dev ex is not always clear, especially for Nimble. There is hope on bette contributor experience, but the end impact may mostly be on improving Nim tooling by providing constructive feedback. | - -## Deliverables - -### Migrate nwaku to Nimble PoC - -Note: maybe taken over by Vac-Nim - -**Owner**: nwaku - -**Feature**: [nwaku](/FURPS/application/nwaku.md) - -**FURPS**: -- U1. Uses nimble for package management and build. -- U2. Can be imported as a nim library using nimble. - -**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) - -### Dogfood VSCode Plugin and Nimsuggest - -**Owner**: nwaku - -**No FURPS** - -**Depends on Migrate nwaku to Nimble PoC** - -**Output**: -- [ ] Test nimsuggest in the nwaku codebase -- [ ] Create reproducible setup for crashes and poor performance, open upstream issues. -- [ ] Optional: provide a plan to make nwaku better compatible with nimsuggest (eg. no git submodule, less macros, etc) - - -### Streamline FFI API Creation by using Protobuf types instead of JSON PoC - -**Owner**: nwaku - -**Feature**: [Waku SDK](/FURPS/core/waku_sdk.md) - -**FURPS**: -- F8. When wrapping the C API, conversion from native types to Protobuf is needed by the wrapper (PoC). - -- U7. When wrapping the C API, a protobuf definition can be used to generate native types for the host language (PoC). - -**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) - - -### [Create nim-ffi, a library to easily exposes c-bindings from Nim](https://github.com/waku-org/pm/issues/332) - -**Owner**: nwaku - -**Feature**: [Nim FFI](/FURPS/application/nim_ffi.md) - -**FURPS**: - -- F1. Provides the core logic needed to expose any synchronous or asynchronous Nim library to a C-FFI library. - -- U1. Introduce new pragma definitions, such as `{.ffi.}`, to appropriately annotate types and procedures. -- U2. Any Nim project can use it and can be installed using Nimble, - similarly to how nim-chronos is imported. -- U3. The interaction with the exposed C library can be done using JSON. -- U4. The interaction with the exposed C library can be done using protobuf. - -- R1. Nim-FFI does not leak memory. -- R2. The exposed C library never hangs when working asynchronously. - -- S1. The exposed C library can be used in Golang. -- S2. The exposed C library can be used in Rust. -- S3. The exposed C library can be used in Python. - -- +1. `nwaku` repository uses `nim-ffi` to expose the existing `libwaku` functionality. - -**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) \ No newline at end of file