196 changes this week, down from Week 40's 302. Most of them landed on two days, Monday and Sunday. Two stories carry it. First, your wallet is now how you sign in. A website shows a link, your browser wallet checks it, you approve, and you're in. No password is involved and your key never leaves the wallet. This arrived in the community, its new member portal, the operator console and the identity-log host. Until now, ordinary members could not sign in to their community anywhere. Second, the first real steps toward accepting credentials from European government wallets (Switzerland's swiyu and the EU's digital identity wallet): reading the keys they use, checking whether a credential has been revoked, and an identity the community can present to those wallets. Around those two: the community app shipped 0.5.0, which walks applicants and vetters through hidden vetting step by step. Two real-world messaging outages were fixed. And your agent now signs git commits itself, so the signing key never has to leave it.
Last week settled who may run a community. This week was about getting people in: members signing in with their wallets, wallets from outside our own ecosystem being understood, and applicants able to see where they are in the joining process.
A site shows a sign-in link. The browser wallet reads and checks it. You approve, and your agent signs a short-lived note saying “this browser may act as me on this site until a set time”. The community console, a new member portal and the identity-log host all accept it. A session can't outlive that note, and the console shows roughly where the request came from.
The community can now verify credentials signed with the key types swiyu and EU wallets use, and check a credential against a published revocation list. Members whose keys sit in a phone's secure chip can sign as members. The community also has a separate, sealed verifier identity to present to those wallets, and the developer kit has the core of the matching protocol.
The community app's 0.5.0 turns joining and vetting into a journey: every step, where you are, and why. Monday alone brought 39 changes, most of them fixes found by walking those journeys. In the admin console, hidden vetting can now be seen, run and switched off, and every refusal says why.
The git-signing tool used to export the signing key from the agent on every commit. Now the agent signs the commit itself, and its signature is only valid as a git signature. The key stays where it lives. The community app turned this on, and the git bridge can now require N approving reviews before a merge.
On October 5, admin sessions stopped receiving replies because unreadable messages piled up in an inbox until it was full. On October 11, after a DNS outage, agents couldn't hold a connection for over an hour. Both causes were found and fixed the same week. The browser wallet now also falls back to a direct connection when its message hub goes quiet, and tells you it has.
Encrypted files in data rooms, stored on disk, S3 or Google Cloud. The agent can act as key holder for cloud accounts, handing out short-lived credentials. The admin console's redesign reached its dashboard, members, access lists and a command palette. The trust backbone also adopted named releases and cut its first under the new scheme, “Eucalyptus”.
Until this week a community's sign-in admitted administrators only, so an ordinary member had nowhere to log in. They now have a portal of their own, kept separate from the admin console by the server itself, not just by what each page displays. They sign in with the same wallet they already use, and there is no password to steal.
Until now our tools understood only credentials made by our own tools. Being able to read what government-backed wallets issue, and to check whether it has been revoked, is the start of a community accepting a real-world ID. It isn't finished: the full request-and-present exchange with a swiyu wallet is designed but not yet running end to end.
Signing git commits used to mean copying the key out of the agent every time. Cloud-account secrets now stay inside the agent and are left out of portable backups. A swiyu verifier key is passed over in a sealed hand-off and never joins the community's own signing keys. Across the week, keys moved less often.
Think of a boarding pass. The airline issues it, it names one flight, and it stops working after departure. The gate agent doesn't need your password, only a pass they can check came from the airline. Wallet sign-in works the same way. Your agent issues the pass, it names one website, and it expires. The website checks it and lets you in.
What changed. The agent can now sign a sign-in grant: “let this browser key act as me at this site until this time.” A device can register a user-verification key when it enrols, either a phone's secure chip or the browser wallet's passkey. Each site publishes what it supports in its public identity document. The browser wallet reads sign-in links strictly to the specification, refuses malformed ones, and can now offer to join an unknown community or trust an unknown identity host straight from a sign-in code. On the community side, a member portal at /members admits only active members. The check runs at sign-in, on every refresh and on every request, and a session ends when its grant does. The operator console's login page uses the same link. The identity-log host gained wallet sign-in on Sunday, and checks itself to confirm its public identity lists everything a wallet needs.
Switzerland's swiyu and the EU's digital identity wallet issue and present credentials in their own standard format, signed with different kinds of keys from ours. Nine changes this week, six in the trust backbone and three in the developer kit, all filed against one goal: a community that can ask one of those wallets for a credential and trust the answer.
The community, the agent and the shared identity resolver could verify only one kind of signature. They now also verify the two kinds these wallets use, from issuers published on the web. The check is strict: the issuer's key decides the algorithm, and nothing in the credential can choose a weaker one.
Support for the new IETF Token Status List standard: a compact list an issuer publishes to say which credentials it has revoked. The community reads it, but only after confirming the credential's own issuer signed it.
A member whose key lives in a phone's secure chip or an EU wallet can now sign requests, rotate keys and receive credentials as a member. Before, all of it assumed one key type.
A swiyu wallet answers only a verifier listed in the Swiss registry. The community now gets a separate verifier identity. Its key arrives by a sealed hand-off and is never mixed with the keys that sign the community's own credentials. The agent has a ready-made template for creating that identity.
Still to come. The developer kit now has the protocol core for requesting and decrypting a presentation (OpenID4VP 1.0), and the design for the community acting as a verifier was written this week. The full exchange with a real swiyu wallet has not yet been run, and this page doesn't claim it has.
Counted the same way as the previous twelve reports, across the same eight Rust projects. Every starting figure below matches the ending figure Week 40 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: fewer changes, more of them new features, and checks still rising steadily.
Three honest notes. First, 196 against 302 is a real fall, with the same ten projects and the same method. No project changed at all on Thursday or Friday. Second, this week mostly added. Only 18.4k lines were removed, against 93.8k last week, when old web routes were retired. Third, the stand-in count rose much less than last week (+17 against +61). The new work leaned on full tests more than on fakes.
And one about the reading itself: this was generated on Sunday evening, while work was still landing. Anything merged after these figures were taken is picked up by Week 42, which starts from exactly where this one stopped. Two local copies were behind the published line (trust backbone by 1, identity-log host by 2). Every figure here comes from origin/main.
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. Seven of the ten shipped something this week.
--monochrome), and a repository can choose which forge account it uses.Bring the phone approver into sign-in. Four quiet weeks now, while wallet sign-in added a slot built for a phone's secure chip. It is the standing risk on this page. Run one exchange with a real swiyu wallet. The signatures, revocation check, verifier identity and protocol core are all in place. Next is an end-to-end request and presentation, on test data. Move the community app to the new dependency set. Git signing and the trust registry moved on Sunday; the community app's move is on a branch, not yet merged and not counted here. Get the proof library reviewed. Hidden vetting is now easy to follow in the app, which makes the independent review of its research library more pressing, not less. And stop the unused-code rise. +3 is the smallest rise yet, but it is the fifth in a row.