The problem

Open source software has run for thirty years on an implicit assumption: that anyone showing up with a working patch had invested non-trivial human attention to produce it. That assumption was the silent collateral behind every merged PR. It justified maintainer trust, it filtered low-effort contributions automatically, and it made certain classes of attack uneconomical.

That assumption is now broken.

Two forces have collapsed it simultaneously. The first is generative AI, which has reduced the marginal cost of producing plausible-looking code to nearly zero. A contributor today can produce dozens of patches in an afternoon, none of which they understand, all of which compile. Maintainers report drowning in "slop PRs" — submissions that pass surface-level review but reveal, on closer inspection, that the contributor cannot answer basic questions about their own change.

The second is the professionalization of supply-chain attacks. The xz-utils incident in 2024 made it clear that patient, well-resourced adversaries are willing to spend years building maintainer credibility in order to ship a single backdoor. Between these two pressures — the high-volume noise floor and the high-effort targeted attack — the maintainers of widely-used packages are being squeezed from both sides at once.

The standard responses have been inadequate. Mandatory 2FA, signed commits, and Sigstore-style attestations all answer the question "is this contribution from who it claims to be from?" None of them answer the question that actually matters now: "should I trust this person to touch this code?"

This proposal sketches a different approach. Rather than treating every contributor as either trusted or untrusted, we propose a graduated trust model in which the friction a contributor faces is a function of their position in a portable, cryptographically verifiable web of trust. Contributors who are socially close to a project face minimal friction. Contributors who are distant or unknown face proof-of-work requirements substantial enough that AI cannot shortcut them. The graph itself becomes the substrate for separating signal from noise.

The core mechanic: friction proportional to social distance

Every repository or organization is a trust origin — a point in a graph from which trust radiates outward. A contributor's required proof-of-work is calculated from their shortest meaningful path to that origin through a network of signed, scoped, revocable vouches.

          hop 0  →  maintainers (trust origin)         →  no proof-of-work
hop 1  →  vouched-for contributors           →  trivial: signed commits, basic checks
hop 2  →  friend-of-friend                   →  light: keep-alive identity, single reviewer
hop 3  →  third-degree connection            →  meaningful: context proofs, observation window
hop ∞  →  unknown / no path                  →  maximum: full PoW + canary quarantine

The key insight is that the graph itself is the proof-of-work substrate. We do not need to invent new computational puzzles. Being inside the graph is the costly thing, because entry requires that someone already inside is willing to stake their own reputation to vouch for you. That stake is the proof-of-work — paid by the voucher, on the candidate's behalf, in a currency (reputation) that AI cannot generate.

This inverts the usual model. Today, the cost of submitting a contribution is paid almost entirely by maintainers, in attention. In a graduated trust model, that cost is shifted onto the contributor and their vouchers, in proportion to their distance from the project.

What "proof-of-work" means at each hop

The nature of the work should change with distance, not just the amount. The closer you are, the less you need to prove because someone has already proved it for you.

Hop 0–1: inside the trust circle. No friction beyond what exists today. Commits get reviewed and merged on the maintainer's normal cadence. The vouch has already happened; piling on additional proofs would be redundant theater.

Hop 2: friend-of-friend. Lightweight, asynchronous proofs designed to filter out throwaway accounts and obviously low-effort contributions. A signing key that has been active for a configurable period. Passing automated checks. A single reviewer acknowledgment from a hop-1-or-closer contributor.

Hop 3 and beyond: substantive proof-of-work. Now we want costly signals that AI cannot fake. Several mechanisms compose well:

_Proof of context._ Before review begins, the contributor must answer questions generated from the surrounding code's history and design documents.

_Proof of time._ The PR sits in a public observation window proportional to hop distance. AI compresses the cost of generating a patch toward zero, but it cannot compress real-world calendar time.

_Proof of corroborating review._ N independent reviewers, each at hop 2 or closer, must stake their own reputation on the change.

_Proof of prior work._ The contributor can link to merged contributions in adjacent projects.

No path: maximum friction. A contributor with no graph connection to the project faces the highest barrier — full PoW across all dimensions, plus their contribution gets quarantined behind a feature flag.

The vouching mechanism is where the security lives

A vouch is not a "like" button. It is a signed, reputation-staked attestation with three properties:

Vouches are scoped. "I vouch for Alice on cryptographic code" is not the same as "I vouch for Alice on documentation."

Vouches expire unless renewed. A vouch granted in 2018 should not still be granting hop-1 access in 2026 without renewal. This addresses dormant-account compromise.

Vouches are public, revocable, and consequential. When you vouch for someone who later turns out to be malicious, your own reputation degrades, with exponential decay by hop distance.

