TL;DR: claude-fafm-sdk 1.4.0 ships Verifiable Provenance — optional Ed25519 signatures on Soul-Packets. Integrity (CRC) and provenance (signature) stay separate. Opt-in via the [sign] extra; the base SDK and uvx claude-fafm-sdk receipt stay zero-crypto.

pip install 'claude-fafm-sdk[sign]' claude-fafm-sdk keygen --out ./keys claude-fafm-sdk seal -f soul.fafm -o soul.fafmp --sign --key ./keys/sign.pem claude-fafm-sdk verify -k ./keys/sign.pub.pem soul.fafmp # → signature OK (exit 0)

CRC answered “intact.” Provenance answers “which key.”

1.2 sealed a soul into an SPK1 packet with CRC-32 — integrity only. 1.3 made that story one command: uvx claude-fafm-sdk receipt. A stranger could prove the bytes weren’t mangled.

What CRC never claimed: which key sealed these bytes. That’s not a human identity, not a trust product, not encryption. It’s a key binding. 1.4 adds it as an optional layer on the same transport.

Signature covers the same raw payload CRC covers. Flag bit 0 = SIGNED. Trailer is a fixed 64-byte Ed25519 signature — no key_id, no embedded pubkey (later). Unsigned seals stay byte-identical to 1.2/1.3.

What's New

  • [sign] extra → cryptography — Ed25519 only when you install it. Missing extra → clean “install claude-fafm-sdk[sign]” message, never a raw ImportError.
  • Librarysign_packet / verify_packet / generate_keypair (top-level exports). PEM-only keys in 1.4-min.
  • CLIkeygen (writes sign.pem at 0600 + sign.pub.pem), seal --sign --key, verify -k.
  • Strict openfrom_packet and CLI open refuse a signed packet (point at verify). merge_packet never CRC-opens a signed peer; pass public_key or reject.
  • Receipt unchangeduvx claude-fafm-sdk receipt still GREEN, still zero-crypto.

How to run it

# provenance path (opt-in crypto): pip install 'claude-fafm-sdk[sign]==1.4.0' claude-fafm-sdk keygen --out ./keys claude-fafm-sdk seal -f soul.fafm -o signed.fafmp --sign --key ./keys/sign.pem claude-fafm-sdk verify -k ./keys/sign.pub.pem signed.fafmp
# integrity path (still zero-crypto): uvx --from 'claude-fafm-sdk==1.4.0' claude-fafm-sdk receipt # → TIER-2 RECEIPT GREEN

Honesty bounds

  • Provenance, never “trust.” A key signed these payload bytes — not a human identity, not a PKI, not “authenticated memory.”
  • Strip-downgrade is possible — drop the 64-byte trailer and clear SIGNED → equivalent unsigned packet of the same payload. The flag is not signed. Demand verify when you need provenance.
  • Old 1.2/1.3 readers reject full signed files (length-exact) — they do not silently CRC-open them.
  • SPK1FAFB — not project-binary signing, no FLAG_SIGNED interop with the FAFB format.
  • Merge oracle untouched — transport only; CvRDT dual-impl remains the 1.1 story. Deletes still don’t converge (→ Forgettable Memory / 1.5).
  • No encryption in this edition.

The Numbers

  • v1.4.0 — production on PyPI (Verifiable Provenance)
  • Optional Ed25519 — fixed 64-byte trailer, payload-aligned with CRC
  • Zero-crypto base — receipt + seal/merge/open without [sign]
  • PyPI: claude-fafm-sdk 1.4.0
  • GitHub: v1.4.0 release

The arc

Mergeable → Sendable → Provable → Verifiable → Forgettable.

  • 1.1 Mergeable Memory — souls join (CvRDT)
  • 1.2 Sendable Memory — SPK1 + CRC travel
  • 1.3 Provable Receipt — one-command stranger proof
  • 1.4 Verifiable Provenance — which key sealed it
  • 1.5 Forgettable Memory — tombstones (shipped — read the post)

Portable memory with optional provenance. Star the SDK if it earns it.

Star claude-fafm-sdk