OpenVTC Wiki

15 min read

OpenVTC Ecosystem Overview

The Problem

OpenVTC exists to solve the Know Your Developer problem: how do you know that a contributor to an open-source project is who they claim to be? That their commit history is genuine? That they’re not a sock puppet or a compromised account? And increasingly, that they’re even human?

AI agents can now convincingly imitate real developers, committing, reviewing, and communicating in ways indistinguishable from a person. Traditional trust signals like GitHub reputation or commit history are unreliable when they can be generated by a machine. The XZ Utils compromise showed the other failure: an attacker who patiently builds a legitimate-looking history is not caught by any key check at all.

Today, most digital identity is delegated — you prove who you are by showing that some authority (Google, your employer, a government) vouches for you. This works, but it creates dependencies on centralized gatekeepers, locks your identity to their platforms, and breaks down in contexts where no single authority is trusted by all parties.

The OpenVTC ecosystem takes a different approach: first-person identity. Instead of asking “who does an authority say you are?”, it asks “who do the people around you say you are?” Trust isn’t granted by a central authority — it’s built from the ground up through real relationships between real people, expressed as cryptographically verifiable credentials. The question becomes not just “who are you?” but “can I verify you’re a real person through a chain of real human relationships?” The community this was modeled on from the start is the Linux kernel’s maintainers and their aging PGP web of trust; the project was presented to them at the Linux Plumbers Conference in Prague on 2026-10-07 — see kernel-web-of-trust.

The Big Picture

The ecosystem is a stack of open-source projects that together enable Verifiable Trust Communities (VTCs) — groups of people and organizations who establish, verify, and audit trust relationships without relying on a central authority. The system is built on W3C open standards for Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). Zero-knowledge proofs let participants verify claims — like humanness, membership, or “enough members vouched for me” — without exposing the underlying data, and the spec recommends ZKP presentation by default.

Here’s how the pieces fit together, from bottom to top:

Layer 1: Identity Infrastructure

At the foundation, every participant needs a cryptographically secure identity — a DID. The ecosystem uses did:webvh, a DID method that gives you a portable, self-certifying identifier with a verifiable history of changes. You host your DID document on your own domain or a domain controlled by the provider of your choice, and anyone can verify its entire history of updates, key rotations, and witness attestations.

The didwebvh-rs library provides the Rust implementation of this DID method (0.8.0 at Eucalyptus, now part of the coordinated tag set), and the did-hosting-service runs the infrastructure for hosting and resolving these DIDs at scale — since Eucalyptus with its REST management surfaces gone, every operation a signed Trust Task. Because a DID is unreadable to humans, the ecosystem added agent names in July 2026 — example.com/@alice — a shortcut that redirects to a DID and is only ever shown once the DID document claims the name back in alsoKnownAs. A person may hold several identifiers with different reach; since Working Draft 02 of the spec the holder declares each one’s correlation-scope — pairwise, directed or public — rather than the identifier carrying a fixed type, and the declaration now has a name in the credential: issuerScope.

Layer 2: Key Management and Signing

Your DID is backed by cryptographic keys, but managing keys securely is hard. The Verifiable Trust Agent (VTA) solves this — it’s an always-on service that manages your keys, signs things on your behalf, and can run inside hardware-isolated enclaves so your key material never touches an unprotected environment.

The VTA is the heart of the Verifiable Trust Infrastructure (VTI). It acts as a signing oracle: applications ask it to sign credentials, DID updates, messages — and, since Eucalyptus, git commits, so a developer’s commit key never leaves the agent. Keys derive from a single seed phrase using BIP-32 derivation, so backing up one mnemonic protects everything (with non-extractable internal keys as the deliberate exception) — including post-quantum ML-DSA keys alongside Ed25519. It is also the holder’s credential vault — W3C Data Integrity, BBS, SD-JWT and ISO mdoc — and the holder’s system of record: a persona store whose faces (profiles over an attribute pool, with slots, retirement and composition) sit behind a context boundary, an app-state store, agent memory, and the key custody for data rooms all live in the VTA. Every door into it is audited in a hash-chained log under its own key.

