BitGraph Domain

A BitGraph Domain is a company's own domain publishing the keys that record for it: one file, at one fixed address. A reader pins the domain once. From then on, anything the company delivers can be checked against it, offline: the file in hand holds a recorded position, and a key the domain published stands behind that recording.

Email made this move twenty years ago: domains publish their signing keys, and receivers check what arrives. Files never got the same statement. This is that statement, and it is the company speaking for itself, not BitGraph speaking about the company: a proof carries a key and nothing else, and whether to pin a domain belongs to each reader. There is no list to join and no one to ask.

Publish yours

Serve one JSON file over HTTPS at a fixed address on your domain:

{
  "version": "bitgraph-domain/1",
  "domain": "acme.com",
  "party": "Acme Corp",
  "keys": {
    "invoices": { "alg": "es256",   "publicKey": "<SPKI DER, base64>" },
    "press":    { "alg": "ed25519", "publicKey": "<raw 32 bytes, base64>" }
  }
}

keys follows the trusted-key grammar of the Player spec, so an entry pastes into a rule's trustedKeys unchanged. For es256, the public key is SPKI DER in base64: the spelling every actor proof already carries, so the entry can be copied out of any proof the key has made. The names are yours; readers see them beside your domain. The file states one thing: these keys record for this domain. It is your letterhead, made checkable. Removing a key withdraws the statement for future pins; it rewrites nothing already recorded.

Record under yours

The file names actor keys. Recording does not change: one touch at bitgraph.ing/actor, or the direct envelope from a server. The domain adds nothing to the proof; it lets a stranger resolve the key a proof already carries to the domain that published it.

Pin one

bitgraph-play pin acme.com

The player fetches the domain's file, shows the party and each key's fingerprint, and stores what you confirm, on your machine. A fingerprint is the SHA-256 of the key itself; for es256 keys it is exactly the keyId actor proofs carry, derived from the key material and never assigned, so a domain cannot claim a key it does not show. Pinning is the only step that touches the network. Pin again whenever you like: the player shows what changed before you accept it. The pin is your record; it never leaves your machine.

Check against one

bitgraph-play check "BitGraph (invoice-4471.pdf)/" --from acme.com

One line joins the report for each recording:

  TRUE   domain       actor key "invoices" · published by acme.com (Acme Corp)
  UNDET  domain       no evidence binds this recording to acme.com

TRUE. The file in hand hashes to the recorded digest, the recording verifies, and a key acme.com published stands behind it, either as the actor inside the proof or as a detached signature in the bundle. Nothing further to do.

UNDETERMINED. The evidence in hand does not establish the connection. The file may be fine; nothing here says so. Ask the sender for the recording, or verify another way before relying on the file.

FALSE never comes from the domain line. It comes from the recording itself, when evidence in hand contradicts it: an edited signature, a block header that does not hash to its anchor. Do not rely on the file.

What it establishes

That a key published by the domain stands behind a recording of exactly these bytes, at a fixed causal position. Not authorship: anyone can record a file they downloaded, under any key they hold. Not content: a recorded invoice can still be wrong. Not exclusivity: the same bytes may hold other positions, under other keys or none. And the statement is only as strong as the domain and the keys behind it: a stolen key keeps the domain's standing until it is removed and readers pin again.

What changes is the default: a delivered file either arrives with the company's recording standing behind it, or it visibly arrives without it.

The cost

A domain's file names a key in public. From that moment, every recording the key has ever made or will make reads as the party's: the ledger is public, positions and volume included, and a pin, once stored, outlives the file that provided it. Publishing is retroactive, and it does not meaningfully un-publish. What it never exposes is content: only digests travel, so attributing a specific file still requires holding its bytes.

The discipline is the one paper letterhead imposes: not every pen in the building writes on it. Publish keys you dedicate to what you intend to stand behind, named for their purpose, and record everything else as always: anonymously from home or the Folder, or under keys the file does not name. An anonymous recording's company is every recording ever made; nothing about a domain changes that.

In a rule

A domain's file is also evidence for rules: its entries paste into a format 2 rule's trustedKeys, and the signedBy claim verifies detached signatures under the same keys. The command and the rule language read the same statement; the Player page has the rest.