8.3 KiB
ADR 006 — Cross-platform identity via human attestation
Date: 2026-05-11 Status: Proposed
Context
The agency scoring system aggregates contribution activity across multiple platforms. To produce a meaningful score for a contributor, the system must know which accounts across those platforms belong to the same person. Without this, contributions are fragmented, scores are incomplete, and the multi-platform eligibility requirement for voting (see ADR 005) cannot be enforced.
This is the identity correlation problem: proving that alice on GitHub is the same
person as alice on the forum and alice on the wiki, without requiring real-world
identity disclosure or centralised identity infrastructure.
Decision
Cross-platform identity is established through human attestation — community members explicitly vouch for account links they are personally confident about.
Each contributor maintains a profile file in docs/contributors/. Other contributors
attest to the account links they can personally verify. A sufficient number of attestations
from eligible community members constitutes a verified identity link.
Why other approaches were rejected
Username matching (assume same username = same person)
Simple but brittle. People use different usernames across platforms, capitalisation varies,
and username squatting is possible — someone could register alice on a platform before
Alice does. More fundamentally, it is unverified: the system has no basis for the assumption
beyond coincidence. Rejected as a primary mechanism; acceptable as a suggested default
that contributors can confirm or override via their profile file.
Cryptographic proofs (Keybase-style) Technically elegant: the contributor posts a signed proof from each platform account pointing to their canonical voting key. Anyone can verify the proof independently. But this approach requires the scoring system to fetch and verify proofs from each platform's API — a running service, not a static file. It also assumes platforms allow freeform posts suitable for embedding a proof (funding platforms, for instance, often do not). The infrastructure dependency cuts against the fork-friendly, git-native design. Rejected as the primary mechanism; not precluded as a supplementary signal.
OAuth / SSO Requires a centralised identity provider and assumes all platforms support the same auth mechanism. Neither is true for this community's platform mix. Rejected.
On-chain identity (DIDs, verifiable credentials) Technically sound but introduces wallet management, gas costs, and blockchain dependencies that are inaccessible to most communities. Reserved as a future direction.
How it works
Contributor profile file
Each contributor creates and maintains a file at docs/contributors/{username}.md.
The platforms listed under accounts mirror the platforms defined in config.yaml
for the community — each fork's contributor profiles reflect its own platform mix.
# Example from the OSArch reference implementation
voting_key: abc123...
accounts:
github: alice
forum: alice
wiki: alice
matrix: @alice:matrix.org
opencollective: alice
attestations:
- attester: bob
attests: [github, forum, wiki]
date: 2026-01-15
- attester: carol
attests: [github, matrix]
date: 2026-01-18
The contributor commits their own profile file using their git identity. Attestations are committed by the attester — not the subject — using the attester's own git credentials. This means attestations are permanently on record under the attester's name.
What an attestation means
An attester is asserting:
"Through my direct experience collaborating with this person across these platforms, I am personally confident these accounts belong to the same individual."
This does not require meeting in person. It may be based on years of collaboration, observed cross-references the person has made publicly, or direct confirmation in a shared communication channel. The attester judges their own confidence level.
Attestations are a reputational stake. Attesting for a sockpuppet or fake account is permanently on record and directly damages the attester's own credibility in the community. This creates a real incentive to attest only when genuinely confident.
Verification tiers
Different confidence levels unlock different system functions:
| Level | Condition | Unlocks |
|---|---|---|
| Unverified | Self-declared only | Contributions counted toward score |
| Likely | 1–2 attestations from any contributor | Cross-platform score aggregation |
| Verified | 3+ attestations from eligible voters | Voting eligibility |
New contributors are not penalized for being unverified — their work counts toward their score from day one. Verification gates the higher-trust functions only.
Revocation
An attester can withdraw an attestation at any time by committing a removal to the profile file. The git history preserves the full record: when the attestation was made and when it was withdrawn. Score and eligibility recalculate accordingly.
If an account is suspected to be compromised or fraudulent, any community member can
open a challenge — a file in a designated docs/contributors/challenges/ directory —
triggering a community review. Challenged links are suspended pending resolution.
The bootstrap problem
The first contributors have no attestors yet — no one has verified credentials in the system. This requires a founding contributor set: a small group whose identity links are accepted at genesis without formal attestation, because the community already has high confidence in them through years of prior collaboration.
This set is committed to the repo as a named, dated file at genesis. It is explicitly political — someone decides who is in it. It should be as small as practically necessary and include a clear note that it represents a bootstrap, not a permanent special status.
Sybil resistance — honest assessment
Human attestation addresses the most common multi-identity scenario: one person maintaining multiple accounts where the community doesn't know they're the same person. Attestation makes this visible — community members notice when two accounts are suspiciously similar or when someone is vouching for accounts that seem related.
It does not fully prevent a highly coordinated attack where real community members knowingly attest for fake identities. This is a social attack, not a technical one, and the defence is also social: the permanent record of attestations creates accountability, and community members lose credibility by vouching for fraudulent accounts.
In combination with the multi-platform eligibility requirement from ADR 005 — which requires sustained activity across multiple platforms to vote — the cost of maintaining multiple fully-attested, multi-platform eligible identities becomes very high. This deters all but the most motivated bad actors.
Relationship to the voting key
The voting key registered in the contributor profile serves as the cryptographic anchor for the voting system (ADR 005). The attestation system establishes that a set of platform accounts belongs to the holder of that key. Together they connect:
- What you've done (contributions across platforms, verified by attestation)
- Who can vote (eligibility derived from verified multi-platform activity — see ADR 005 §Eligibility)
- Anonymous ballot (ring signature over voting keys — see ADR 005 §Cryptographic foundation)
The two systems are separable — attestation provides value for scoring independent of whether ring-signature voting is implemented.
Consequences
- Cross-platform score aggregation becomes reliable without infrastructure dependency
- The identity layer ships with the repo — every fork inherits the contributor registry
- New communities bootstrapping the system can start with a founding set and grow attestation coverage organically as the community establishes itself
- The system formalises knowledge the community already has — who is who — rather than requiring new verification infrastructure to produce it