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 “installclaude-fafm-sdk[sign]” message, never a rawImportError.- Library —
sign_packet/verify_packet/generate_keypair(top-level exports). PEM-only keys in 1.4-min. - CLI —
keygen(writessign.pemat 0600 +sign.pub.pem),seal --sign --key,verify -k. - Strict open —
from_packetand CLIopenrefuse a signed packet (point atverify).merge_packetnever CRC-opens a signed peer; passpublic_keyor reject. - Receipt unchanged —
uvx claude-fafm-sdk receiptstill 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 GREENHonesty 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.
SPK1≠FAFB— not project-binary signing, noFLAG_SIGNEDinterop 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