OpenVTC Wiki

11 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.

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 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, age, or membership — 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, and the did-hosting-service runs the infrastructure for hosting and resolving these DIDs at scale. 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.

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, or messages, and it handles the cryptography. 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). It is also the holder’s credential vault — W3C Data Integrity, BBS, SD-JWT and, since August 2026, ISO mdoc. For most people the VTA runs in the cloud — self-hosted, or managed on the project’s VTA Farm — while thin Personal Network Manager surfaces (the pnm CLI, the mobile Authenticator, the VTA Wallet browser plugin) approve and act on its behalf; see vta-topology for the vocabulary.

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. The ecosystem’s preferred transport is now the lean ToIP Trust Spanning Protocol (TSP), with DIDComm v2 as the interop fallback — the mediator is dual-protocol on one connection, a VTA can run TSP-only, and communities publish which transports they offer. 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. Underneath, a reliable delivery layer (durable outbox, delivery evidence, ack-only-after-handoff, stored-mail pickup on connect) arrived in July 2026 to close a class of silently lost messages; and for the wider Aries/Credo world the mediator also speaks DIDComm v1.

Layer 4: Trust Credentials

Trust relationships are expressed as Decentralized Trust Graph (DTG) Credentials — six Verifiable Credential types defined by the Trust Over IP Foundation in the DTG Core Credentials specification, which in July 2026 became a formal ToIP deliverable (v1.0 Working Draft 01) in its own repo. They fall into three functional categories, with the foundational credentials being:

  • Membership Credentials — proof that you are a real, unique human within a community (the ecosystem’s answer to AI agent impersonation). Membership is verified through a bi-directional pair of VMCs.
  • 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).
  • Endorsement Credentials, Witness Credentials, and Persona Credentials — annotations that strengthen existing edges with skill endorsements, third-party attestations (now bound to the specific edge and the specific exchange — see trust-task-context-binding), and persona linking

These credentials form the Decentralized Trust Graph — a graph whose nodes are entities (people, devices, agents, communities) 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.

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 (with agent names), establishing trust relationships with others, and participating in trust communities — including multiple trust communities simultaneously, each with its own persona and lifecycle. The multi-community pivot completed in June 2026 (Banyan); v0.3.0 (August 2026, in the Cypress release) made the join ceremony robust to the realities of asynchronous messaging — joining by DID or agent name, over TSP or DIDComm, with stored mail collected on connect and unanswered joins polled rather than waited on. Behind the scenes, it orchestrates the VTA, TSP/DIDComm messaging on the reliable delivery layer, and Trust-Task exchanges.

For the Know Your Developer case specifically, Verifiable Git Infrastructure (VGI) — split out of OpenVTC in July 2026 — signs git commits with a VTA-held key 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 authorises. 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.

On mobile, the VTI now ships two thin native apps — Authenticator (a holder’s pocket approver for AAL step-up over DIDComm v2) and PNM mobile (mobile counterpart of the pnm operator CLI) — both built on a shared Rust UniFFI engine, vta-mobile-core.

And for anyone who wants to stand the whole stack up themselves — from a throwaway learning VM to a production deployment — the vti-setup repo provides tested, version-pinned setup guides organized by persona (developer, community manager, sysop), pinned since August 2026 to the Cypress coordinated release (coordinated-releases). Kubernetes deployment instructions, alongside the managed VTA Farm, are coming soon — so that deploying a VTA for an individual becomes straightforward either way.

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 August 2026 the ecosystem has just cut Cypress — its third coordinated, cross-project release and the first to go through formal release candidates (coordinated-releases). Cypress is the clearest statement yet of what the stack is: VTA 0.17 / vta-sdk 0.25, OpenVTC 0.3, dtg-credentials 0.2 (tracking the spec’s first formal Working Draft), TDK mediator 0.18 with the reliable delivery layer and agent names, did-hosting-service 0.8, VGI 0.4.5, didwebvh-rs 0.6 — all on trust-tasks 0.9, all exercised together, all pinned by the setup guides. The frontier has moved accordingly:

  • Convergence, not expansion. The July–August work across every repo was about making one shape out of many: every wire operation is now a canonical Trust Task (the VTI retired its legacy REST surfaces with a usage metric gating their deletion, the VTC its openvtc/vtc bindings, did-hosting its own URIs, the TDK mediator its 19-task admin family); three approval mechanisms became one runtime-manageable model with a break-glass; the vta-service monolith became eleven subsystem crates; and publishing moved to release-plz. A codebase preparing for 1.0.
  • TSP is the transport, DIDComm the bridge. No longer “preferred in principle”: the VTA can run TSP-only, communities publish their transports, registries are reached by DID over TSP, joins run over TSP, the browser wallet has a pure-TypeScript TSP stack. DIDComm’s role is interop — including, newly, DIDComm v1 for Aries/Credo wallets.
  • The spec is formal — and being shaped by implementation. The DTG Core Credentials spec is a ToIP deliverable at Working Draft 01: three categories not four, four DID types not five, a new taskContext binding, and a Witness Credential that now must name the exchange and the edge it attests — changes driven directly by implementer feedback (a wallet’s witness server) and already reflected in dtg-credentials 0.2.0, with one flagged digest-encoding divergence still to resolve. Two companion specs (verifiable data structures; trust-task protocols) are announced.
  • Names for humans, trust for git, login for the web. Agent names (example.com/@alice) landed across the TDK, did-hosting, the VTA and OpenVTC in a single fortnight; VGI turns Know Your Developer into a required CI check; the browser wallet is heading for the Chrome Web Store with its core library about to become a standalone VTA client.
  • The VTA holds more kinds of things for more kinds of holders. ISO mdoc joins DI / BBS / SD-JWT in the vault; non-extractable keys and a three-gate signing-oracle guarantee harden the oracle; the phone verifies request proofs on-device before prompting; and the Nitro enclave no longer bakes tenant config into the image, so one attested image can serve a fleet.
  • Deployment is getting easier. The VTA Farm is open self-signup; pre-built binaries track the latest tagged release; and the next vti-setup milestone is Kubernetes deployment instructions alongside the VTA Farm, so that an individual’s VTA — managed or self-run — is a short path rather than a weekend.

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 and the AI agent as first-class holders and approvers of credentials, TSP as the common transport, and a formal ToIP specification underneath.

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