Design discussion distilled from our Product Hunt launch thread with Abdullah Javaid (@abdullahjavaid409), whose framing this issue mostly transcribes. Related but distinct from #31 (evidence portability): this one is about WHO the evidence belongs to.
Today
Attribution is by author email: the scan counts only commits authored by the identities you claim, and claimed emails are corroborated against verified account emails server-side. Signatures are read as anchors (the bundle ships signed count, ratio, and key types) but they are not the attribution primitive. A misconfigured user.email (a real case from the thread: months of commits carrying a colleague's address) inherits git's wrong answer, and possession of the repo cannot fix it, because possession is not identity (anyone who clones a repo possesses it).
Forward: keys as the primitive
An email is a string anyone can set in one config line. A signature is possession of a key. For repos where signing is on, attribute by key and treat the author field as a hint: the misattribution class disappears going forward. The key still needs to be verified as yours (same corroboration architecture, stronger primitive).
Backward: countersignatures, and why the asymmetry is the security
For history that is already wrong, self-issued retro-claims fail because the claimant gains by lying. A countersignature from the address that owns the commits, scoped to a commit range rather than to a person, works because the attester LOSES by lying: they are giving away credit they could have kept. Attestation is only sound when it costs the person making it.
The known holes, and their answers from the thread
- Collusion (credit trading between accounts) is not fixable at the attestation layer. It shows up as a graph shape: two accounts attesting mostly each other. Detect it after the fact via reciprocity ratio; pricing friction into each attestation only taxes honest pairs who really work together.
- Key rotation is the retro problem one level up. The usual answer is a continuity chain: a new key signs a statement adopting the old one, and history transfers without re-signing anything. Lost keys stay lost, which is right: a claim nobody can prove should decay.
Open questions
- Key verification depends on a registry (platform-verified keys). What does the CLI ship versus what does the server judge?
- Does any of this earn new bundle fields? If so, the full data-boundary process applies (prior discussion, schema bump, docs, privacy tests).
- What is the minimal v1? Key-preferred attribution where signatures exist, with email fallback, might be most of the value with a fraction of the machinery.
- Where do reciprocity-ratio checks live? (Server-side by nature; noted here because the signals they consume would come from bundles.)
Credit where due: the keys-as-primitive framing, the attester-loses asymmetry, the reciprocity-graph answer to collusion, the continuity chains, and the decay principle all come from @abdullahjavaid409's comments in the launch thread.
Design discussion distilled from our Product Hunt launch thread with Abdullah Javaid (@abdullahjavaid409), whose framing this issue mostly transcribes. Related but distinct from #31 (evidence portability): this one is about WHO the evidence belongs to.
Today
Attribution is by author email: the scan counts only commits authored by the identities you claim, and claimed emails are corroborated against verified account emails server-side. Signatures are read as anchors (the bundle ships signed count, ratio, and key types) but they are not the attribution primitive. A misconfigured user.email (a real case from the thread: months of commits carrying a colleague's address) inherits git's wrong answer, and possession of the repo cannot fix it, because possession is not identity (anyone who clones a repo possesses it).
Forward: keys as the primitive
An email is a string anyone can set in one config line. A signature is possession of a key. For repos where signing is on, attribute by key and treat the author field as a hint: the misattribution class disappears going forward. The key still needs to be verified as yours (same corroboration architecture, stronger primitive).
Backward: countersignatures, and why the asymmetry is the security
For history that is already wrong, self-issued retro-claims fail because the claimant gains by lying. A countersignature from the address that owns the commits, scoped to a commit range rather than to a person, works because the attester LOSES by lying: they are giving away credit they could have kept. Attestation is only sound when it costs the person making it.
The known holes, and their answers from the thread
Open questions
Credit where due: the keys-as-primitive framing, the attester-loses asymmetry, the reciprocity-graph answer to collusion, the continuity chains, and the decay principle all come from @abdullahjavaid409's comments in the launch thread.