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.

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.

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. The goal here is not to verify competence — your voucher already did that — but to verify that you are who you claim to be, and that this is not a one-shot drive-by.

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. Why does this function exist? What was the prior approach, and why was it rejected? These are questions trivial for someone who has read the code and difficult for someone who has only had a model write a patch. The maintainer does not need to write the questions manually — they can be auto-generated from git blame, design docs, and prior PR discussions, and a trusted human reviewer only adjudicates the answers.

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. A 24-hour window at hop 2 might extend to 30 days at hop ∞, with notifications to dependent projects so that downstream consumers have time to flag concerns.

Proof of corroborating review. N independent reviewers, each at hop 2 or closer, must stake their own reputation on the change. This converts review from an unpaid attention drain into a reputation-bearing act. Reviewers who consistently approve good changes accumulate reputation; reviewers who rubber-stamp something malicious lose it.

Proof of prior work. The contributor can link to merged contributions in adjacent projects. These count not as raw line counts but as weighted by those projects' trust graphs. A contributor who has accumulated standing in a related ecosystem starts closer to the origin than a true unknown.

No path: maximum friction. A contributor with no graph connection to the project faces the highest barrier — full PoW across all the above dimensions, plus their contribution gets quarantined behind a feature flag in a canary release until it accumulates positive runtime signal. This is not a permanent ban. It is a deliberately steep on-ramp for genuinely new contributors, designed to ensure that the cheapest path into a project's trust graph runs through actual relationship-building rather than account creation.

A vouch is not a "like" button. It is a signed, reputation-staked attestation with three properties that distinguish it from existing endorsement systems:

Vouches are scoped. "I vouch for Alice on cryptographic code" is not the same as "I vouch for Alice on documentation." A maintainer who is excellent at JavaScript should not accidentally extend their trust into a kernel module. Scopes can be hierarchical (language → ecosystem → project) so contributors do not need a separate vouch for every repository, but they should be narrow enough that misplaced trust is contained.

Vouches expire unless renewed. A vouch granted in 2018 should not still be granting hop-1 access in 2026 without an affirmative renewal. This addresses the dormant-account compromise scenario directly: a maintainer who stopped paying attention five years ago no longer has live trust to lose, and an attacker who takes over their account inherits an expiring asset rather than a permanent one.

Vouches are public, revocable, and consequential. When you vouch for someone who later turns out to be malicious, your own reputation degrades, and so does the reputation of everyone who vouched for you, with exponential decay by hop distance. This is the mechanism that makes the xz scenario meaningfully harder. Today, no one pays a price when they trust the wrong person; the cost is externalized onto downstream users. In this model, vouchers have skin in the game.

The reputation degradation needs to be calibrated carefully — too punitive and no one will vouch for newcomers, too lenient and the signal is meaningless. The right calibration probably looks something like: small, recoverable losses for vouching for someone who turns out to be merely incompetent; large, slow-to-recover losses for vouching for someone who ships a backdoor.

A naive shortest-path calculation is brittle. If a single compromised account can serve as a bridge that lets attackers reach hop 1 of every project, the system collapses the moment any well-connected maintainer is phished. Three refinements address this:

Multiple disjoint paths. A contributor's effective hop distance should be calculated over multiple independent paths, not just the shortest one. 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. This makes single-account compromise dramatically less valuable to attackers, because compromising one bridge node only buys access through that node, not the union of every project that node touches.

Path quality weighting. Edges should be weighted by the voucher's history and current stake, not treated as binary present/absent. A vouch from a long-standing, high-reputation maintainer should count for more than a vouch from someone who joined the graph last week. 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. A contributor with deep standing in frontend tooling does not get a free pass to touch crypto primitives. The graph is not one graph — it is a family of overlapping, scoped graphs.

Together these refinements move the model from "shortest path" to something closer to "weighted, scoped, multi-path reputation flow." This is harder to compute and harder to game.

The reason to take this approach seriously is that it pushes back on each of the major attack vectors simultaneously, in ways that single-mechanism solutions do not.

AI slop PRs stop being a maintainer-attention problem because they cannot accumulate vouches. No one with reputation will stake on a stranger spamming patches. Slop submissions sit at hop ∞ permanently, hit maximum friction, and never reach the front of the maintainer's queue. The signal-to-noise ratio at the review surface improves dramatically without maintainers having to manually triage.

xz-style long games become harder, though not impossible. The attacker still has to build credibility, but they now have to build graph position — collecting vouches from people whose reputations are on the line. Every vouch they accumulate is a person who will lose standing when the attack surfaces. This creates natural detection incentives that do not exist today: vouchers have reason to monitor the people they vouched for, because their own reputation depends on it. The attack does not become impossible, but it becomes louder, slower, and more expensive.

Maintainer takeovers become explicit graph events rather than quiet commit-bit grants. A handoff is a signed, visible vouch transfer. The community can observe "this project's trust origin just shifted toward someone whose strongest connections are in an unrelated ecosystem" and apply scrutiny in proportion. Compromised accounts that attempt to grant themselves elevated trust trigger anomaly signals in the graph — sudden changes in vouching patterns from a long-stable account are themselves a detection vector.

