add: NIP-80 hardware-attested media provenance

[PrarthanaPurohit]

This NIP defines events for media provenance anchored in capture hardware: a camera signs each photo at the moment it's taken, and the proof is published to relays keyed by the content itself, so verification survives metadata stripping, re-hosting, and platform takedowns. Re-encoded copies are handled through derivation attestations rather than fuzzy matching.

The motivation is journalists and human rights defenders documenting events in places where "that's AI-generated" is the default dismissal. C2PA exists, but it embeds manifests in file metadata that every major platform strips on upload, and its trust model runs through certificate authorities and expensive proprietary cameras. This puts the proof out-of-band on relays and lets every verifier pick their own trust roots. There are no authorities anywhere in the design.

To be upfront about scope, since it's the first thing everyone asks: an attestation proves capture provenance—this exact image came from this device at roughly this time, unmodified or modified only in declared, provable ways. It does not prove the scene was real. A trusted camera pointed at a screen will faithfully attest a photo of that screen. The specification explicitly forbids clients from collapsing results into a bare "authentic" badge.

New event kinds

(Checked against the README table, registry-of-kinds, and nostrdata/kinds. Happy to renumber if I missed an existing allocation, including the NIP number.)

• 1080 — Capture Attestation
• 1081 — Derivation Attestation (resize, crop, recompress, redact; reveal mode or ZK)
• 1082 — Revocation (regular event; permanent, author-scoped, monotonic)
• 11080 — Device Announcement
• 31080 — Device Endorsement
• 31081 — Device Set for Anonymous Attestations (experimental; could be split into a companion NIP)

Existing NIPs reused

• NIP-94 (x tag semantics)
• NIP-92 (imeta)
• NIP-65 (revocation discovery)
• Blossom (media storage)
• NIP-03 (optional timestamp anchoring)

Status

This specification grew out of building the camera first and then realizing the event format itself needed standardization.

I have a working prototype, OpenVeilCam, a Rust camera runtime for Raspberry Pi using an ATECC608 secure element:

https://github.com/PrarthanaPurohit/OpenVeilCam

I'm currently updating it to publish these event kinds, along with a standalone verifier. The px1 reference decoder and test vectors will also live in that repository. The specification intentionally makes a canonicalization identifier unusable until its reference implementation and test vectors are published, so nothing depends on trusting my implementation.

Feedback I'd especially appreciate

• Does the two-key design make sense? The proposal uses a BIP-340 device key together with an ECDSA hardware key, since no mainstream secure element currently produces BIP-340 signatures. For example, Microchip's ATECC608 (the ~$1 part used in the reference build) supports only P-256, NXP SE050 supports secp256k1 but only with ECDSA, TPM 2.0 modules and Infineon OPTIGA Trust M likewise support P-256/RSA, and phone secure enclaves (Apple Secure Enclave and Android StrongBox) are also P-256. This lets dedicated hardware and phones share the same trust model.
• Are there any weaknesses or edge cases in the pinned-reference-decoder canonicalization approach?