List view
# Milestone — v2.3 > Planned after v2.2 reaches stable. > **Status: early stage planning.** --- v2.3 focuses on vote integrity and long-term maintainability. It introduces a publicly downloadable bulletin board of cryptographic proofs so that anyone can independently verify that a vote was conducted honestly, and enforces RwLock acquisition order at compile time to prevent deadlocks as the codebase grows. ## Goals - **Bulletin board** — after a meeting concludes, a bulletin board file is made available for download containing all the signatures and proofs used during the vote round. Anyone can use this to verify vote integrity independently. No information about how anyone voted is included — only the cryptographic material needed for verification. - **Compile-time RwLock order enforcement** — the order in which the per-meeting RwLocks (`vote_auth` → `voters` → `admin_auth` → `invite_auth`) must be acquired is currently a convention rather than a guarantee. This milestone encodes that order at the type level so that acquiring locks out of order is a compile error, eliminating the possibility of deadlocks introduced by future endpoint changes. - **Bug fixes** — any bugs discovered during v2.2 or early v2.3 development will be addressed as part of this release.
No due date•0/3 issues closed> Planned after v2.1 reaches stable. > **Status: planning.** --- v2.2 introduces a community theming system. Users will be able to create and apply their own custom themes within a meeting, and optionally submit their theme for inclusion in the official Rustsystem theme collection — with credit given to the creator. ## Goals - **Theme editor** — a UI for creating custom themes by configuring the colour palette used across the application. - **Community submissions** — users can submit their theme for review, with their name attached as the credited creator if it is accepted and shipped as a built-in theme. - **Bug fixes** — any bugs discovered during v2.1 or early v2.2 development will be addressed as part of this release.
No due date> Planned as the first minor release after v2.0 reaches stable. > **Status: planning.** --- v2.1 will focus on reliability and security. The scope is drawn from audit findings and issues likely to surface under real meeting load after v2.0's full release. No significant new features are planned. ## Goals - **Security hardening** — address known vulnerabilities in credential handling, race conditions, and CORS configuration. Add rate limiting on public endpoints. - **Reliability** — improve resilience of file I/O operations and inter-service state consistency. - **UX** — fix failure modes that are silent or opaque to the user, ensuring errors are surfaced clearly and correctly.
No due date•3/22 issues closed# Milestone — v2.0 > Target stable release: v2.0.x (tag placed at same commit as the accepted pre-release) > **Status: in progress — pre-release testing ongoing.** --- v2.0 is the milestone being worked towards through the v2.0.x-beta pre-release series. It represents a complete redesign of the system — server/trustauth split, native TypeScript crypto, stateless frontend, encrypted tally persistence, and a fully redesigned UI. No new features will be added before the stable release. Once confidence in stability is high enough, the stable tag `v2.0.x` will be placed at the same commit as the accepted pre-release.
Overdue by 6 day(s)•Due by March 30, 2026•3/3 issues closed