For most people the VTA runs in the cloud — self-hosted, or managed on the VTA Farm — while thin Personal Network Manager surfaces approve and act on its behalf: the pnm CLI, the VTA Wallet browser plugin, the mobile Authenticator, and now the Keyring phone wallet from Harvard’s Berkman Klein Center, which can hold several agents at once and which the Farm can connect to a hosted agent from a single QR code; see vta-topology for the vocabulary. The Farm itself is open source as three repos: the portal, the Kubernetes provisioning backend and the OpenTofu cluster build. Its security model is the point: one Kubernetes namespace per user, every master seed sealed in HashiCorp Vault under a role only that namespace can assume, an operator whose own Vault policy cannot read a seed, and an admin key that is generated on the user’s machine and imported — so the Farm hosts your agent but never controls it.

Layer 3: Secure Communication

Participants communicate over end-to-end encrypted, DID-bound messaging routed through mediators, so participants don’t need to know each other’s IP addresses. The Affinidi Trust Development Kit provides the messaging infrastructure, including a mediator service — since Eucalyptus an operable one, with queue inspection, a live traffic monitor and runtime configuration, all administered through Trust Tasks because the legacy admin surface is gone. The ecosystem’s transport is the lean ToIP Trust Spanning Protocol (TSP) at Rev 3, now on by default in the VTA and the mediator, with relationships formed before any exchange, nested routing across mediators for metadata privacy, and a cross-implementation conformance suite covering Rust, TypeScript, Go and Dart. DIDComm v2 remains as the interop carrier on the same mediator, and for the wider Aries/Credo world — including Keyring — the mediator also speaks DIDComm v1.

