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

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

Hop calculation: subtleties that matter

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.

Why this addresses the current threat landscape

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.

The friction has to be adaptive

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.

Bootstrapping is the hard part

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.

How this connects to

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.

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 — there is no platform that can revoke it, and no central registry that needs to agree it exists. This is exactly the identity layer a contributor reputation graph requires. A Seed account is a stable, portable, cryptographically verifiable identity that can outlive any particular forge, project, or even the Seed application itself.

Contacts as the vouching primitive.

Seed already has the concept of a contact — a signed record that one account publishes about another. Contacts are directional and queryable in both directions: you can list contacts an account has created, and contacts that have been created about an account. They are revocable through tombstones, which means a "vouch" is not a permanent declaration but a current, observable state that can be withdrawn. The contact mechanism today is primitive — closer to "I follow this person" than "I stake my reputation on this person's competence in cryptography" — but the structural shape is correct. Adding scoped attestations, expirations, and reputation weight to contacts is an extension of an existing primitive rather than the invention of a new one.

Capabilities for delegated trust.

Seed's capability system is even more directly suited to the proof-of-work gating layer. A capability is an unforgeable signed token where an Issuer grants a Delegate the ability to perform some role on some resource, under specified constraints. It is, by design, similar in spirit to UCAN, SPKI/SDSI, and ZCAP-LD, but simpler and tightly scoped. The capability model is exactly the right primitive for "hop-1 contributors on this project may bypass the observation window" or "this contributor has been granted reviewer status by the maintainers of these three related projects." The friction policies described earlier in this proposal are, in effect, capability-validation rules.

Documents as the policy layer.

The friction-and-criticality policies that gate contribution — the rules that say a parser change in a high-criticality project needs three hop-2 reviewers and a 14-day window — are themselves content. They are exactly the kind of artifact Seed is designed to host: signed, versioned, forkable documents that a community curates collectively. A maintainer organization publishes its contribution policy as a Seed document; downstream consumers can read it, fork it, propose changes through Seed's existing collaboration mechanisms, and verify which version was in force at the time a contribution was merged. The policy layer is not a separate system to build. It is an application of the publishing system that already exists.

The graph is already content-addressed.

Because everything in Seed is content-addressed and signed, the trust graph inherits properties that are difficult or impossible to retrofit onto a centralized service. Historical state is auditable: you can verify what the graph looked like at any past point in time, which means a contribution merged six months ago can be evaluated against the policies and vouches that existed then, not the ones that exist now. Compromise events can be replayed and analyzed. The graph itself becomes a permanent, queryable record of trust evolution in an ecosystem.

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.

Open questions

This proposal is deliberately a sketch rather than a specification. Several questions need work before implementation:

Reputation calibration. How severe should the cost be for vouching for someone who turns out to be malicious? Too punitive and the graph stays sparse; too lenient and vouches mean nothing.
Sybil resistance at the edges. What prevents an attacker from creating a cluster of mutually-vouching fake accounts? Disjoint paths help, but the formal analysis needs work.
Privacy. A fully public graph reveals a lot about contributor relationships. Are there meaningful zero-knowledge variants, or is publicness an acceptable cost?
Governance of scopes. Who decides what "cryptography scope" means? A taxonomy that is too rigid will not adapt; one that is too flexible can be gamed.
Recovery from compromise. When a high-reputation account is compromised, how does the graph recover? Mass vouch-revocation events need to be possible without destroying legitimate trust.

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.

Conclusion

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.