None of these are bulletproof. A determined, well-resourced attacker who builds a clean identity over many years and earns genuine vouches can still ship a backdoor. The goal is not to eliminate the threat — it is to raise the cost floor enough that opportunistic attacks become uneconomical and patient attacks leave more traces.

Open source's defining superpower has always been frictionlessness. A 14-year-old in any country with internet access can land a patch in a project that ships to billions of devices. That has to remain true for low-risk contributions to low-criticality projects, or we will have replaced one problem with a worse one.

The right system is therefore adaptive. Friction scales with two independent variables: contributor distance (how far you are from the trust origin) and contribution criticality (how dangerous the change is if it turns out to be malicious).

Criticality signals already exist in the ecosystem. The OpenSSF Criticality Score, dependency-graph centrality, and the security-sensitivity of the touched code paths (cryptographic primitives, authentication, parsers, build scripts) all provide inputs. A typo fix in a project's README from an unknown contributor should still be near-frictionless. A change to a parser in a library that ships in every Linux distribution should require substantial proof-of-work even from hop-2 contributors.

The dial that needs to exist is contribution-friction-as-a-function-of-(distance, criticality). Most of the inputs to that dial already exist. What is missing is the wiring.

The graph is most valuable when it is dense and least useful when it is empty. Early adopters face all the friction with none of the network effects. This is the place where the proposal is most vulnerable, and worth being honest about.

A few mechanisms can ease the bootstrap:

Seed from existing signals. Long-running PGP webs of trust, Sigstore identities, OpenSSF Scorecards, and high-history GitHub accounts all carry information that maps imperfectly but usefully onto initial graph positions. A new participant should not start from absolute zero; their existing reputation should import as a prior, decaying over time as they accumulate native vouches.

Start with high-criticality projects. The friction model is most valuable, and the network-effects bootstrapping problem least painful, in projects where contributors are already willing to accept significant friction. Cryptographic libraries, kernel components, and widely-depended-on infrastructure are natural starting points. The model can spread outward from there as the graph densifies.

Make the graph useful even before universal adoption. If the graph provides value as a signal — a maintainer can see "this contributor has hop 3 to this project, here are their cross-project vouches" — even before it is enforced as a gate, adoption can be incremental. Maintainers can use it to allocate attention before they use it to allocate access.

The reason this proposal lives at the intersection of open source security and decentralized hypermedia is that the trust graph cannot live on any single platform. GitHub, GitLab, Codeberg, sourcehut, and self-hosted forges all need to read and write the same graph. A maintainer's reputation should not evaporate when they migrate projects between hosts. A contributor's standing in one ecosystem should be cryptographically verifiable from another.

This places a specific set of demands on the substrate. The graph must be portable across forges and platforms, with no single point of authority that can revoke or censor. Vouches must be cryptographically verifiable signed claims, not platform-specific endorsements that disappear when the platform changes its policies. The graph must be decentralized at the protocol level, even though communities can and should curate their own subgraphs. And it must be composable across projects — the same vouching primitive should work whether you are gating a kernel patch or a documentation fix.

This is unusually well-aligned with what Seed Hypermedia already provides. Seed is not a generic document store onto which a social graph would need to be retrofitted. The primitives this proposal requires are, for the most part, already in the system — currently used for publishing, collaboration, and account discovery, but structurally suited to a much more ambitious application.

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. The primitives are already there. The work is in extending contacts with the missing properties (scope, expiration, reputation weight), defining the policy schema as a Seed document type, and building the hop-distance calculation as a pure function over the existing graph.

The concrete proposal for the Seed team is to treat OSS contributor reputation as a high-leverage application of the existing platform — one that is genuinely needed by a community already in crisis, and that exercises every primitive Seed has built. A minimum viable version looks like an extension of contacts to support scoped, expiring, weight-bearing attestations; a Seed document schema for project contribution policies; a reference implementation of multi-path hop-distance over the contact graph; and an integration with at least one forge (a GitHub Action and a Forgejo plugin would cover most of the ecosystem) that surfaces hop distance and friction recommendations in the PR review interface. None of this requires forges to adopt the gating model on day one — it provides value as a signal first, and as an enforcement layer later.

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 the cost of false trust has risen sharply because AI has lowered the cost of fabrication. OSS is the most acute current need, but it is not the only one. Building this primitive well, on the substrate Seed already provides, lays groundwork that other communities will need shortly.

These are real questions, but none of them strike me as fundamentally blocking. They are the kind of questions that get answered by building the thing, not by debating it further in the abstract.

The trust assumptions that carried open source through its first thirty years are not coming back. AI has eliminated the cost of producing plausible code, and well-resourced adversaries have demonstrated patience that neither maintainers nor existing tooling are equipped to detect. The response cannot be more 2FA, more signing, or more attestations of the same identities we already had — those answer the wrong question.

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. Close contributors keep working at full velocity. Distant contributors face proof-of-work that AI cannot shortcut. Vouchers carry the cost of their own endorsements, creating the detection incentives that today are absent.

This is a substantial project, but most of the primitives already exist. What is missing is the wiring, and a substrate willing to host the graph without trying to own it. Both are within reach.