Hop calculation: subtleties that matter

Multiple disjoint paths. If you can only reach a project through a single intermediary, you are effectively at that intermediary's hop plus one — not your nominal distance.

Path quality weighting. Edges should be weighted by the voucher's history and current stake. This is essentially EigenTrust applied to contribution graphs.

Per-domain graphs. Your hop distance to a cryptography library should be computed over cryptography-domain vouches, not your generic social graph.

How this connects to Seed Hypermedia

Accounts and identity.

Every Seed account is rooted in an Ed25519 keypair derived from a twelve-word seed phrase. Identity is cryptographic and self-sovereign.

Contacts as the vouching primitive.

Seed already has the concept of a _contact_ — a signed record that one account publishes about another. Adding scoped attestations, expirations, and reputation weight to contacts is an extension of an existing primitive.

Capabilities for delegated trust.

Seed's capability system is even more directly suited to the proof-of-work gating layer.

Documents as the policy layer.

The friction-and-criticality policies that gate contribution are themselves content — exactly the kind of artifact Seed is designed to host.

The graph is already content-addressed.

Because everything in Seed is content-addressed and signed, the trust graph inherits properties that are difficult to retrofit onto a centralized service.

What this means in practice is that the trust graph is not a new system to design from scratch — it is a richer use of contacts, capabilities, and documents than Seed currently makes.

It also positions Seed for something larger than the OSS use case. A web of trust that proves itself on contributor reputation is the same web of trust that can carry forward to journalism, scientific peer review, community moderation, and any other domain where AI has lowered the cost of fabrication.

Open questions

Reputation calibration. How severe should the cost be for vouching for someone malicious?

Sybil resistance at the edges. What prevents a cluster of mutually-vouching fake accounts?

Privacy. A fully public graph reveals a lot about contributor relationships.

Governance of scopes. Who decides what "cryptography scope" means?

Recovery from compromise. When a high-reputation account is compromised, how does the graph recover?

Conclusion

The trust assumptions that carried open source through its first thirty years are not coming back. The right question is whether someone should be trusted to touch this code, and the right answer comes from a portable, cryptographically verifiable web of trust where contribution friction scales inversely with social distance.

---

See also:

Remodeling the web — critique of the current state of the internet and Seed Hypermedia's architectural response to the web's broken trust and collaboration patterns; the graduated trust proposal extends that remodeling thesis into concrete OSS trust mechanisms

Building Trust Without Central Authority — Seed's distributed trust model that provides the substrate for graduated trust

Web of Trust: Identities without servers — Seed Hypermedia's community documentation on decentralized, peer-to-peer web of trust; graduated trust extends this foundation into practical contribution-gating mechanisms

How to Solve Trust on the Open Web — complementary framing of the cryptographic trust challenge on the open web, proposing signed attestations as the solution

Vibe code like a PRO — the Linear→PR agent pipeline that directly motivates the slop PR problem; graduated trust provides the social-graph solution for trusting AI-augmented contributions from unknown contributors

---

Related Reading:

How I Built a Full Booking System as a Side Project — With Devin as My Engineering Partner — a live case study of the trust problem: an AI agent (Devin) autonomously ships 6+ merged PRs to a real production app in one month, demonstrating both the productivity upside of AI-augmented development and the urgent need for the graduated trust mechanisms proposed here

Notes on Community Models in Seed — Seed Hypermedia's two complementary trust models: formal communities (explicit membership, role-based permissions) and the user web of trust (informal one-way follow relationships for discovery and filtering) — the web-of-trust mechanism discussed here is the practical substrate for graduated trust

Secure Scuttlebutt — the canonical P2P protocol that uses the social graph as its infrastructure: follow/hops for replication scope, Sybil resistance through graph topology, and trust as a routing primitive — the closest existing implementation of the social-graph-distance mechanism Graduated Trust proposes

P2P Technologies — Trust and Safety — vendor-neutral knowledge base covering identity (key-based, DIDs, delegations), authorization (UCAN, macaroons, capabilities), Sybil resistance, and reputation systems — the foundational primitives a graduated trust system is built on

Strategic Notes

This document has been assessed by the Strategist agent. Key findings:

Signature idea potential: Graduated Trust is the #1 ranked idea — uniquely positioned at the intersection of AI-augmented OSS + P2P web-of-trust + graduated contribution friction. Nobody else owns this combination.

Content priority: "Graduated Trust in Practice" (using the Devin case study as narrative spine) is the top-ranked content action.

Strategic documents created:

Opportunity Backlog — ranked opportunities

Signature Ideas — high-level analysis

Content Roadmap — content creation plan

Research Roadmap — areas needing deeper investigation

_Added by Strategist agent — 2026-07-28_