← All Articles
Product Launch

A Community of Two: OpenVTC, Six Months After We Opened It Up

Most trust systems start at the top and wait for an authority to vouch for everyone. OpenVTC starts with two people who already know each other. Six months after we contributed it to the Linux Foundation, here is what has shipped, why it matters, and what it still cannot do.

Every open-source project starts the same way. Someone writes some code, someone else finds it useful, and one of them says to the other: “I’ve seen your work. I trust you with commit access.”

That sentence is the most important security control in open source. It is also, almost everywhere, unwritten. It lives in a maintainer’s memory, a chat thread, or a list of usernames on a platform the project does not own. When it is wrong, as it was with XZ utils, nobody can trace how the trust was built or who granted it.

The first generation of self-sovereign identity tried to fix this from the top down. It waited for governments, universities and employers to issue everyone a credential, and then hoped communities would build on them. Most are still waiting.

OpenVTC starts at the other end. It starts with two people who already know each other, and it writes that sentence down: signed by both of them, checkable by anyone, and owned by neither a platform nor us.

Six months on

In March we contributed OpenVTC to LF Decentralized Trust and explained why trust infrastructure cannot be proprietary. We published the architecture, and alongside kernel maintainer Greg Kroah-Hartman we demonstrated Linux ID as a replacement for PGP key-signing ceremonies.

At the time it was a protocol and a promise. Today it is a tool you can install.

Most of those six months went into building rather than launching. Since March we have merged more than 2,900 pull requests across 15 repositories in the OpenVTC organisation, and published more than 70 Rust crates that have been downloaded over 650,000 times. What you install today sits on top of all of that.

What is new

OpenVTC is now a full terminal application for joining and running communities where membership is something you can prove. The project has its own home at openvtc.net and its own GitHub organisation, github.com/OpenVTC.

  • One account, many communities. Join a foundation, a working group and a side project from the same account. Each runs its own session, so if one community goes down, the others keep working.
  • A separate identity per community. You can create a fresh identity for every community you join, or reuse one on purpose. OpenVTC warns you when reusing an identity would let someone link your memberships.
  • Rules you can read and test. Joining, leaving and changing roles all run through the community’s own policy. The policy denies by default and can be tested in a simulator before it goes live.
  • Two open messaging protocols, side by side. DIDComm and the Trust over IP Trust Spanning Protocol (TSP) both run directly between identities, end to end encrypted, with no central server in the middle.
  • Signed commits that lead to a person. did-git-sign signs your git commits with the same identity your community already trusts. The key stays in your agent and never touches disk.
  • A two-minute start. The VTA farm hosts a Verifiable Trust Agent for you, so you can try everything without running a server.
cargo install openvtc
openvtc setup
openvtc

Why this matters

OpenVTC serves three groups of people, and each gets something different from it.

Contributors get a reputation they own. Today your track record belongs to whichever platform hosts the project. With OpenVTC, an endorsement is a signed credential that you carry, so it moves with you from one project to the next.

Maintainers get an answer to “who wrote this?” A signature on a commit leads to an identity, and that identity leads to the people who vouch for it. That doesn’t make a supply-chain attack impossible. As I said at the Linux Foundation summit, it raises the cost. The XZ attacker needed nothing but patience. An attacker facing OpenVTC needs a history of trust from several independent people, and every one of those vouches can be checked and revoked.

Community owners get rules nobody else can override. Each community runs its own service with its own identity, policy and governance. It can be fully open, invitation only, or gated by member vetting. Every policy change is signed, kept in an append-only log, and can be rolled back. It works alongside GitHub, Codeberg and Forgejo, so projects don’t have to move.

There is a fourth group arriving whether communities are ready or not: AI agents. Maintainers are already dealing with a rising volume of machine-generated pull requests and bug reports. In January, curl ended its bug bounty after six years, because a flood of AI-generated reports had pushed the share of real vulnerabilities below 5%. OpenVTC treats people and agents as separate entities, each with its own identity. An agent only ever gets a narrow, revocable slice of the authority of the person it works for. The same principle runs through our Agent Gateway. Open source just happens to be where the problem shows up first.

Proving you belong without saying who you are

Accountability usually comes at the cost of privacy. OpenVTC is designed so it doesn’t have to.

