The First Person Network
The Vision
The First Person Network is the overarching vision that the OpenVTC ecosystem implements. Described in the First Person Project white paper, it proposes a world where digital identity is asserted by you, not assigned to you.
The name is deliberate:
- First person — “I am” rather than “they say I am”
- You create your own identity (DID)
- You host it on the domain of your choice — or on a hosted VTA Farm that holds your agent but never your admin key
- You build trust through real relationships, not institutional endorsements
- No organization can revoke your identity or gatekeep your participation
How It Differs from Existing Models
| Model | Who controls identity? | How is trust established? |
|---|---|---|
| Centralized (Google, Facebook) | The platform | The platform vouches for you |
| Federated (OAuth, SAML) | Identity providers | An IdP vouches for you |
| Self-sovereign (general SSI) | You | Varies — often still requires institutional issuers |
| First Person | You | Peer-to-peer relationships, collectively verifiable |
The key distinction from general self-sovereign identity (SSI) is the emphasis on peer-to-peer trust building. Many SSI systems still rely on institutional credential issuers (governments, universities, employers). The First Person model builds trust from individual relationships up — your trust graph is the sum of your genuine connections.
The Protocol
The First Person Protocol defines how participants:
- Create and host their Persona DID (using did-webvh)
- Establish private communication channels (TSP, with didcomm for interop)
- Exchange Personhood Credentials and Relationship Credentials
- Build and traverse the Decentralized Trust Graph
- Form Verifiable Trust Communities
The Know Your Developer Problem
The initial application focus is Know Your Developer — establishing verifiable developer identities in the open-source ecosystem. The problem is real: how do you know that a contributor is who they claim to be? That their commit history is genuine? That they’re not a sock puppet or a compromised account?
This challenge has intensified with the rise of AI agents. An AI can now convincingly imitate a real developer — committing, reviewing, and communicating in ways that are indistinguishable from a person. Traditional trust signals like GitHub reputation or commit history are unreliable when they can be generated by a machine. The question is no longer just “who are you?” but “are you human at all?”
The First Person Network answers this by letting developers build verifiable trust graphs through their real professional relationships. Instead of trusting a GitHub account, you can verify a chain of peer attestations, endorsements, and witness proofs — all anchored in communities that have verified their members’ personhood.
Since July 2026 this has a concrete, shippable form: Verifiable Git Infrastructure (VGI). A developer signs commits with a key held in their VTA (did-git-sign), the commit names its signer by DID — since the Dogwood release (VGI 0.4.7) as a Signed-by-DID: trailer written by a commit hook, so user.email stays an ordinary address and forges still attribute the commit — and a project’s CI (verify-trust) asks the community’s Trust Registry whether that DID is authorized to sign for this repository right now — failing closed. “VGI verifies, the VTC decides”: remove a contributor from the registry and their next commit fails everywhere at once. The human side of the same story is agent names — example.com/@alice instead of a DID string — so a reviewer sees a name that is cryptographically claimed by the DID document, not a display name anyone could type. And since September 2026 the human root of all of this — the moment a community checks that a new member is a real person — is made explicit as peer-identity-vetting.
By the Eucalyptus release (2026-10-07) the Know Your Developer story is complete enough to walk end to end. A developer is vetted into a community by existing members — from the OpenVTC TUI or from the Keyring phone wallet, in person or on video, with the option of proving “k distinct vetters vouched for me” in zero knowledge so that nobody learns which ones. Admission issues a membership credential and, where the community grants it, a git.commit.sign right on a community git namespace that the community itself governs on GitHub or Forgejo. The developer’s commits are then signed by their VTA — the key never leaves it — and every pull request is checked in CI against the community’s Trust Registry, with PR-open gates and required approvals enforced by a bridge the community runs. The community the whole design was modeled on, the Linux kernel’s maintainers, saw it presented at the Linux Plumbers Conference in Prague on the day Eucalyptus was tagged; that story has its own page, kernel-web-of-trust.
See also: decentralized-trust-graph, verifiable-trust-community, openvtc, kernel-web-of-trust, peer-identity-vetting, keyring-wallet