1 pointby harris-0129 hours ago1 comment
  • harris-0127 hours ago
    Maker here. Some backstory and technical context:

    I come from automotive B2B operations, not software engineering. I was building a distributed communication protocol for AI agents — zero-trust, X.509 certificates, sub-millisecond message passing — basically trying to solve "how do agents talk to each other securely." Along the way I realized the protocol primitives I'd built (hash chaining, Ed25519 signing, capability tokens) were exactly what you'd need for cryptographic accountability, not just communication.

    NotaryOS is the first app built on that protocol engine. The engine handles the hard stuff — the crypto, the chain verification, the performance (178+ receipts/sec, 4.7ms P50 on a 4-vCPU droplet). NotaryOS is the developer-facing layer on top.

    Design decisions worth calling out:

    - Ed25519 over ECDSA: faster verification, smaller keys, no nonce-reuse footgun - Hash chain is per-agent, not global: no consensus overhead, offline-verifiable via SDKs - Payloads are never stored, only SHA-256 hashes: privacy-preserving by default - Counterfactual commit-reveal: agent commits a hash of its decision before the outcome is known, then reveals after the window closes. Anyone can verify the reveal matches

    The counterfactual receipt design came from working with trading systems where you need to prove a bot didn't execute when conditions were met. I deployed this and have had it running in production. I've started seeing the term "counterfactual receipts" appear in other projects recently — as far as I'm aware, NotaryOS is the first deployed system implementing them.

    Integrations for LangChain, CrewAI, AutoGen — three lines of code. Auto-receipting wrapper that instruments every public method on an agent class. Self-hosting via Docker Compose for air-gapped environments all coming soon!

    Happy to go deep on the security, the receipt spec, or the protocol engine underneath.