Members can use zero-knowledge proofs to show they belong to a community without revealing who they are, which keeps them unlinkable from one community to the next. The most interesting use is hidden-vetter admission. A community can require that, say, three existing members vouch for a newcomer. It can verify that three did without learning which three. Nobody can be pressured over a vouch they gave, and nobody can game the system by knowing who the gatekeepers are.

It is the same idea as the secret ballot. You can count the votes, but you cannot see who cast them.

The cryptography behind it is the Predicate Credential System, built by zkBricks and UC Berkeley. The research is published in A Cryptographic Framework for Proof of Personhood. We’ll go deeper on how it works in OpenVTC in a follow-up post.

Credentials can also carry post-quantum ML-DSA signatures alongside Ed25519, so a vouch signed today will still be trustworthy when quantum computers can break today’s signatures.

What it does not do (yet)

It is worth being direct about the limits.

  • It is early. OpenVTC is terminal-first and built for developers. If you are not comfortable with cargo, it is not ready for you yet.
  • The VTA farm is for development and testing. For your real identity, run your own Verifiable Trust Agent. The cold-start guide covers it, including running it inside a hardware-isolated enclave.
  • The browser plugin is in open beta and is not yet in the Chrome Web Store.
  • It cannot make a bad actor honest. It makes trust visible, checkable and revocable. Deciding whom to trust is still up to the community.

Built with others, on purpose

Here is what Affinidi has contributed: OpenVTC itself, the Verifiable Trust Infrastructure underneath it (the agent, the community service and the operator tools), our Rust implementation of did:webvh, which we donated to the Decentralized Identity Foundation, and our open DIDComm libraries in Rust and Dart.

None of it would mean much on its own. OpenVTC follows the model in the First Person Project white paper and was built with the First Person Cooperative, with zkBricks and UC Berkeley contributing the zero-knowledge layer. Its credentials come from the Trust over IP Decentralized Trust Graph specification, which is developed in the open by a working group. It is governed as an LF Decentralized Trust Labs project and licensed under Apache-2.0.

The strongest evidence that this is a standard and not a product is that somebody else built on it. Harvard’s Applied Technology Lab has built Keyring, a mobile identity wallet based on the same trust-graph specifications. Two independent teams and two different form factors can verify each other’s credentials. Interoperability like that can’t be announced; it has to be shown.

Two people is enough

Most trust infrastructure asks you to wait: for an authority to issue you something, for a platform to verify you, for everyone else to join first. OpenVTC doesn’t. A community of two works on day one. A third person joins because two people vouched for them. Trust grows the same way it always has between people, except that now it can be checked.

Your identity, your community, your data, your code. Own those four, and everything built on top of them is yours to decide.

Install it, vouch for someone you’ve worked with, and ask them to vouch back.

Get started

Further reading: Open by Design explains why we built this in public. The Architecture of Accountability explains how it works.

Open SourceOpenVTCDecentralised IdentityLinux FoundationTrust
Try it Get OpenVTC and join your first community

Cookie Preferences

We use cookies to enhance your experience. You can manage your preferences below. For more information, read our Cookie Policy.

Strictly Necessary Always Active

These cookies are essential for core website functions such as security, session integrity, and cookie preference storage. They cannot be disabled.

  • _cf_bm: Distinguishes humans from bots (Cloudflare) · 30m
  • _cfuvid: Ensures secure browsing (Cloudflare) · Session
  • __hs_initial_opt_in: Prevents HubSpot's banner · 7 days
  • _gtm_debug: GTM debug mode (testing only) · Session
Analytics

These cookies help us understand how visitors interact with the site so we can improve content and performance. All data is aggregated and anonymous.

  • _ga, _gid, _gat: Google Analytics · Session – 2 years
  • __hstc, hubspotutk, __hssrc: HubSpot visitor tracking · 13 months
  • __hs_opt_out: HubSpot opt-out preference · 6 months
Marketing & Targeting

These cookies allow us and our partners to serve personalised ads and measure campaign performance.

  • _gcl_au, _gcl_dc: Google Ads conversion tracking · 90 days
  • IDE: Google Display Network personalisation · 1 year
  • _fbp: Meta / Facebook remarketing · 90 days
  • li_gc, _li_fat_id, bcookie: LinkedIn tracking · 1–24 months
  • guest_id, personalization_id: Twitter/X analytics · 2 years