How JayBase keeps agent writes safe
Agents write company data into JayBase. Here is how the store, the write path, and the history work, so agent write access stays safe.
What JayBase is
JayBase is an append-only event store. The source of truth is the history: a chain of events linked by hashes. Facts are flexible JSON. When you want the current state of an entity, you replay its events.
The store is open source, AGPL-3.0-or-later. The code is public, so you can inspect how a write is stored.
Hosted JayBase is the store plus a UI. Spaces is the store browser. Magpie and Martin are command-line tools and schemas on that same store.
How it works
- Read the current root.
- Send the event. The server records the actor, stores the payload, and advances the root.
- Send the same event again and you get the first one back. If the root has moved, read it again and write against the new root.
- To correct, retract, or approve, append another event. Named refs are checkpoints.
Details
- POST the event with expected_root, an Idempotency-Key, and the body.
- The server sets actor and role from the credential, encrypts the payload with AES-GCM, hashes the event, writes it, and advances the root.
- The same body and the same Idempotency-Key return the original event.
- A root that has moved, or a key already used for a different body, returns 409. Read the root again, re-evaluate, and write against the new root.
- One writer process serves each data volume. Many agents share that writer.
- Replay to inspect. Metadata is plaintext. Payloads are available when you ask for them.
Why that makes write access safe
- The hosted API appends. An accepted event stays in the history, with its actor and its time.
- A correction is a new event pointing at the earlier hash. The earlier event stays. A retraction or an approval works the same way.
- A retry of the same body and key returns the first event, so the fact lands once.
- On 409, another write moved the tip, or the key belonged to a different body. Reread, decide again, and append to the root that is current.
- A wrong fact from an authorized writer stays visible. A later event can correct it.
How hashing and the DAG enable this
Each event stores the hash of the event it follows, and the event is named by a hash of its own contents. The link points from the newer event back to the older one. Follow the links and you walk into the past, one way. A graph of hashes with that one-way shape is a Merkle DAG.
In JayBase each event has one parent, so the history you append is a chain. The root is the tip of that chain, and a successful write advances it.
- The event address is a SHA-256 hash over the metadata and the ciphertext.
- Change an older event and the hashes after it change with it.
- You can keep a copy of the root off the host. Compare it with the root the host is serving, and a rewritten or rolled-back tip shows up as a root that differs from the copy you kept.