Every protocol exchange is expressed as a Trust Task — a versioned JSON document with a canonical trusttasks.org/spec/* URI — so the same operation works over TSP, DIDComm, or plain HTTPS. Dogwood made those documents validated, signed by an identified client and replay-guarded at the dispatch spine; Eucalyptus closed the door: every call into the stack is a signed Trust Task with a proof bound to its sender, and the remaining REST management surfaces in the VTA, the mediator, DID hosting and the trust registry were removed. The ToIP spec registry the tasks live in joined the coordinated tag set for the first time. Underneath, a reliable delivery layer (durable outbox, delivery evidence, ack-only-after-handoff, stored-mail pickup on connect) closes a class of silently lost messages.

Layer 4: Trust Credentials

Trust relationships are expressed as Decentralized Trust Graph (DTG) Credentials — Verifiable Credential types defined by the Trust Over IP Foundation in what is now titled the DTG Credentials Core Specification, a formal ToIP deliverable whose Working Draft 02 (September 2026) reshaped the family around what implementers had learned, and whose late-September revisions pinned a v1 JSON-LD context and a registry of predicates at registry.trustoverip.org/dtg. The foundational credentials are:

  • Membership Credentials — proof that you are a real, unique human within a community (the ecosystem’s answer to AI agent impersonation). Membership is a bi-directional pair: a grant from the community and an acknowledgement from the member; since Eucalyptus a membership can also be renewed.
  • Relationship Credentials — peer-to-peer trust attestations between two people. A relationship is verified through a bi-directional pair of VRCs (one each direction forms a complete edge).
  • Delegation and Authority Credentials — a delegation is a third kind of edge (a grant plus a required acceptance) that moves the permission question without answering it; an authority credential is a statement to a verifier of what a holder may do, attenuable by the holder down a digest-linked chain. Since DTG Credentials v1, a community’s roles — vetter, maintainer, custom roles — are authority credentials, and neither VAC nor VDC is a bearer credential any longer.
  • Statement Credentials — one type with predicate profiles: the spec defines endorses/1 (endorsement) and witnessed/1 (witness, bound to the specific edge and exchange by [[trust-task-context-binding|taskContext]] and a task digest), and the registry adds vetted/1 (a vetter’s statement that they checked who you are) and presented/1. Every new community accepts exactly these four, fail-closed, until its administrators say otherwise.
  • Persona Credentials and Invitation Credentials — persona linking, and the bootstrap of new participants into communities and rooms.

These credentials form the Decentralized Trust Graph — a graph whose nodes are entities (people, devices, agents, communities, and rooms) and whose edges are credential pairs. Anyone can trace trust paths between participants. Communities can federate into Verifiable Trust Networks (VTNs), and trust registries provide authoritative records of which entities are authorized to perform specific actions within a community — including, now, who may sign commits to which repository. The human root of the whole graph — a community checking that a new member is a real person — is peer-identity-vetting: existing members check an applicant in person or on video and sign vetted/1 statements the community counts under a published criterion, and in hidden mode the applicant proves in zero knowledge that k distinct eligible vetters vouched for them without revealing which.

Layer 5: The User Experience

OpenVTC is the user-facing TUI that ties it all together for end users. It walks you through binding to your VTA, minting personas and faces, establishing trust relationships with others, and participating in trust communities — including multiple trust communities simultaneously, each with its own persona and lifecycle. 0.5.0 (October 2026, Eucalyptus) carries the complete applicant and vetter journeys of peer identity vetting, hidden vetting, a Repos panel for community git namespaces with commit signing through the VTA, membership renewal, themes and a Windows build.

The same journeys now exist on a phone. The Keyring wallet (iOS and Android, built on the Keyring fork of OpenWallet Foundation Bifold) began as a peer-to-peer relationship-credential wallet with witnessed exchange and hardware attestation; over September and October 2026 it became a Personal Network Manager over one or several cloud VTAs, speaking Trust Tasks over DIDComm and TSP, able to join a community, approve its agent’s requests, and run the full vetting flow from both sides — the applicant’s and the vetter’s desk — just as the TUI does.

For the Know Your Developer case specifically, Verifiable Git Infrastructure (VGI) signs git commits with a VTA-held key — the key never leaves the agent, and the commit names its signer by DID in a Signed-by-DID: trailer — and lets a project’s CI verify, against the community’s Trust Registry, that every commit in a pull request was signed by a DID the community currently authorizes. Since Eucalyptus a community can govern the forge namespace itself: community-git-namespaces bind a VTC to a GitHub or Forgejo organization, with a rights model (namespace admin, repository owner, maintainer, commit signer), separation of duties, break-glass, and a per-community vgi-bridge that enforces PR-open gates, required approvals and re-signing on the forge. For the web, the VTA Wallet browser plugin lets you log into websites as the controller of your VTA DID (passkey ceremony in the browser, keys never leave the VTA), with rp-sdk-js for the site’s server side and vti-didcomm-js as the browser DIDComm stack; the wallet also carries a management console, a faces manager and a data-rooms pane. For shared context, data rooms give a team, a working group or a family a credential-governed, MLS-encrypted space that its members’ agents can also recall from.

On mobile, the VTI also ships two thin native apps — Authenticator (a holder’s pocket approver for AAL step-up, which now asks the owner before every approval) and PNM mobile — both built on a shared Rust UniFFI engine, vta-mobile-core.

And for anyone who wants to stand the whole stack up themselves, the vti-setup repo provides tested, version-pinned setup guides organized by persona (developer, community manager, sysop), with every download verified, and the production path — Kubernetes, Vault, and the Farm — is the vtafarm-k8s repo. For “which versions go together?”, the answer is the latest coordinated release, Eucalyptus (coordinated-releases).

The First Person Network

The ecosystem implements the First Person Protocol, described in the First Person Project white paper. The vision is a world where your digital identity belongs to you, your trust relationships are verifiable by anyone, and no single organization can revoke your identity or gatekeep your participation.

The name “first person” is deliberate — this is identity asserted by you, not about you by someone else. You create your own DID, you host it on the domain of your choice, and the trust graph is built from mutual attestations between peers.

Where Things Are Heading

As of 2026-10-07 the ecosystem has shipped Eucalyptus, its fifth coordinated release and by far the largest: 36 days, eighteen repositories, close to two thousand commits, two hundred of them breaking — about as much as the three previous releases combined (coordinated-releases). It was tagged on the day Hart Montgomery, Drummond Reed and Glenn Gore presented Cryptographic Proofs of Personhood: Solving the Kernel Web of Trust Problem in a Privacy-Preserving Manner to the Linux kernel developers at the Linux Plumbers Conference in Prague, a day after an LFDT mini-summit on decentralized trust for open-source maintainers and a day before the Kernel Maintainer Summit that had been the target since March (kernel-web-of-trust). The frontier has moved on several fronts at once:

  • The door is signed. Every call into the stack — VTA, VTC, mediator, DID hosting, trust registry — is a signed Trust Task with a sender-bound proof, over TSP, DIDComm or HTTPS, and the REST management surfaces that remained are gone. TSP Rev 3 is the default. This is the end of a road that began at Cypress with canonical URIs and passed through Dogwood’s conformance sweep; from here, “which transport” is a deployment question, not a security one.
  • Vetting is real, in three clients, and can be private. The kernel pilot’s V0 target of 2026-10-05 was met: applicant and vetter journeys in the OpenVTC TUI and in the Keyring phone, vetter grants and a PGP web-of-trust bootstrap in the community console, and — pulled forward from the design’s V2 — hidden vetting on the new Predicate Credential System, a zero-knowledge k-of-n construction that lets a community count vetters it cannot name. It is unaudited and off by default; it is also the first piece of the privacy story that runs.
  • Governed by more than one person. VTC administration is role-based, an unrestricted administrator needs another administrator’s consent, and consequential actions wait in an action list until the N-th approval. Separation of duties and break-glass extend to the forge through community git namespaces.
  • The phone is a first-class holder. Keyring joined the ecosystem from outside the OpenVTC org — a Berkman Klein Center project with its own lineage (Bifold, BC Wallet, Credo) — and in doing so became the stack’s second independent implementation of the vetting protocol and a steady source of conformance findings against the Rust side. The wallet pins the same Trust Tasks release the stack ships.
  • The spec has a registry. The DTG Credentials Core Specification pinned a v1 context and moved its predicates to registry.trustoverip.org/dtg; dtg-credentials 0.13.0 conforms; the VTI, OpenVTC and Keyring issue and verify statements under the same four predicates. The informative credential categories were dropped; Edge Credentials remain as a class.
  • Six more repos under the tag. The Trust Tasks framework and spec registry, didwebvh-rs, the Predicate Credential System, the agent-memory plugin, and the Go and Dart TSP ports joined the coordinated release, which for the first time since Cypress was published as a GitHub Release with a cross-repo version table.
  • Hardening as a standing discipline. A second security sweep closed SSRF, IDOR, replay and authorization gaps; every client vets a host before dialing it; key custody goes only through audited doors; refresh-token reuse is detected.

The direction of travel is unchanged but closer: a fully self-contained, publicly deployable trust infrastructure that any community can adopt — with the phone, the browser, the git forge, the AI agent and the shared room as first-class holders of credentials, TSP as the common transport, a formal ToIP specification with a registry underneath, and the Linux kernel’s maintainers as the first community invited to judge whether it is good enough.

For a release-by-release timeline of how the ecosystem got here — including each project’s recent activity log — see the wiki log and the Recent Development section on each entity page.

Reading This Wiki

This wiki is organized into:

Start with the concepts if you want to understand the “why.” Start with the entities if you want to understand the “what.” The pages are heavily cross-linked — follow the threads that interest you.

Graph View

Backlinks