OpenVTC Wiki

8 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 affinidi-webvh-service runs the infrastructure for hosting and resolving these DIDs at scale.

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. All keys derive from a single seed phrase using BIP-32 derivation, so backing up one mnemonic protects everything.

Layer 3: Secure Communication

Participants communicate via DIDComm v2 — end-to-end encrypted messaging where the encryption is tied to your DID. Messages are 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 and support for the newer Trust Spanning Protocol (TSP).

Layer 4: Trust Credentials

Trust relationships are expressed as Decentralized Trust Graph (DTG) Credentials — a family of Verifiable Credentials defined by the Trust Over IP Foundation (spec v0.3). These fall into four 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, 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 command-line tool (and TUI) that ties it all together for end users. It walks you through creating your identity, establishing trust relationships with others, and participating in trust communities. Behind the scenes, it orchestrates the VTA, DIDComm messaging, and credential issuance — but from the user’s perspective, it’s as simple as: set up your identity, connect with people you know, and build your trust network.

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 May 2026, the ecosystem is in active early development with clear momentum toward production readiness:

  • The VTI/VTA released v0.5.0 — sealed-bootstrap in May: every secret-bearing transfer between VTA, integrations, and CLIs is now an HPKE-sealed bundle; DID minting is template-driven; and the DIDComm protocol surface can be enabled, disabled, or migrated on a running VTA without rebuilding it, with mediator changes going through a drain set so in-flight messages keep landing while the new mediator picks up traffic. A unified pnm services … CLI for live runtime service management (enable/disable/list/rollback) followed in P0–P5 PRs, with the 0.6.0 workspace bump in flight on a feature branch.
  • OpenVTC released v0.2.0 in May — workspace consolidation (openvtc-cli2 → openvtc, the legacy openvtc-cli deleted), full TUI main menu (eight panels, real-time inbox), DIDComm service integration replacing manual messaging, R-DID generation across both BIP32 and VTA backends. A substantial security pass folded into the same release: per-entry random Argon2 salt, did-git-sign parent-process gating + audit log, DIDComm replay window, tagged-variant downgrade defence on SecuredConfigFormat, real W3C DID Core 1.0 syntax parser.
  • The WebVH service released v0.6.0 in May — web-based ACL invites, VTA template, offline bootstrap, plus a substantial security pass on cross-service refresh handlers (JWS-signed envelopes binding signer to session DID), refresh-token rotation TOCTOU closed end-to-end via a new atomic take_raw_atomic primitive, registry/proxy trust chain hardening in webvh-control, and stricter watcher sync validation.
  • DTG Credentials is still at v0.1.2; the recent spec changes (bidirectional Edge Credentials, ZKP construction split) have not yet been picked up in the implementation.
  • The TDK shipped affinidi-tdk-common v0.6.0 and a mediator 0.14.0 release with pluggable storage, unified secret backend, and a new dedicated mediator-setup wizard package; affinidi-messaging-test-mediator was published as a standalone crate, immediately consumed by the OpenVTC test harness.
  • didwebvh-rs has been quiet at v0.5.2; tracking the DIF didwebvh 1.0 spec.
  • The DTG specification had two notable PRs land in late April / early May:
    • PR #31 (merged 2026-04-30) — Bidirectional Edge Credentials. Both VMCs and VRCs are framed as edges between existing entities, each requiring a bi-directional pair to constitute a complete edge in the graph. Nodes are entities, not credentials. See decentralized-trust-graph.
    • PR #33 (merged 2026-05-08) — ZKP construction split. The old “Zero-Knowledge Proof Requirements” subsection under VRC is replaced by two distinct constructions: a pairwise ZKP (anchored to VRC; available regardless of shared community) and a community-anchored ZKP (anchored to VMC; the three-part proof requiring same C-DID). The Overview now states that DTG credentials SHOULD use ZKP presentation when privacy is desired, and that implementations SHOULD make ZKP presentation the default. See zero-knowledge-proofs.

The direction of travel is toward a fully self-contained, publicly deployable trust infrastructure that any community can adopt — with mutable runtime surfaces, hardened cross-service trust paths, and ZKP-by-default privacy.

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