diff --git a/2025H1-SUMMARY.md b/2025H1-SUMMARY.md index 4bd7789..2fe93ec 100644 --- a/2025H1-SUMMARY.md +++ b/2025H1-SUMMARY.md @@ -29,10 +29,11 @@ | 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 protocol to Web applications | 5/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 @@ -60,6 +61,7 @@ | 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 @@ -86,13 +88,7 @@ ## Funding and Resources -| Name | Amount | -|------------------------|---------------------| -| Headline Budget Ask | k-USD | -| Final Budget Used | k-USD | -| Resource Count Initial | 21 | -| Resource Count Final | 20 | -| Open Positions | 0 (2 backfill lost) | +https://notes.status.im/E_bcw7cLR36QKI39k-PlMg# ## ⚠️ Keys Risks & Controls @@ -111,5 +107,7 @@ - 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 (Messaging) API" was initially a tidy up, as Waku was already integrated in Status. With a focus towards Chat SDK and growing a developer community, it became an urgent-important item. - 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 new file mode 100644 index 0000000..cbfc51f --- /dev/null +++ b/2025H2-SUMMARY.md @@ -0,0 +1,136 @@ +# Milestones Presentation (Half-Year to Dec-2025): Waku + +## 🧭 Key Outcome(s) of Vision you are supporting + +- Create Chat SDK MVP - one-to-one (Nim, Rust, Golang), support Status' technical roadmap, supports Logos Movement and Logos Core by enabling secure conversations over Waku +- Simplify the API of the Waku SDK (Browser, Nim, Rust, Golang), supports Chat SDK, Logos Movement and Logos Core, make it is easy to integrate +- Improve Waku Developer Experience by stabilizing The Waku Network and reviewing Docs: Support Logos Movement, make it is easy to integrate +- Deploy metrics to measure Waku and any Waku app's level of adoption: Support measuring success of Logos Technology adoption +- Introduce mixnet for message sending: Support Logos Vision of a private technology stack +- Formalize and Expand Waku Web Apps: Support Logos Movement on teaching them how to hunt +- Integrate RLN with Waku API: Supports Chat SDK, and Logos Movement to make it easy it to integrate Waku RLN +- Streamline DevEx: Mobile, and Web dev, supporting Status to have nwaku and chat sdk on mobile, provide tooling to make it easy to integrate js-waku +- Extend Chat SDK with Group conversations: ditto create chat sdk +- Nim Usage Improvement: Dedicate time to improve nim usage (nimble usage, iterate on ffi api, study `nimsuggest` behaviour): to improve nwaku contributor experience, enable all goals above and make it easy to contribute +- Continue Waku Incentivisation: Finish Light push PoC and define next steps, to make Waku infrastructure decentralized and sustainable, as per Logos Vision + +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 is awol. + +## 🧩 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 | Pending | +| 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 | Pending | +| 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 | + +### 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 | | + +### 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/application/chat_sdk.md b/FURPS/application/chat_sdk.md new file mode 100644 index 0000000..8258f87 --- /dev/null +++ b/FURPS/application/chat_sdk.md @@ -0,0 +1,39 @@ +# 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 new file mode 100644 index 0000000..090c86e --- /dev/null +++ b/FURPS/application/codex_archiving.md @@ -0,0 +1,25 @@ +# 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/forum.md b/FURPS/application/forum.md new file mode 100644 index 0000000..46bee15 --- /dev/null +++ b/FURPS/application/forum.md @@ -0,0 +1,55 @@ +# 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 new file mode 100644 index 0000000..69acd0f --- /dev/null +++ b/FURPS/application/group_chat.md @@ -0,0 +1,31 @@ +# 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 index c03ccb4..47e2d6b 100644 --- a/FURPS/application/js-waku.md +++ b/FURPS/application/js-waku.md @@ -1,27 +1,17 @@ # JS-Waku FURPS -TODO - ## Functionality -1. ... - ## Usability -1. ... - ## Reliability -1. ... +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. ... +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 -1. ... - ## + (Privacy, Anonymity, Deployments) - -1. ... \ No newline at end of file diff --git a/FURPS/application/local_dev_rln_harness.md b/FURPS/application/local_dev_rln_harness.md new file mode 100644 index 0000000..f86c6fb --- /dev/null +++ b/FURPS/application/local_dev_rln_harness.md @@ -0,0 +1,23 @@ +# 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 new file mode 100644 index 0000000..65f303f --- /dev/null +++ b/FURPS/application/local_web_dev_harness.md @@ -0,0 +1,24 @@ +# 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 new file mode 100644 index 0000000..d740bd1 --- /dev/null +++ b/FURPS/application/network_metrics_tracker.md @@ -0,0 +1,39 @@ +# 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/nwaku.md b/FURPS/application/nwaku.md index 58101f6..1cc6dd0 100644 --- a/FURPS/application/nwaku.md +++ b/FURPS/application/nwaku.md @@ -4,10 +4,12 @@ 1. nwaku can be compiled as a library, `libwaku`. 2. libwaku exposes c-bindings. +3. Metrics can be enabled in libwaku. ## Usability -1. ... +1. Uses nimble for package management and build. +2. Can be imported as a nim library using nimble. ## Reliability @@ -20,8 +22,13 @@ ## Supportability 1. libwaku, wakunode2 can build on Windows -2. libwaku supports relay functionalities. +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 +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 index 5ba6be1..592be05 100644 --- a/FURPS/application/p2p_reliability.md +++ b/FURPS/application/p2p_reliability.md @@ -14,12 +14,8 @@ ## Reliability -TBD - ## Performance -TBD - ## Supportability 1. Within browser environments (edge node mode) diff --git a/FURPS/application/qaku.md b/FURPS/application/qaku.md new file mode 100644 index 0000000..74dffbe --- /dev/null +++ b/FURPS/application/qaku.md @@ -0,0 +1,54 @@ +# 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 new file mode 100644 index 0000000..34042e8 --- /dev/null +++ b/FURPS/application/rate_limit_manager.md @@ -0,0 +1,36 @@ +# 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 index a61c760..dbff9d4 100644 --- a/FURPS/application/rln_membership_management.md +++ b/FURPS/application/rln_membership_management.md @@ -24,9 +24,11 @@ ## 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. Deployed on https://rln.waku.org +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. \ No newline at end of file +3. Proof generation and validation is out of scope for this FURPS. \ No newline at end of file diff --git a/FURPS/application/segmentation.md b/FURPS/application/segmentation.md new file mode 100644 index 0000000..c6ac752 --- /dev/null +++ b/FURPS/application/segmentation.md @@ -0,0 +1,32 @@ +# 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 new file mode 100644 index 0000000..22dcf8d --- /dev/null +++ b/FURPS/application/signal_network.md @@ -0,0 +1,24 @@ +# Signal Network PoC FURPS + +## Functionality + +1. Establishes a direct connection between two peers using Waku as a signaling layer + +## Usability + +1. Developers have access to a simple API: single entry `connect` function and event-based inbound handling. + +## 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. + +## + (Privacy, Anonymity, Deployments) + +1. Signaling payloads are end-to-end encrypted. +2. STUN and TURN servers may be required for WebRTC usage. \ No newline at end of file diff --git a/FURPS/application/status_go.md b/FURPS/application/status_go.md index 338885e..b4cc2d8 100644 --- a/FURPS/application/status_go.md +++ b/FURPS/application/status_go.md @@ -2,7 +2,8 @@ ## Functionality -1. Nwaku is the used Waku implementation for relay mode. +1. Nwaku is the used Waku implementation for relay mode. +2. Nwaku is the used Waku implementation for light mode. ## Usability @@ -20,8 +21,12 @@ ## Supportability 1. Status Desktop binary for Linux, Mac and Windows. -2. Relay mode is supported; no edge/light mode. +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. \ No newline at end of file +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 index 9d230af..77bd0d9 100644 --- a/FURPS/application/status_private_chats.md +++ b/FURPS/application/status_private_chats.md @@ -1,4 +1,4 @@ -# {Feature Name} FURPS +# Status Private Chats FURPS Waku specific FURPS, **before** integration of the Chat SDK. diff --git a/FURPS/core/mix.md b/FURPS/core/mix.md new file mode 100644 index 0000000..dcd1f7e --- /dev/null +++ b/FURPS/core/mix.md @@ -0,0 +1,21 @@ +# Mixnet FURPS + +## Functionality + +1. Relay nodes can mount mixnet protocol, acting as sender, intermediary or exit nodes. +2. Nodes can discover other nodes that support mix using available peer discovery mechanisms +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. + +## Usability + +## Reliability + +## Performance + +## Supportability + +1. `wakunode2` for intermediary and exit nodes. +2. nwaku CLI for sender nodes. + +## + (Privacy, Anonymity, Deployments) diff --git a/FURPS/core/rln_api.md b/FURPS/core/rln_api.md new file mode 100644 index 0000000..8b35d0c --- /dev/null +++ b/FURPS/core/rln_api.md @@ -0,0 +1,29 @@ +# Waku RLN API 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_relay.md b/FURPS/core/rln_relay.md index 43f9b63..73c95d1 100644 --- a/FURPS/core/rln_relay.md +++ b/FURPS/core/rln_relay.md @@ -3,10 +3,14 @@ ## 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. +1. Light push clients do not need RLN logic when using RLNaaS. ## Reliability @@ -23,6 +27,7 @@ ## 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) diff --git a/FURPS/core/rln_smart_contract.md b/FURPS/core/rln_smart_contract.md index e617eec..0ef8d3e 100644 --- a/FURPS/core/rln_smart_contract.md +++ b/FURPS/core/rln_smart_contract.md @@ -12,6 +12,7 @@ 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. ## Reliability @@ -28,6 +29,5 @@ ## + (Privacy, Anonymity, Deployments) -1. Smart Contracts are deployed on Linea Sepolia. -2. TWN uses smart contracts deployed on Linea Sepolia. - +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_sync.md b/FURPS/core/store_sync.md new file mode 100644 index 0000000..335b6cb --- /dev/null +++ b/FURPS/core/store_sync.md @@ -0,0 +1,23 @@ +# 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 new file mode 100644 index 0000000..bab1afc --- /dev/null +++ b/FURPS/core/waku_sdk.md @@ -0,0 +1,41 @@ +# Waku ADK 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/draft-roadmap/README.md b/draft-roadmap/README.md index 37d1909..7a76ccb 100644 --- a/draft-roadmap/README.md +++ b/draft-roadmap/README.md @@ -1,8 +1,62 @@ # 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 H1 +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. @@ -10,6 +64,10 @@ Period in planning: 2025 H1 - [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: @@ -18,14 +76,87 @@ Testing out new format, once approved: - Deliverables are moved to GitHub issues - Waku FURPS remains in [FURPS](/FURPS/README.md) -- [Foundation for Communities Optimization](foundation_for_communities_optimisation.md) -- [RLN Mainnet](deploy_rln_onchain_tree_on_l2_testnet.md) -- [Hardening and Scaling Foundations for Private Chats](hardening_and_scaling_foundation_for_private_chat.md) -- [Upgrade Waku for the Web](https://github.com/waku-org/pm/milestone/43) -- [Logos Web Apps](formalize_logos_web_apps.md) -- [Explore Peer Discovery Gap](https://github.com/waku-org/pm/milestone/44) -- [Nwaku in Status Desktop (Relay only)](integrate_nwaku_in_status_desktop_relay_mode_only.md) -- [Nwaku in Status Mobile and Light Mode MVP](https://roadmap.logos.co/waku/milestones/open/2025-nwaku-in-status-mobile)https://github.com/waku-org/pm/milestone/44 -- [e2e reliability protocol](introduce_e2e_reliability_in_status.md) -- [Debugging Tools](https://github.com/waku-org/pm/milestone/38) -- [Messaging API](https://github.com/waku-org/pm/milestone/41) \ No newline at end of file +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 | [Integrate RLN with Waku API](integrate_rln_with_waku_api.md) | 30 Sep | 1*1m | 1*2m | 2*2m | | | 1.7 | +| 7 | [Streamline DevEx: Mobile, Rust and Web dev](streamline_dev_ex_local_dev_rust.md) | 30 Nov | | 2*6w | 3*6w | | | 1.2 | +| 8 | [Extend Chat SDK with Group Conversations](extend_chat_sdk_with_group_conversations.md) | 19 Dec | | | | 2*3m | | 1.4 | +| 9 | [Incentivisation and Marketplace Follow-up Outline](incentivisation_follow_up.md) | TBD | 2.5*5m | | | | | 3 | +| 10 | [Nim Usage Improvements](nim_usage_improvements.md) | 19 Dec | | | 1*2m | | | 0.5 | +| 11 | [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 + +## 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 + 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 index dcef732..4388e45 100644 --- a/draft-roadmap/TEMPLATE.md +++ b/draft-roadmap/TEMPLATE.md @@ -7,16 +7,25 @@ - {external services consumed (Vac/IFT)} - {infrastructure} +{Milestone Narrative - what do we get once done} -{Milestone Description - what do we get once done} +## Strategic Objective -**FURPS**: +Logos xxx + +## FURPS - [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc} -**deliverables**: +## Risks -## {Name of deliverable 1 - eg "improve feature X for the browser"} +| 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} diff --git a/draft-roadmap/acquire_first_10_customers.md b/draft-roadmap/acquire_first_10_customers.md new file mode 100644 index 0000000..828da27 --- /dev/null +++ b/draft-roadmap/acquire_first_10_customers.md @@ -0,0 +1,46 @@ +# 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 new file mode 100644 index 0000000..e7c0e75 --- /dev/null +++ b/draft-roadmap/create_chat_sdk_mvp.md @@ -0,0 +1,163 @@ +# 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 + +**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 + +**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 + +**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 + +**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 index 22102dc..b0222f5 100644 --- a/draft-roadmap/define_incentivisation_for_rlnaas.md +++ b/draft-roadmap/define_incentivisation_for_rlnaas.md @@ -15,40 +15,15 @@ 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. -**FURPS**: TODO +## Strategic Objective -**deliverables**: https://github.com/waku-org/pm/milestone/35 TODO adjust deliverables with FURPS +Logos Vision: Core Values Alignment -## [Pay for RLN provision PoC](https://github.com/waku-org/pm/issues/245) +## FURPS +- [Incentivisation](/FURPS/core/incentivisation.md): F1-3, U1-2, R1-3, P1, for S1 -**Owner**: core research +## Risks -**Feature**: [Incentivisation](/FURPS/core/incentivisation.md) - -**FURPS**: -- F1. RLNaaS clients proceed to pay RLNaaS providers for attaching RLN proof to published messages. -- F2. RLNaaS clients can assess the quality of a provisioned RLNaaS and use it to build local reputation. -- F3. RLNaaS clients can use local reputation of RLNaaS providers to select what provider to use. -- U1. A consumer node can pay a service node for RLNaaS. -- U2. A consumer node can select an RLNaaS provider based on local reputation. -- R1. A consumer prefers new providers to known unreliable providers. -- R2. 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)**. -- R3. A client can assess whether an RLNaaS provider has relayed their message (**Vac-QA**) - in 90% of cases **(Vac-DST)**. -- P1. Assuming a block time of 5 seconds, - a user can execute an RLNaaS payment and send a message within 30 seconds (Vac-DST) - -For S1. A nwaku-based CLI on a testnet, interaction with a custodial wallet is out-of-scope. - -**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) - -## [Service incentivisation roadmap & spec](https://github.com/waku-org/pm/issues/246) - -**Owner**: core research - -**Output**: a roadmap document. \ No newline at end of file +| 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 new file mode 100644 index 0000000..8854c31 --- /dev/null +++ b/draft-roadmap/deploy_rln_onchain_tree_on_l2_testnet.md @@ -0,0 +1,90 @@ +# 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 new file mode 100644 index 0000000..cbea5d1 --- /dev/null +++ b/draft-roadmap/extend_chat_sdk_with_group_conversations.md @@ -0,0 +1,99 @@ +# 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 + +**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 + +**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 + +**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 new file mode 100644 index 0000000..e1febf7 --- /dev/null +++ b/draft-roadmap/formalize_and_expand_waku_web_apps.md @@ -0,0 +1,162 @@ +# 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 + +**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). + +**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 + +**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 + +**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) \ No newline at end of file diff --git a/draft-roadmap/formalize_logos_web_apps.md b/draft-roadmap/formalize_logos_web_apps.md deleted file mode 100644 index c501049..0000000 --- a/draft-roadmap/formalize_logos_web_apps.md +++ /dev/null @@ -1,19 +0,0 @@ -# Formalize Logos Web Apps - -**Estimated date of completion**: 19 Dec 2025 - -**Resources Required for 2025H2**: -- 1.5 engineers for 6 months - -Develop Web applications for Logos, using the Logos technology stack: - -- Qaku (Q&A over Waku): harden Waku to MVP level, so it can be used for IFT Town Halls, and Logos physical events -- Logos Operators Forum: Build a web forum PoC over Waku to serve as a basis for a decentralized Logos forum (opchan). - -As well as leveraging Qaku to explore Codex x Waku integration. - -**FURPS**: - -- [{Feature Name}]({path/to/furps/file}): {list of furps: F1, etc} TODO - -**Milestone and deliverables**: https://github.com/waku-org/pm/milestone/42 diff --git a/draft-roadmap/foundation_for_communities_optimisation.md b/draft-roadmap/foundation_for_communities_optimisation.md index 4f5e852..fcb02cd 100644 --- a/draft-roadmap/foundation_for_communities_optimisation.md +++ b/draft-roadmap/foundation_for_communities_optimisation.md @@ -1,9 +1,11 @@ # [Foundation for Communities Optimisation](https://github.com/waku-org/pm/milestone/31) -**Estimated date of completion**: 7-Apr-2025 - to be reviewed TODO +**Estimated date of completion**: 31 Oct 2025 (Final clean-up to be merged after a few Status app releases) **Resources Required for 2025H2**: -- App/Chat engineer: Pablo 100% for X months - TODO +- 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, diff --git a/draft-roadmap/hardening_and_scaling_foundation_for_private_chat.md b/draft-roadmap/hardening_and_scaling_foundation_for_private_chat.md index 0186fd1..cc80266 100644 --- a/draft-roadmap/hardening_and_scaling_foundation_for_private_chat.md +++ b/draft-roadmap/hardening_and_scaling_foundation_for_private_chat.md @@ -1,11 +1,11 @@ # [Hardening and Scaling Foundations for Private Chats](https://github.com/waku-org/pm/milestone/40) -**Estimated date of completion**: TODO +**Estimated date of completion**: Completed with reduced scope -**Resources Required for 2025H2**: TODO -- {roles and % application to it} -- {external services consumed (Vac/IFT)} -- {infrastructure} +**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 @@ -31,9 +31,11 @@ either removed or disabled by default to ensure accurate testing and evaluation. **Milestone and deliverables**: https://github.com/waku-org/pm/milestone/40 -TODO: [clean-up the deliverables](https://discord.com/channels/1110799176264056863/1337300409412489290/1379311090302980097): -- specify private chat: drop -- rate limit poc: finish it -- network metrics: move it -- baseline benchmarks: handover to DST -- status-cli: review with QA \ No newline at end of file +## 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 new file mode 100644 index 0000000..1110eb2 --- /dev/null +++ b/draft-roadmap/improve_devex_api_twn_metrics_docs.md @@ -0,0 +1,195 @@ +# 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 + +**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 + +**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 + +**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 + +**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 + +**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 new file mode 100644 index 0000000..579e4f7 --- /dev/null +++ b/draft-roadmap/incentivisation_follow_up.md @@ -0,0 +1,30 @@ +# 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 index 305c8c3..2ac1d95 100644 --- a/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md +++ b/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md @@ -1,9 +1,12 @@ -# Integrate nwaku in Status Desktop, relay mode only +# [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 +- 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. @@ -22,7 +25,26 @@ meaning that if Status were to use RLN (see Scale 1:1 chat messages PoC), then i **FURPS**: -- [nwaku](/FURPS/application/nwaku.md): F1-2, S1-2, +1 +- [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 new file mode 100644 index 0000000..6930a8a --- /dev/null +++ b/draft-roadmap/integrate_rln_with_waku_api.md @@ -0,0 +1,148 @@ +# 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 + +**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 + +**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 + +**Owner**: nwaku + +**Feature**: [Waku RLN API](/FURPS/core/rln_api.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 + +**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 Web3 RPC calls + +**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. + +**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 index 4950318..535ed51 100644 --- a/draft-roadmap/introduce_e2e_reliability_in_status.md +++ b/draft-roadmap/introduce_e2e_reliability_in_status.md @@ -4,6 +4,8 @@ **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) diff --git a/draft-roadmap/introduce_mixnet_for_message_sending.md b/draft-roadmap/introduce_mixnet_for_message_sending.md new file mode 100644 index 0000000..38125c0 --- /dev/null +++ b/draft-roadmap/introduce_mixnet_for_message_sending.md @@ -0,0 +1,46 @@ +# Introduce Mixnet For Message Sending + +**Estimated date of completion**: 30 Sep 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/nwaku/issues/3280) + +**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 discover other nodes that support mix using available peer discovery mechanisms +- 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/nim_usage_improvements.md b/draft-roadmap/nim_usage_improvements.md new file mode 100644 index 0000000..f864976 --- /dev/null +++ b/draft-roadmap/nim_usage_improvements.md @@ -0,0 +1,76 @@ +# Upgrade Nim Usage + +**Estimated date of completion**: 19 Dec + +**Resources Required for 2025H2**: +- 1 nwaku eng for 2 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) \ No newline at end of file diff --git a/draft-roadmap/streamline_dev_ex_local_dev_rust.md b/draft-roadmap/streamline_dev_ex_local_dev_rust.md new file mode 100644 index 0000000..8ad0d66 --- /dev/null +++ b/draft-roadmap/streamline_dev_ex_local_dev_rust.md @@ -0,0 +1,163 @@ +# 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 + +**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 + +**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 + +**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 + +**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 + +**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. Establishes a direct connection between two peers using Waku as a signaling layer + +- U1. Developers have access to a simple API: single entry `connect` function and event-based inbound handling. + +- 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. + +- +1. Signaling payloads are end-to-end encrypted. +- +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