302 changes this week, down from Week 39's 430 and level with Week 38. Two stories carry it. First, a community is now run by roles, approvals and waiting periods, not by whoever holds the admin login. Risky changes wait in a queue until enough people approve them, and anything that takes power away is announced and held for a cooling-off period first. Second, last week's off-the-books experiment landed on the main line: a community can now admit someone on the word of three vetters without anyone learning which three. Around those two: the community service retired its last unsigned entrances, credentials moved to a new standard version, and messages now find their way between two message hubs and survive a laptop going to sleep.
Last week every project got one signed front door. This week was about who may walk through it, and what happens when they do: who gets to decide, how many must agree, and how long before it takes effect.
Administration in a community is now role-based: built-in and custom roles, each a set of named permissions. An operation that needs consent waits in an action list and runs on the N-th approval. Removing an administrator or lowering the approval threshold needs a second person. A change that takes rights away is announced, then cools off before it bites, and the work survives a crash in between.
Last week's zero-knowledge work, which let an applicant prove that three eligible vetters vouched without revealing which, was on local branches only. This week it landed on main in both the trust backbone and the community app, each as a single change, and now uses the published release of the proof library.
Every call the community's client makes is now a signed request. Members' everyday actions, the policy and identity logs, website content and the console's signing keys all moved over, and the matching old web routes were removed. The identity-log host deleted its old management interface on both the control plane and the edge, and its witness now accepts signed requests only.
A new standard shape for what a community issues: role credentials, a “vetted” statement and a “witnessed” statement. A community can now record its own identity check as a “vetted” statement and deliver it to the person. The community app keeps it and offers it as proof of personhood elsewhere.
A secure-protocol conversation can now start with someone on a different message hub. The toolkit's live connection recovers after a laptop sleeps or the network drops, a message is no longer lost to a waiter that gave up, and the hub reconnects to its store after a restart. One fix stopped incoming messages being silently dropped.
The community app can now be published to crates.io and cut releases 0.3.1 and 0.4.0. The git-signing bridge is published too, with ready-built binaries and a setup command that writes a runnable folder. Six projects moved to the same new dependency set together. A key test set went from 16.3s to 3.6s on a laptop.
Last week the most powerful role started needing a second admin's consent. This week extends that idea to the whole community. Removing an admin, lowering how many approvals are needed, or changing who has authority now takes a second party. A cut to someone's rights is announced and waits before it applies, so a stolen login can't quietly lock everyone else out before anyone notices.
A community where vetters could be pressured or targeted can now admit people without keeping a list of who vouched for whom. Moving this from a local branch to the main line is the step that makes it something a real community could switch on, though the proof library still needs an independent review first.
Checks and balances assume more than one administrator. Rather than make small groups fake a second person, a community can declare single-administrator mode at install time. It is recorded as one person under several identifiers, and the two-person rules are knowingly relaxed instead of quietly broken.
Think of a club's bank account. A small club might let the treasurer sign alone. A bigger one wants two signatures on large cheques, a notice period before a committee member is removed, and a record of who agreed. Until now our communities had the first model, with a few emergency extras. This week they got the second, and a small club can still choose the first, openly.
What changed. Administration is now built from permissions grouped into roles, built-in or custom, each with an explicit scope. A permission can have its own set of approvers. An operation that needs consent goes into an action list and completes on the N-th approval. Emergency (“break-glass”) ratification, join review and vetting review all live in the same list. Operator changes must be acknowledged. Removing rights is announced, cools off, and survives a crash part-way through. An administrator's phone approver can serve as the extra confirmation step, and the browser wallet can now answer that request too. The admin console updates live, and only ever receives a hint to re-read, never the data itself.
It reaches the code, too. A community's rights over its git repositories are now the same kind of permission as everything else, so there is one model of authority rather than two. A suspended member's git rights are withdrawn from the registry and the forge until the cooling-off ends. A new gate closes pull requests from people the policy doesn't allow, enforced by the git-signing bridge.
Last week this page described working zero-knowledge vetting on local branches that were not pushed, not merged and behind main. This week those branches came up to date and landed. Alongside, the credentials a community issues moved to a new standard version, and a community can now vouch in its own name.
The community side (enrolling vetters, rate-limited vouching tokens, one-time challenges, proof checking, issuing admission) landed in the trust backbone. The applicant and vetter side landed in the community app, with its end-to-end test and a fixture each side checks against the other. Both now use the published proof library. It is still opt-in per community.
Role credentials, “vetted” and “witnessed” statements, identity credentials and an explicit issuer scope landed together in the trust backbone and the community app. A note went out to operators who wrote their own policy rules, since those rules see the new shape.
A community's own identity check is now recorded as a “vetted” statement, bound server-side to a pseudonym that is unique per person, and delivered to its subject. The community app keeps it and offers it as personhood evidence.
An approved applicant whose credential never arrived used to be stuck. They can now ask the community to send it again, from the app with one key. The join flow speaks the newer join-request version and falls back to the older one.
Still to come. A pushed branch in the community app (one change, dated just after this window and not counted) adds badges that show a credential's post-quantum signing and whether a community uses hidden vetting. The proof library remains a research artefact that has not been audited.
Counted the same way as the previous eleven reports, across the same eight Rust projects. Every starting figure below matches the ending figure Week 39 published. The browser wallet and the phone approver are written in TypeScript and Swift, so they add nothing to these counts. Their changes are included in the headline totals above.
In one line: a smaller but denser week. Fewer changes than last week, a large rise in checks, and the unused-code measure rising more slowly but still rising.
Three honest notes. First, 302 against 430 is a real fall, with the same ten projects and the same method. Last week's total was swelled by git signing's forge work. Second, the removed lines are mostly deliberate. The trust backbone removed 59.5k lines and the identity-log host 28.8k, largely retired web routes and their tests, not lost features. Third, git signing's 18 version tags reflect a release after almost every dependency bump, not 18 sets of new features.
And one about the reading itself: two of the ten local copies were behind the published main line when this ran (git signing by 15 changes, the browser wallet by 3), and the trust backbone's copy was on a docs branch. Every figure on this page comes from origin/main, not from those copies.
The published report tracks around eleven projects. This page covers the ten held locally, so the totals here are a minimum rather than the whole picture. Eight of the ten shipped something this week.
Bring the phone approver up to date. It is now three weeks quiet while the community made an approver device part of how admins confirm risky actions. It is the standing risk on this page. Run the approval rules with a real community. Roles, approvals and cooling-off landed in three days; the next evidence is a community living with them, including one in single-administrator mode. Get the proof library reviewed. Hidden vetting is now on main, which makes an independent review of the research library the gate before any community switches it on. The badge branch that shows it to members is pushed and waiting. Turn on the git gate for real. The bridge is now published with a setup command; one community governing real repositories is the next step. And stop the unused-code rise. +5 is much smaller than last week's +22, but it is the fourth rise in a row.