188 lines
8.3 KiB
Markdown
188 lines
8.3 KiB
Markdown
# 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](005-git-native-voting-system.md)) 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.
|
||
|
||
```yaml
|
||
# 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](005-git-native-voting-system.md#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](005-git-native-voting-system.md#eligibility) —
|
||
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)](005-git-native-voting-system.md). 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](005-git-native-voting-system.md#eligibility))
|
||
- **Anonymous ballot** (ring signature over voting keys — see [ADR 005 §Cryptographic foundation](005-git-native-voting-system.md#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
|