diff --git a/content/acz/ift/2025q4-rln-status-l2.md b/content/acz/ift/2025q4-rln-status-l2.md index 1a6b07bfb..9fd8cc869 100644 --- a/content/acz/ift/2025q4-rln-status-l2.md +++ b/content/acz/ift/2025q4-rln-status-l2.md @@ -1,252 +1,252 @@ ---- -title: RLN Status L2 -tags: - - "2025q4" - - "acz" - - "ift" -draft: false -description: "Deploying and testing the prover module in testnet and devnet, -releasing the prover module with shared DB support, -as well as maintaining the code quality and performance" - ---- - -`vac:acz:ift:2025q4-rln-status-l2` - -## Description -This commitment entails testing the deployed RLN prover module for -the gasless feature of Status L2 architecture in testnet and devnet. -Specificaly, testing that all RLN components such as prover, -verifier, deny list and RPC node in monorepo. - -### Background -Status L2 is a rollup with Linea and builds a platform with the capacity to support -SocialFi and GameFi apps, governance experiments, the Status voting system, -and more, all while aiming to keep transaction costs low and throughput high. -Status L2 will incorporate a gasless feature, necessitating an effective anti-spam mechanism. -Rate-Limiting Nullifier (RLN) is a potential solution that could be deployed on Status L2 -to prevent spam and support the gasless functionality. - -In 2025q3, we released the RLN prover module with tracking module, tests, optimizations and benchmarks. - -### Narratives -By utilizing this commitment, we will reinforce the Conduit of Expertise narrative by: -* Continue sharing the RLN knowledge with the Status L2 team. -* Testing modified RLN design to make sure all components work seamlessly. - -We will also strengthen the Premier Research Destination narrative by: -* Offering an RLN use-case to the ecosystem that can be used for other gasless roll-up projects. - -## Task List - -### Finalizing the RLN deployment spec - -* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-spec-final` -* owner: Sylvain -* status: in progress (40%) -* start-date: 2025/10/22 -* end-date: 2025/11/03 - -#### Description -This task encompasses finalizing the RLN deployment spec with all its edge cases -and ready to the final implementation. - -#### Deliverables -* [A notion document](https://www.notion.so/RLN-Deployment-Specs-1f98f96fb65c806c8737d94851b4d14d) - -### Prover Module maintaining - -* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:maintaining` -* owner: Sylvain -* status: in progress (10%) -* start-date: 2025/10/01 -* end-date: 2025/02/30 - -#### Description -This task encompasses all maintenance updates for prover module, -including CI updates and the creation of future issues. - -#### Deliverables -* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). - -### Multi Tree Support - -* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:multi-tree` -* owner: Sylvain -* status: done -* start-date: 2025/10/01 -* end-date: 2025/10/15 - -### Description - -This task entails extending the Prover module to scale from supporting a single tree -with up to 1M users to a multi-tree architecture capable of handling -up to 32M users without compromising performance. -The current design, limited to a single tree, cannot efficiently manage larger user sets. -While an initial approach based on consistent hashing was considered, -it was ultimately discarded due to performance drawbacks. -The new approach introduces a dual-identifier database structure -using both tree_id and rln_identifier_id to efficiently -distribute and manage user commitments across multiple trees. -When one tree reaches its capacity, the system will automatically allocate -new users to the next available tree, ensuring seamless scalability and high performance. -This task is complete when the Prover module can reliably -handle up to 32M users across multiple trees with proper data management and performance validation. - -### Deliverables - -* A set of [PRs](https://github.com/vacp2p/status-rln-prover/pull/49) and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). - -### Gas checking support - -* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:gascheck` -* owner: Sylvain -* status: done -* start-date: 2025/10/15 -* end-date: 2025/10/20 - -### Description - -This task entails updating the Prover module to handle cases where -a single transaction exceeds the maximum quota and therefore requires burning multiple message IDs. -Currently, the module generates one RLN proof per transaction, -without accounting for transactions that surpass the allowed quota. - -The updated implementation must ensure that the gas information associated -with each incoming transaction is received alongside the transaction data. -Using both the max quota value and the transaction’s gas amount, -the module should calculate the exact number of message IDs to be burned -and deduct them from the user’s remaining tier limit accordingly. -This task is complete when the Prover module computes and applies -the required number of message ID burns based on transaction gas -and quota values, ensuring accurate user limit tracking. - -### Deliverables - -* A set of [PRs](https://github.com/vacp2p/status-rln-prover/pull/51) and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). - -### Monorepo Review - -* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:monorepo-review` -* owner: Sylvain -* status: done -* start-date: 2025/10/01 -* end-date: 2025/11/01 - -### Description - -This task entails getting familiar with and testing the -[monorepo](https://github.com/status-im/status-network-monorepo)in preparation for the prover integration. -In addition to basic exploration and setup, it includes a brief review of the implementation -of the sequencer, prover, and smart contracts, as well as a review of the deployment process -to identify and fix existing platform-specific bugs. -The task also involves testing newly added features to ensure -compatibility, stability, and readiness for prover integration. -This task is complete when the monorepo environment is fully reviewed, -deployment issues are resolved, and new features have been successfully tested and validated. - -### Deliverables - -* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). - -### Decentralized slashing - -* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:monorepo-review` -* owner: Sylvain -* status: done -* start-date: 2025/10/01 -* end-date: 2025/11/01 - -### Description - -This task entails updating the Prover module to listen for slashing events emitted by the `karma.sol` smart contract -and to handle the corresponding user data accordingly. -When a slashing occurs, the Prover must identify the affected user through the event data and remove -that user’s commitment from the local database to maintain consistency between on-chain and off-chain states. -This task is complete when the Prover module successfully detects slashing events from `karma.sol`, -correctly identifies the corresponding user, and reliably removes their commitment from the local database. - -### Deliverables - -* A set of [PRs](https://github.com/vacp2p/status-rln-prover/pull/52) and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). - -### Multi-prover with shared Database - -* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:shared-db` -* owner: Sylvain -* status: in progress (10%) -* start-date: 2025/11/03 -* end-date: 2025/11/30 - -### Description - -This task entails modifying the prover instance to release the multi-prover that each prover module -can write to the shared DB for having a prover cluster based on the pre-research in 2025q3. - -### Deliverables - -* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). - -### Devnet testing - -* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:devnet-testing` -* owner: Sylvain -* status: not started (5%) -* start-date: 2025/10/15 -* end-date: 2025/11/15 - -### Description - -This task focuses on testing the internal devnet. -The findings and feedback will be reflected in the RLN specification. - -### Deliverables - -* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover) - -### RLN public website - -* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-public-website` -* owner: Ugur -* status: in progress (60%) -* start-date: 2025/10/13 -* end-date: 2025/11/03 - -### Description - -This task entails preparing a comprehensive and publicly shareable Notion document -that consolidates the latest and most accurate notes on RLN (Rate Limiting Nullifier). -The document should explain in technical detail how RLN enables the gasless feature in the Gasless L2, -including the underlying cryptographic mechanisms that make gasless operations possible. -This task is complete when the Notion document accurately compiles the most recent RLN insights, -clearly articulates the technical reasoning behind the Gasless L2’s gasless functionality, -and is structured in a manner suitable for public presentation. - -### Deliverables - -* A doc on [Status Notion](https://www.notion.so/Status-Program-f6eef7b91ad94539babf66c26ea1cf02). - - -### SN RLN whitepaper - -* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:whitepaper` -* owner: Ugur -* status: not started -* start-date: 2025/11/03 -* end-date: 2025/12/03 - -### Description - -This task entails writing the Prover module section of the IEEE-format whitepaper, -providing a detailed and technically rigorous explanation of RLN as implemented in the system. -The section should build upon the existing RLN specification, -expanding it with clear descriptions of the Prover’s responsibilities, -data flow, and interactions with other components. -It should also illustrate the key mechanisms and cryptographic processes that enable -the Prover to function correctly within the RLN framework. -This task is complete when the whitepaper section presents a comprehensive, -technically accurate, and publication-ready explanation of the Prover module and its integration with RLN. - -### Deliverables - -* A doc on [Status Notion](https://www.notion.so/Status-Program-f6eef7b91ad94539babf66c26ea1cf02). +--- +title: RLN Status L2 +tags: + - "2025q4" + - "acz" + - "ift" +draft: false +description: "Deploying and testing the prover module in testnet and devnet, +releasing the prover module with shared DB support, +as well as maintaining the code quality and performance" + +--- + +`vac:acz:ift:2025q4-rln-status-l2` + +## Description +This commitment entails testing the deployed RLN prover module for +the gasless feature of Status L2 architecture in testnet and devnet. +Specificaly, testing that all RLN components such as prover, +verifier, deny list and RPC node in monorepo. + +### Background +Status L2 is a rollup with Linea and builds a platform with the capacity to support +SocialFi and GameFi apps, governance experiments, the Status voting system, +and more, all while aiming to keep transaction costs low and throughput high. +Status L2 will incorporate a gasless feature, necessitating an effective anti-spam mechanism. +Rate-Limiting Nullifier (RLN) is a potential solution that could be deployed on Status L2 +to prevent spam and support the gasless functionality. + +In 2025q3, we released the RLN prover module with tracking module, tests, optimizations and benchmarks. + +### Narratives +By utilizing this commitment, we will reinforce the Conduit of Expertise narrative by: +* Continue sharing the RLN knowledge with the Status L2 team. +* Testing modified RLN design to make sure all components work seamlessly. + +We will also strengthen the Premier Research Destination narrative by: +* Offering an RLN use-case to the ecosystem that can be used for other gasless roll-up projects. + +## Task List + +### Finalizing the RLN deployment spec + +* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-spec-final` +* owner: Sylvain +* status: in progress (40%) +* start-date: 2025/10/22 +* end-date: 2025/11/03 + +#### Description +This task encompasses finalizing the RLN deployment spec with all its edge cases +and ready to the final implementation. + +#### Deliverables +* [A notion document](https://www.notion.so/RLN-Deployment-Specs-1f98f96fb65c806c8737d94851b4d14d) + +### Prover Module maintaining + +* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:maintaining` +* owner: Sylvain +* status: in progress (10%) +* start-date: 2025/10/01 +* end-date: 2025/02/30 + +#### Description +This task encompasses all maintenance updates for prover module, +including CI updates and the creation of future issues. + +#### Deliverables +* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). + +### Multi Tree Support + +* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:multi-tree` +* owner: Sylvain +* status: done +* start-date: 2025/10/01 +* end-date: 2025/10/15 + +### Description + +This task entails extending the Prover module to scale from supporting a single tree +with up to 1M users to a multi-tree architecture capable of handling +up to 32M users without compromising performance. +The current design, limited to a single tree, cannot efficiently manage larger user sets. +While an initial approach based on consistent hashing was considered, +it was ultimately discarded due to performance drawbacks. +The new approach introduces a dual-identifier database structure +using both tree_id and rln_identifier_id to efficiently +distribute and manage user commitments across multiple trees. +When one tree reaches its capacity, the system will automatically allocate +new users to the next available tree, ensuring seamless scalability and high performance. +This task is complete when the Prover module can reliably +handle up to 32M users across multiple trees with proper data management and performance validation. + +### Deliverables + +* A set of [PRs](https://github.com/vacp2p/status-rln-prover/pull/49) and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). + +### Gas checking support + +* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:gascheck` +* owner: Sylvain +* status: done +* start-date: 2025/10/15 +* end-date: 2025/10/20 + +### Description + +This task entails updating the Prover module to handle cases where +a single transaction exceeds the maximum quota and therefore requires burning multiple message IDs. +Currently, the module generates one RLN proof per transaction, +without accounting for transactions that surpass the allowed quota. + +The updated implementation must ensure that the gas information associated +with each incoming transaction is received alongside the transaction data. +Using both the max quota value and the transaction’s gas amount, +the module should calculate the exact number of message IDs to be burned +and deduct them from the user’s remaining tier limit accordingly. +This task is complete when the Prover module computes and applies +the required number of message ID burns based on transaction gas +and quota values, ensuring accurate user limit tracking. + +### Deliverables + +* A set of [PRs](https://github.com/vacp2p/status-rln-prover/pull/51) and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). + +### Monorepo Review + +* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:monorepo-review` +* owner: Sylvain +* status: done +* start-date: 2025/10/01 +* end-date: 2025/11/01 + +### Description + +This task entails getting familiar with and testing the +[monorepo](https://github.com/status-im/status-network-monorepo)in preparation for the prover integration. +In addition to basic exploration and setup, it includes a brief review of the implementation +of the sequencer, prover, and smart contracts, as well as a review of the deployment process +to identify and fix existing platform-specific bugs. +The task also involves testing newly added features to ensure +compatibility, stability, and readiness for prover integration. +This task is complete when the monorepo environment is fully reviewed, +deployment issues are resolved, and new features have been successfully tested and validated. + +### Deliverables + +* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). + +### Decentralized slashing + +* fully qualified name: `vac:acz:ift:2025q3-rln-status-l2:monorepo-review` +* owner: Sylvain +* status: done +* start-date: 2025/10/01 +* end-date: 2025/11/01 + +### Description + +This task entails updating the Prover module to listen for slashing events emitted by the `karma.sol` smart contract +and to handle the corresponding user data accordingly. +When a slashing occurs, the Prover must identify the affected user through the event data and remove +that user’s commitment from the local database to maintain consistency between on-chain and off-chain states. +This task is complete when the Prover module successfully detects slashing events from `karma.sol`, +correctly identifies the corresponding user, and reliably removes their commitment from the local database. + +### Deliverables + +* A set of [PRs](https://github.com/vacp2p/status-rln-prover/pull/52) and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). + +### Multi-prover with shared Database + +* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:shared-db` +* owner: Sylvain +* status: in progress (10%) +* start-date: 2025/11/03 +* end-date: 2025/11/30 + +### Description + +This task entails modifying the prover instance to release the multi-prover that each prover module +can write to the shared DB for having a prover cluster based on the pre-research in 2025q3. + +### Deliverables + +* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover). + +### Devnet testing + +* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:devnet-testing` +* owner: Sylvain +* status: in progress (5%) +* start-date: 2025/10/15 +* end-date: 2025/11/15 + +### Description + +This task focuses on testing the internal devnet. +The findings and feedback will be reflected in the RLN specification. + +### Deliverables + +* A set of PRs and issues to [vacp2p/status-rln-prover](https://github.com/vacp2p/status-rln-prover) + +### RLN public website + +* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:rln-public-website` +* owner: Ugur +* status: in progress (60%) +* start-date: 2025/10/13 +* end-date: 2025/11/03 + +### Description + +This task entails preparing a comprehensive and publicly shareable Notion document +that consolidates the latest and most accurate notes on RLN (Rate Limiting Nullifier). +The document should explain in technical detail how RLN enables the gasless feature in the Gasless L2, +including the underlying cryptographic mechanisms that make gasless operations possible. +This task is complete when the Notion document accurately compiles the most recent RLN insights, +clearly articulates the technical reasoning behind the Gasless L2’s gasless functionality, +and is structured in a manner suitable for public presentation. + +### Deliverables + +* A doc on [Status Notion](https://www.notion.so/Status-Program-f6eef7b91ad94539babf66c26ea1cf02). + + +### SN RLN whitepaper + +* fully qualified name: `vac:acz:ift:2025q4-rln-status-l2:whitepaper` +* owner: Ugur +* status: not started +* start-date: 2025/11/03 +* end-date: 2025/12/03 + +### Description + +This task entails writing the Prover module section of the IEEE-format whitepaper, +providing a detailed and technically rigorous explanation of RLN as implemented in the system. +The section should build upon the existing RLN specification, +expanding it with clear descriptions of the Prover’s responsibilities, +data flow, and interactions with other components. +It should also illustrate the key mechanisms and cryptographic processes that enable +the Prover to function correctly within the RLN framework. +This task is complete when the whitepaper section presents a comprehensive, +technically accurate, and publication-ready explanation of the Prover module and its integration with RLN. + +### Deliverables + +* A doc on [Status Notion](https://www.notion.so/Status-Program-f6eef7b91ad94539babf66c26ea1cf02). diff --git a/content/acz/ift/2025q4-zerokit.md b/content/acz/ift/2025q4-zerokit.md index 33c6c0aee..a95856491 100644 --- a/content/acz/ift/2025q4-zerokit.md +++ b/content/acz/ift/2025q4-zerokit.md @@ -1,124 +1,124 @@ ---- -title: Zerokit -tags: - - "2025q4" - - "acz" - - "ift" -draft: false -description: "Maintaining and improving Zerokit, including the release of version v1.0.0, -which supports BE and improved FFI, lastly researching new ZK proof techniques" - ---- - -`vac:acz:ift:2025q4-zerokit` -## Description - -This commitment entails developing and maintaining Zerokit -including Zerokit v1 release by advancing the next version, such as -big-endian support, research on faster proving methods, -lastly improved FFI feature and new ZK proofs research. - -### Background - -[Zerokit](https://github.com/vacp2p/zerokit) is a collection of Zero Knowledge modules -that focus on RLN, developed in Rust, is intended for integration with various system programming environments. - -In 2025q3, we released Zerokit v0.9.0, which supports improved CI, optimized, partially BE support and research on FFI improvements. - -### Narratives - -By utilizing the zerokit commitment, we will reinforce the Conduit of Expertise narrative by: -* Delivers an optimized version for IFT projects utilizing Zerokit, -including [nwaku](https://github.com/waku-org/nwaku)and [js-rln](https://github.com/waku-org/js-rln) -and [Status L2](https://docs.status.network/). - -We will also strengthen the Premier Research Destination narrative by: -* Offers a Rust crate that serves as a more efficient open-source development tool for users looking to integrate RLN into their projects. -* Verifying the existing ZK framework by integrating zerokit. - -## Task List - -### Zerokit maintaining - -* fully qualified name: `vac:acz:ift:2025q4-zerokit:zerokit-maintaining` -* owner: Ekaterina -* status: in progress (%30) -* start-date: 2025/10/01 -* end-date: 2025/12/30 - -#### Description -This task encompasses all maintenance updates for Zerokit, including CI updates and the creation of future issues. - -#### Deliverables -A set of PRs and issues to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/). - -### Wasm FFI Rework - -* fully qualified name: `vac:acz:ift:2025q4-zerokit:wasm-ffi-rework` -* owner: Vinh -* status: not started -* start-date: 2025/11/03 -* end-date: 2025/11/10 - -#### Description -This task aims to rework the current rln-wasm module to replace its serialization/deserialization-based -FFI interface with opaque Rust structures exposed directly to JavaScript via wasm-bindgen. -Instead of converting data to and from serialized formats when crossing the Rust–JS boundary, -we will define types like `WasmFr` (a wrapper around `ark_bn254::Fr`) and `WasmRLNProofValues` that can be used natively in JavaScript. -For discussion and context, see: [Zerokit Discussion](https://github.com/vacp2p/zerokit/discussions/336) - -#### Deliverables -* A PR to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/) that covers: - * Refactor: Replace serialization-based argument passing with opaque structs (WasmFr, WasmRLNProofValues, etc.). - - * Bindings Update: Regenerate JS/TS bindings and verify correct usage in Node.js test and Browser headless test. - - * Documentation & Examples: Add usage examples, note wasm-bindgen constructor support, and document known limitations (e.g., tuple returns not supported) - -### FFI re-work - -* fully qualified name: `vac:acz:ift:2025q4-zerokit:ffi-rework` -* owner: Vinh -* status: in progress (80%) -* start-date: 2025/10/01 -* end-date: 2025/11/01 - -#### Description -The due date of this task is expanded to 11/01 due to the bugs and test requirements. - -This task entails reworking Zerokit’s FFI (Foreign Function Interface) to support passing data in Big Endian format, -and to transition from a manual byte-based serialization approach to a safer and more maintainable opaque-struct model. -Currently, FFI functions require developers to manually allocate buffers, serialize arguments, -and handle deserialization within Rust, which introduces overhead, performance loss, fragile data handling -and complex documentation requirements. -Additionally, maintaining separate implementations for different endianness formats -and managing numerous byte-to-struct conversions adds unnecessary complexity. - -The proposed solution is to adopt an opaque struct pattern managed by Rust, -allowing C code to manipulate only pointers through a defined API, leveraging the safer_ffi crate -to automatically generate C headers, ensure memory safety, and remove unsafe code, -as in planned in [this zerokit/discussion](https://github.com/vacp2p/zerokit/discussions/336). - -This change aims to simplify the FFI layer, improve performance, reduce maintenance effort, -and make the system more resilient to data format changes while easing integration with languages like C and Nim. - -This task is complete when a proof of concept demonstrating RLN proof generation -and verification through the new FFI model is implemented and validated -for memory safety and Big Endian compatibility. - -#### Deliverables -A set of PRs and issues to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/). - -### Release v1 - -* fully qualified name: `vac:acz:ift:2025q4-zerokit:release` -* owner: Ekaterina -* status: not started -* start-date: 2025/12/15 -* end-date: 2025/12/30 - -#### Description -The new version of the Zerokit v1.0.0. - -#### Deliverables +--- +title: Zerokit +tags: + - "2025q4" + - "acz" + - "ift" +draft: false +description: "Maintaining and improving Zerokit, including the release of version v1.0.0, +which supports BE and improved FFI, lastly researching new ZK proof techniques" + +--- + +`vac:acz:ift:2025q4-zerokit` +## Description + +This commitment entails developing and maintaining Zerokit +including Zerokit v1 release by advancing the next version, such as +big-endian support, research on faster proving methods, +lastly improved FFI feature and new ZK proofs research. + +### Background + +[Zerokit](https://github.com/vacp2p/zerokit) is a collection of Zero Knowledge modules +that focus on RLN, developed in Rust, is intended for integration with various system programming environments. + +In 2025q3, we released Zerokit v0.9.0, which supports improved CI, optimized, partially BE support and research on FFI improvements. + +### Narratives + +By utilizing the zerokit commitment, we will reinforce the Conduit of Expertise narrative by: +* Delivers an optimized version for IFT projects utilizing Zerokit, +including [nwaku](https://github.com/waku-org/nwaku)and [js-rln](https://github.com/waku-org/js-rln) +and [Status L2](https://docs.status.network/). + +We will also strengthen the Premier Research Destination narrative by: +* Offers a Rust crate that serves as a more efficient open-source development tool for users looking to integrate RLN into their projects. +* Verifying the existing ZK framework by integrating zerokit. + +## Task List + +### Zerokit maintaining + +* fully qualified name: `vac:acz:ift:2025q4-zerokit:zerokit-maintaining` +* owner: Ekaterina +* status: in progress (30%) +* start-date: 2025/10/01 +* end-date: 2025/12/30 + +#### Description +This task encompasses all maintenance updates for Zerokit, including CI updates and the creation of future issues. + +#### Deliverables +A set of PRs and issues to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/). + +### Wasm FFI Rework + +* fully qualified name: `vac:acz:ift:2025q4-zerokit:wasm-ffi-rework` +* owner: Vinh +* status: not started +* start-date: 2025/11/03 +* end-date: 2025/11/10 + +#### Description +This task aims to rework the current rln-wasm module to replace its serialization/deserialization-based +FFI interface with opaque Rust structures exposed directly to JavaScript via wasm-bindgen. +Instead of converting data to and from serialized formats when crossing the Rust–JS boundary, +we will define types like `WasmFr` (a wrapper around `ark_bn254::Fr`) and `WasmRLNProofValues` that can be used natively in JavaScript. +For discussion and context, see: [Zerokit Discussion](https://github.com/vacp2p/zerokit/discussions/336) + +#### Deliverables +* A PR to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/) that covers: + * Refactor: Replace serialization-based argument passing with opaque structs (WasmFr, WasmRLNProofValues, etc.). + + * Bindings Update: Regenerate JS/TS bindings and verify correct usage in Node.js test and Browser headless test. + + * Documentation & Examples: Add usage examples, note wasm-bindgen constructor support, and document known limitations (e.g., tuple returns not supported) + +### FFI re-work + +* fully qualified name: `vac:acz:ift:2025q4-zerokit:ffi-rework` +* owner: Vinh +* status: in progress (80%) +* start-date: 2025/10/01 +* end-date: 2025/11/01 + +#### Description +The due date of this task is expanded to 11/01 due to the bugs and test requirements. + +This task entails reworking Zerokit’s FFI (Foreign Function Interface) to support passing data in Big Endian format, +and to transition from a manual byte-based serialization approach to a safer and more maintainable opaque-struct model. +Currently, FFI functions require developers to manually allocate buffers, serialize arguments, +and handle deserialization within Rust, which introduces overhead, performance loss, fragile data handling +and complex documentation requirements. +Additionally, maintaining separate implementations for different endianness formats +and managing numerous byte-to-struct conversions adds unnecessary complexity. + +The proposed solution is to adopt an opaque struct pattern managed by Rust, +allowing C code to manipulate only pointers through a defined API, leveraging the safer_ffi crate +to automatically generate C headers, ensure memory safety, and remove unsafe code, +as in planned in [this zerokit/discussion](https://github.com/vacp2p/zerokit/discussions/336). + +This change aims to simplify the FFI layer, improve performance, reduce maintenance effort, +and make the system more resilient to data format changes while easing integration with languages like C and Nim. + +This task is complete when a proof of concept demonstrating RLN proof generation +and verification through the new FFI model is implemented and validated +for memory safety and Big Endian compatibility. + +#### Deliverables +A set of PRs and issues to [vacp2p/zerokit](https://github.com/vacp2p/zerokit/). + +### Release v1 + +* fully qualified name: `vac:acz:ift:2025q4-zerokit:release` +* owner: Ekaterina +* status: not started +* start-date: 2025/12/15 +* end-date: 2025/12/30 + +#### Description +The new version of the Zerokit v1.0.0. + +#### Deliverables A set of PRs to vacp2p/zerokit repository with [tag v1.0.0](https://github.com/vacp2p/zerokit/releases/tag/v1.0.0) \ No newline at end of file diff --git a/content/dst/ift/2025q4-dst-tooling.md b/content/dst/ift/2025q4-dst-tooling.md index 47a421e11..c08433cfc 100644 --- a/content/dst/ift/2025q4-dst-tooling.md +++ b/content/dst/ift/2025q4-dst-tooling.md @@ -145,7 +145,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. * fully qualified name: `vac:dst:ift:2025q4-dst-tooling:complete-deployment-refactor` * owner: Pearson -* status: 70% +* status: in progress (70%) * start-date: 2025/10/06 * end-date: 2025/10/24 diff --git a/content/dst/status/2025q4-status-evaluation.md b/content/dst/status/2025q4-status-evaluation.md index d99d107ac..cf6bf4baf 100644 --- a/content/dst/status/2025q4-status-evaluation.md +++ b/content/dst/status/2025q4-status-evaluation.md @@ -102,7 +102,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. * fully qualified name: `vac:dst:status:2025q4-status-evaluation:chat-protocol-benchmarks-followup` * owner: Alberto -* status: 70% +* status: in progress (70%) * start-date: 2025/10/06 * end-date: 2025/10/24 diff --git a/content/dst/vac/2025q4-libp2p-evaluation.md b/content/dst/vac/2025q4-libp2p-evaluation.md index e190a5f46..fabd0bdc1 100644 --- a/content/dst/vac/2025q4-libp2p-evaluation.md +++ b/content/dst/vac/2025q4-libp2p-evaluation.md @@ -137,7 +137,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. * fully qualified name: `vac:dst:vac:2025q4-libp2p-evaluation:mix-in-nim-libp2p-node` * owner: Farooq -* status: 100% +* status: done * start-date: 2025/10/06 * end-date: 2025/10/17 @@ -154,7 +154,7 @@ include mix to the configuration options of the node. * fully qualified name: `vac:dst:vac:2025q4-libp2p-evaluation:go-libp2p-node` * owner: Farooq -* status: 100% +* status: done * start-date: 2025/10/06 * end-date: 2025/10/24 @@ -173,7 +173,7 @@ Report results of a single scenario (fixed parameters) using K8s and shadow. * fully qualified name: `vac:dst:vac:2025q4-libp2p-evaluation:rust-libp2p-node` * owner: Farooq -* status: 0% +* status: not started * start-date: 2025/10/27 * end-date: 2025/11/07 diff --git a/content/dst/waku/2025q4-waku-scaling.md b/content/dst/waku/2025q4-waku-scaling.md index bd00c6d8a..3018f8f1f 100644 --- a/content/dst/waku/2025q4-waku-scaling.md +++ b/content/dst/waku/2025q4-waku-scaling.md @@ -70,7 +70,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. * fully qualified name: `vac:dst:waku:2025q4-waku-scaling:optimise-browser-bootstrapping` * owner: Pearson -* status: 10% +* status: in progress (10%) * start-date: 2025/10/15 * end-date: 2025/10/31 @@ -181,7 +181,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. * fully qualified name: `vac:dst:waku:2025q4-waku-scaling:TWN-supports-RLN-tree` * owner: Alberto -* status: 70% +* status: in progress (70%) * start-date: 2025/10/06 * end-date: 2025/10/24 diff --git a/content/nim/ift/2025q4-nimble.md b/content/nim/ift/2025q4-nimble.md index 671d858d1..2b3e0f9be 100644 --- a/content/nim/ift/2025q4-nimble.md +++ b/content/nim/ift/2025q4-nimble.md @@ -25,7 +25,7 @@ We'll prioritize these enhancements to bring Nimble closer to its 1.0 release, e By the end of this quarter, we aim to have made significant progress on these fronts, setting the stage for Nimble to become the go-to package manager in IFT projects. -## Tasks +## Task List ### Nimble 1.0.0 diff --git a/content/p2p/ift/2025q4-nimlibp2p-kad-dht.md b/content/p2p/ift/2025q4-nimlibp2p-kad-dht.md index 50addeeb5..3366beba8 100644 --- a/content/p2p/ift/2025q4-nimlibp2p-kad-dht.md +++ b/content/p2p/ift/2025q4-nimlibp2p-kad-dht.md @@ -24,7 +24,7 @@ This deliverable continues the work started in 2025q2 * fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-kad-dht:routing-and-rpc` * owner: gabe/rramos -* status: in progress(75%) +* status: in progress (75%) * start-date: 2025/10/01 * end-date: 2025/12/31 @@ -59,7 +59,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. * fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-kad-dht:network-maintenance-node-management` * owner: gabe -* status: in progress(50%) +* status: in progress (50%) * start-date: 2025/10/01 * end-date: 2025/12/31 @@ -76,7 +76,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. * fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-kad-dht:data-storage` * owner: gabe -* status: in progress(90%) +* status: in progress (90%) * start-date: 2025/10/01 * end-date: 2025/12/31 @@ -96,7 +96,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. * fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-kad-dht:data-retrieval` * owner: gabe -* status: in progress(60%) +* status: in progress (60%) * start-date: 2025/10/01 * end-date: 2025/12/31 @@ -113,7 +113,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. ### Discovery * fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-kad-dht:discovery` * owner: gabe -* status: in progress(15%) +* status: in progress (15%) * start-date: 2025/10/01 * end-date: 2025/12/31 @@ -135,4 +135,4 @@ PRs Ensure interop is achieved between nim-libp2p's kad-dht implementation and other libp2p implementations #### Deliverables -PRs \ No newline at end of file +PRs diff --git a/content/p2p/ift/2025q4-nimlibp2p-mix.md b/content/p2p/ift/2025q4-nimlibp2p-mix.md index d80d0394d..699b5c815 100644 --- a/content/p2p/ift/2025q4-nimlibp2p-mix.md +++ b/content/p2p/ift/2025q4-nimlibp2p-mix.md @@ -44,7 +44,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. * fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-mix:stream-reuse` * owner: rramos -* status: completed +* status: done * start-date: 2025/10/13 * end-date: 2025/10/22 diff --git a/content/p2p/ift/2025q4-nimlibp2p-quic.md b/content/p2p/ift/2025q4-nimlibp2p-quic.md index c8a268c52..a98ef6f82 100644 --- a/content/p2p/ift/2025q4-nimlibp2p-quic.md +++ b/content/p2p/ift/2025q4-nimlibp2p-quic.md @@ -24,7 +24,7 @@ In Q3 we discovered critical deficiencies in nim-quic, including runtime instabi * fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-quic:stabilization` * owner: vlado/rramos -* status: started +* status: in progress (10%) * start-date: 2025/10/01 * end-date: 2025/12/31 @@ -40,7 +40,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. * fully qualified name: `vac:p2p:ift:2025q4-nimlibp2p-quic:openssl-replacement` * owner: rramos -* status: completed +* status: done * start-date: 2025/10/01 * end-date: 2025/10/15 diff --git a/content/qa/status/2025q4-status-qa-desktop.md b/content/qa/status/2025q4-status-qa-desktop.md index 1708f4fde..079aeff5f 100644 --- a/content/qa/status/2025q4-status-qa-desktop.md +++ b/content/qa/status/2025q4-status-qa-desktop.md @@ -156,7 +156,7 @@ Schedule note: Dates reflect quarter bounds; update when actual timing is known. * fully qualified name: `vac:qa:status:2025q4-status-qa-desktop:local-backup` * owner: nastya -* status: in progress(75%) +* status: in progress (75%) * start-date: 2025/10/07 * end-date: 2025/10/20 diff --git a/content/qa/vac/2025q4-nim-libp2p-testing.md b/content/qa/vac/2025q4-nim-libp2p-testing.md index 13c364e5e..88f06f1d8 100644 --- a/content/qa/vac/2025q4-nim-libp2p-testing.md +++ b/content/qa/vac/2025q4-nim-libp2p-testing.md @@ -32,7 +32,7 @@ Improve stability by addressing flaky tests and extend coverage for Identify/Pus * fully qualified name: `vac:qa:vac:2025q4-nim-libp2p-testing:test-plans` * owner: radek -* status: in progress(20%) +* status: in progress (20%) * start-date: 2025/10/01 * end-date: 2025/10/20 @@ -121,7 +121,7 @@ Update GossipSub performance tests based on dev feedback and existing data gathe * fully qualified name: `vac:qa:vac:2025q4-nim-libp2p-testing:quic` * owner: radek -* status: nin progress (5%) +* status: in progress (5%) * start-date: 2025/10/16 * end-date: 2025/11/25 diff --git a/content/qa/waku/2025q4-waku-testing.md b/content/qa/waku/2025q4-waku-testing.md index e392a55e9..a88bdbb76 100644 --- a/content/qa/waku/2025q4-waku-testing.md +++ b/content/qa/waku/2025q4-waku-testing.md @@ -95,7 +95,7 @@ Extend Waku end-to-end tests with network condition scenarios (high latency, low * fully qualified name: `vac:qa:waku:2025q4-waku-testing:maintenance` * owner: fbarbu15 -* status: in progress(20%) +* status: in progress (20%) * start-date: 2025/10/01 * end-date: 2025/12/30 diff --git a/content/rfc/codex/2025q4-rfc-iteration.md b/content/rfc/codex/2025q4-rfc-iteration.md index 57d879c16..6f37b014d 100644 --- a/content/rfc/codex/2025q4-rfc-iteration.md +++ b/content/rfc/codex/2025q4-rfc-iteration.md @@ -1,6 +1,7 @@ --- title: RFC Iteration tags: + - 2025q4 - rfc - codex draft: false @@ -41,7 +42,6 @@ editorial work through previous and future RFCs to improve them (identify edge cases for example) - **Alignment with VAC Narratives:** - The VAC RFC team plans to become a repository @@ -57,93 +57,57 @@ in their projects, similar to [IETF](https://www.ietf.org/). ### Slot Builder -- Fully qualified name: - `vac:rfc:codex:2025q4-rfc-iteration:slot-builder' -- Owner: jimstir -- Status: 10% -- Start date: 2025/10/01 -- End date: 2025/10/15 +- fully qualified name: `vac:rfc:codex:2025q4-rfc-iteration:slot-builder' +- owner: jimstir +- status: in progress (10%) +- start-date: 2025/10/01 +- end-date: 2025/10/15 + +#### Description +Create the RFC for slot builder, updating design decisions and open questions. + + +#### Deliverables +- PRs/Issues/Docs/Reports + ### Erasure Coding Module -- Fully qualified name: - `vac:rfc:codex:2025q4-rfc-iteration:erasure-coding-module` -- Owner: cofson -- Status: not started -- Start date: 2025/10/15 -- End date: 2025/10/30 +- fully qualified name: `vac:rfc:codex:2025q4-rfc-iteration:erasure-coding-module` +- owner: cofson +- status: not started +- start-date: 2025/10/15 +- end-date: 2025/10/30 + +#### Description +Create the RFC for the erasure coding module that documents data availability behaviour. + +#### Deliverables +- PRs/Issues/Docs/Reports ### Purchase Module -- Fully qualified name: - `vac:rfc:codex:2025q4-rfc-iteration:purchase-module` -- Owner: cofson -- Status: not started -- Start date: 2025/10/04 -- End date: 2025/10/19 +- fully qualified name: `vac:rfc:codex:2025q4-rfc-iteration:purchase-module` +- owner: cofson +- status: not started +- start-date: 2025/10/04 +- end-date: 2025/10/19 + +#### Description +Create the RFC for the purchase module covering pricing, incentives, and settlement flows. + +#### Deliverables +- PRs/Issues/Docs/Reports ### The Block Exchange -- Fully qualified name: - `vac:rfc:codex:2025q4-rfc-iteration:the-block-exchange' -- Owner: cofson -- Status: not started -- Start date: 2025/10/04 -- End date: 2025/10/31 +- fully qualified name: `vac:rfc:codex:2025q4-rfc-iteration:the-block-exchange' +- owner: cofson +- status: not started +- start-date: 2025/10/04 +- end-date: 2025/10/31 - \ No newline at end of file +#### Deliverables +- PRs/Issues/Docs/Reports \ No newline at end of file diff --git a/content/rfc/ift/2025q4-rfc-culture-establishment.md b/content/rfc/ift/2025q4-rfc-culture-establishment.md index df4e17172..204ab439b 100644 --- a/content/rfc/ift/2025q4-rfc-culture-establishment.md +++ b/content/rfc/ift/2025q4-rfc-culture-establishment.md @@ -1,9 +1,9 @@ --- title: RFC Culture Establishment tags: + - 2025q4 - rfc - ift - - vac draft: false description: Continuation of RFC Culture establishment through introducing new initiatives. --- @@ -41,11 +41,11 @@ similar to [IETF](https://www.ietf.org/). ### Team Communication -- Fully qualified name: `vac:rfc:ift:2025q4-culture-establishment-team-communication` -- Owner: cofson -- Status: not started -- Start date: 2025/10/01 -- End date: 2025/12/31 +- fully qualified name: `vac:rfc:ift:2025q4-rfc-culture-establishment:team-communication` +- owner: cofson +- status: not started +- start-date: 2025/10/01 +- end-date: 2025/12/31 #### Description diff --git a/content/rfc/ift/2025q4-rfc-index-maintenance.md b/content/rfc/ift/2025q4-rfc-index-maintenance.md index 369473c84..ed7d01b8a 100644 --- a/content/rfc/ift/2025q4-rfc-index-maintenance.md +++ b/content/rfc/ift/2025q4-rfc-index-maintenance.md @@ -1,8 +1,9 @@ --- title: rfc-index-maintenance tags: + - 2025q4 - rfc - - vac + - ift draft: false description: This commitment revolves around a continuous effort to fix and update across the relevant RFC websites (including the communication). --- diff --git a/content/rfc/index.md b/content/rfc/index.md index df0d0e826..d97350104 100644 --- a/content/rfc/index.md +++ b/content/rfc/index.md @@ -5,6 +5,26 @@ tags: - vac --- +## 2025q4 `vac:rfc:` + + +### `ift:` +* [[rfc/ift/2025q4-rfc-culture-establishment|rfc-culture-establishment]] +* [[rfc/ift/2025q4-rfc-index-maintenance|rfc-index-maintenance]] + +### `waku:` +* [[rfc/waku/2025q4-rfc-iteration|rfc-iteration]] + +### `nomos:` +* [[rfc/nomos/2025q4-rfc-iteration|rfc-iteration]] + +### `codex:` +* [[rfc/codex/2025q4-rfc-iteration|rfc-iteration]] + +### `status:` +* [[rfc/status/2025q4-rfc-iteration|rfc-iteration]] + + ## 2025q3 `vac:rfc:` diff --git a/content/rfc/nescience/2025q4-rfc-iteration.md b/content/rfc/nescience/2025q4-rfc-iteration.md deleted file mode 100644 index 8aac55482..000000000 --- a/content/rfc/nescience/2025q4-rfc-iteration.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: RFC Iteration -tags: - - rfc - - nomos -draft: false -description: "Iteration commitments generally comprise: through discussion and curation, support the process of auditing raw, draft, mature selected RFCs." ---- - -`vac:rfc:nescience:2025q4-rfc-iteration` - -Iteration commitments generally comprise: -through discussion and curation, -support the process of auditing raw, draft, mature selected RFCs. - -## Description - -This commitment covers the writing of the following mature RFCs -according to COSS, based on the Notion documentation: -- TBD - -We will also include specification validation - -to make sure there are no errors, missing information, inconsistencies -and that the specification is up to standards. - - - -**Alignment with VAC Narratives:** - -- The VAC RFC team plans to become a repository -for RFCs regarding all IFT projects. -- By promoting the RFC culture, -we hope to incentivize projects to submit their RFCs -to the rfc-editors team. -- We aim to have the broader web3 community use our RFCs -in their projects, similar to [IETF](https://www.ietf.org/). - -## Task List - -TBD - - diff --git a/content/rfc/nomos/2025q4-rfc-iteration.md b/content/rfc/nomos/2025q4-rfc-iteration.md index 1b59d5ba8..ccae08ba9 100644 --- a/content/rfc/nomos/2025q4-rfc-iteration.md +++ b/content/rfc/nomos/2025q4-rfc-iteration.md @@ -1,6 +1,7 @@ --- title: RFC Iteration tags: + - 2025q4 - rfc - nomos draft: false @@ -46,45 +47,70 @@ in their projects, similar to [IETF](https://www.ietf.org/). ### Cryptarchia v1 Protocol Specification -- Fully qualified name: - `vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-v1-protocol-specification` -- Owner: cofson -- Status: not started -- Start date: 2025/11/01 -- End date: 2025/11/15 +- fully qualified name: `vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-v1-protocol-specification` +- owner: cofson +- status: not started +- start-date: 2025/11/01 +- end-date: 2025/11/15 + +#### Description +Create the RFC for the Cryptarchia v1 protocol covering validators, messages, and consensus flow. + +#### Deliverables +- PRs/Issues/Docs/Reports ### Cryptarchia v1 Bootstrapping & Synchronization -- Fully qualified name: - `vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-v1-bootstrapping-and-synchronization` -- Owner: cofson -- Status: not started -- Start date: 2025/11/01 -- End date: 2025/11/15 +- fully qualified name: `vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-v1-bootstrapping-and-synchronization` +- owner: cofson +- status: not started +- start-date: 2025/11/01 +- end-date: 2025/11/15 + +#### Description +Create the RFC for Cryptarchia bootstrapping and synchronization procedures. + +#### Deliverables +- PRs/Issues/Docs/Reports ### Cryptarchia Fork Choice Rule -- Fully qualified name: - `vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-fork-choice-rule` -- Owner: cofson -- Status: not started -- Start date: 2025/12/01 -- End date: 2025/12/15 +- fully qualified name: `vac:rfc:nomos:2025q4-rfc-iteration:cryptarchia-fork-choice-rule` +- owner: cofson +- status: not started +- start-date: 2025/12/01 +- end-date: 2025/12/15 + +#### Description +Create the RFC for the Cryptarchia fork choice rule logic and safety guarantees. + +#### Deliverables +- PRs/Issues/Docs/Reports ### Total Stake Inference -- Fully qualified name: - `vac:rfc:nomos:2025q4-rfc-iteration:total-stake-inference` -- Owner: cofson -- Status: not started -- Start date: 2025/12/01 -- End date: 2025/12/15 +- fully qualified name: `vac:rfc:nomos:2025q4-rfc-iteration:total-stake-inference` +- owner: cofson +- status: not started +- start-date: 2025/12/01 +- end-date: 2025/12/15 + +#### Description +Create the RFC for total stake inference and state tracking within Cryptarchia. + +#### Deliverables +- PRs/Issues/Docs/Reports ### Proof of Leadership Specification -- Fully qualified name: - `vac:rfc:nomos:2025q4-rfc-iteration:proof-of-leadership-specification` -- Owner: cofson -- Status: not started -- Start date: 2025/12/20 -- End date: 2025/12/31 \ No newline at end of file +- fully qualified name: `vac:rfc:nomos:2025q4-rfc-iteration:proof-of-leadership-specification` +- owner: cofson +- status: not started +- start-date: 2025/12/20 +- end-date: 2025/12/31 + +#### Description +Create the RFC for the proof of leadership mechanism, including leader election and validation criteria. + +#### Deliverables +- PRs/Issues/Docs/Reports \ No newline at end of file diff --git a/content/rfc/status/2025q4-rfc-iteration.md b/content/rfc/status/2025q4-rfc-iteration.md index d04e2e671..3b9f22e86 100644 --- a/content/rfc/status/2025q4-rfc-iteration.md +++ b/content/rfc/status/2025q4-rfc-iteration.md @@ -1,7 +1,9 @@ --- title: RFC Iteration tags: + - 2025q4 - rfc + - status draft: false description: "Iteration commitments generally comprise: through discussion and curation, support the process of auditing raw, draft, mature selected Status RFCs." --- @@ -42,9 +44,14 @@ in their projects, similar to [IETF](https://www.ietf.org/). ### Chat Specifications Support -- Fully qualified name: - `vac:rfc:status:2025q4-rfc-iteration:chat-specifications-support` -- Owner: Filip -- Status: not started -- Start date: 2025/11/01 -- End date: 2025/12/31 +- fully qualified name: `vac:rfc:status:2025q4-rfc-iteration:chat-specifications-support` +- owner: Filip +- status: not started +- start date: 2025/11/01 +- end date: 2025/12/31 + +#### Description +Create the RFC for Status chat specifications updates so docs match current client behaviour. + +#### Deliverables +- PRs/Issues/Docs/Reports diff --git a/content/rfc/waku/2025q4-rfc-iteration.md b/content/rfc/waku/2025q4-rfc-iteration.md index d41a584ad..de8cf51d2 100644 --- a/content/rfc/waku/2025q4-rfc-iteration.md +++ b/content/rfc/waku/2025q4-rfc-iteration.md @@ -1,6 +1,7 @@ --- title: RFC Iteration tags: + - 2025q4 - rfc - waku draft: false @@ -50,9 +51,14 @@ from the point of view of a new developer. ### Opchan -- Fully qualified name: - `vac:rfc:waku:2025q4-rfc-iteration:opchan` -- Owner: jimstir -- Status: 30% (paused) -- Start date: 2025/11/01 -- End date: 2025/11/30 \ No newline at end of file +- fully qualified name: `vac:rfc:waku:2025q4-rfc-iteration:opchan` +- owner: jimstir +- status: in progress (30%) +- start-date: 2025/11/01 +- end-date: 2025/11/30 + +#### Description +Create the RFC for Opchan reflecting the latest Waku channel architecture and open questions. + +#### Deliverables +- PRs/Issues/Docs/Reports \ No newline at end of file diff --git a/tools/roadmap_validator/constants.py b/tools/roadmap_validator/constants.py index 8af9c0cc9..26d54b139 100644 --- a/tools/roadmap_validator/constants.py +++ b/tools/roadmap_validator/constants.py @@ -25,6 +25,13 @@ TASK_HEADING_RE = re.compile(TASK_HEADING_PATTERN) META_LINE_PATTERN = r"^[\-\*]\s*([^:]+):\s*(.*)$" META_LINE_RE = re.compile(META_LINE_PATTERN) +STATUS_ALLOWED = { + "not started", + "done", + "blocked", +} +STATUS_IN_PROGRESS_RE = re.compile(r"^in progress\s*\((\d{1,2})%\)$") + VAGUE_KEYWORDS = ( "investigate", "research", diff --git a/tools/roadmap_validator/tasks.py b/tools/roadmap_validator/tasks.py index 3582429e5..f00e7fb24 100644 --- a/tools/roadmap_validator/tasks.py +++ b/tools/roadmap_validator/tasks.py @@ -7,6 +7,8 @@ from constants import ( META_LINE_RE, METADATA_ALIAS_MAP, REQUIRED_TASK_FIELDS, + STATUS_ALLOWED, + STATUS_IN_PROGRESS_RE, TANGIBLE_KEYWORDS, TASK_HEADING_RE, TODO_RE, @@ -56,6 +58,23 @@ class TaskReport: self.add_issue( f"`{field_name}` should use YYYY/MM/DD format (found `{value}`)", line ) + elif field_name == "status": + normalized = value.strip().lower() + match = STATUS_IN_PROGRESS_RE.match(normalized) + if normalized not in STATUS_ALLOWED: + if match: + progress = int(match.group(1)) + if progress >= 100: + self.add_issue( + "`status` percentage must be between 0% and 99% for `in progress`", + line, + ) + else: + allowed_text = ", ".join(sorted(STATUS_ALLOWED)) + ", or `in progress (NN%)`" + self.add_issue( + f"`status` should be {allowed_text} (found `{value.strip()}`)", + line, + ) if not self.had_description or self.description_lines == 0: line = self.description_line or self.line