Docs / Protocol

Protocol

The plain-language explanation is How PubPhys proves what and when. This page is the technical summary; the normative text is protocol/SPEC.md (version 1, frozen), published with the schemas and the verifier in the mirror repository Galitski-group/pubphys-log.

Objects

• Record (pubphys.record/2): type, content hash, files, parents, author (ORCID iD or an opaque account reference, never a name), origin, a 256-bit salt and a claimed creation time. record_hash = SHA-256 of its canonical JSON (keys sorted, strings only, equal to RFC 8785).
• Attested record (pubphys.attested/1): the record hash and how identity is attested: orcid-oidc (from phase 2), platform (seed and platform records) or none.
• Envelope (pubphys.envelope/1): the attested hash and an Ed25519 platform signature over pubphys.platform/1\n followed by it.
• Bundle (pubphys.bundle/1): one record with content, files, attested object, envelope, every OpenTimestamps proof, the inclusion proof and its checkpoint.

Transparency log

• Leaves are the canonical bytes of {envelope_hash, record_type}; tree hashing and proofs follow RFC 9162. Leaf indexes start at 0 in insertion order.
• Checkpoints are C2SP signed notes (origin pubphys.com/log/v1, size, root), signed only when the log grew: /log/checkpoint.
• Proofs: /log/proof/inclusion?leaf=&size= and /log/proof/consistency?from=&to=.
• Each checkpoint's SHA-256 is logged in Sigstore Rekor v2 (hashedrekord, signed with a separate ECDSA P-256 submission key published in the trust file) and committed with the Rekor entry to the mirror repository.
• A verifier checks a bundle's checkpoint against a witnessed checkpoint of equal or larger size from the mirror, whose digest Rekor logged (inclusion proof against a Rekor checkpoint signed by the pinned shard key). A split view is detected on comparison; independent cosignatures of PubPhys checkpoints arrive in phase 2.

Keys

• The platform signing key signs envelopes and checkpoints. Each platform key is introduced by a platform-key record: the first by the offline recovery key, later ones by the previous key or the recovery key. Revocations are platform-key-revocation records, effective from their Bitcoin anchor.
• A verifier pins the recovery key out of band and builds the key chain from the key records' bundles (kept in the mirror under keys/); the trust file (/.well-known/pubphys-trust.json) is a convenience copy. See Keys.

Records of the seed collection

The genesis key record, the import manifest (its content and the exact items.json bytes), one topic record per topic and one revision record per problem, with declared parents and the manifest among its parents. Each record page links its bundle: /records/<record hash>/bundle.json.