Built this after hitting the same gap on multiple projects: teams log critical events (admin actions, permission changes, PII access) but have no structural way to prove those records weren't altered after the fact.
Immutable storage (S3 Object Lock, WORM) are common, but it only covers tampering after the write lands. It doesn't protect against someone with DB write access, and it doesn't give a third party, e.g. an auditor, a way to verify integrity without touching your infrastructure.
My approach: hash chaining. Each event is SHA-256 hashed against its canonical payload + the hash of the previous event. Any insertion, deletion, or modification breaks all subsequent hashes. Anyone with the public API can re-verify the chain independently.
A few decisions I'm happy to discuss:
- Canonicalization before hashing: JSON isn't canonical by default. Ended up writing a strict sorted-key schema rather than fighting recursive serialization. - Per-actor chains vs. one global chain: Global is simpler to verify but creates write contention and makes auditor exports painful. Per-actor trades some global integrity for operational sanity.
- Trusted server-side timestamps anchored into the hash: If the client controls the timestamp, you can reorder events without breaking hashes.
- Periodic anchoring to a public chain: On the roadmap for the "full infra access + rewrite the whole chain" attack vector.
SDK is available (nodejs, others are coming). Integration is trivial. Free tier available without CC.
Happy to go deep on the crypto model, the canonicalization approach, or the trust assumptions.
saidnooneever•1h ago
i see now it requires npm and is JSey. In my personal oppinion this would be super valuable if it could be applied to any kind of logging. so maybe a lib in a different language or some wrappers, so i could make a rust, c or whatever application log in such a way, and chuck the logs in a log verifier that does the verification magic.
(ofc did not read all the docs so of this is actually already possible, maybe highlight it more, and ignore my comment :p)
unTamper•1h ago
The JS SDK is just the first one out the door. The verification model is language-agnostic: it's HTTP(S) + JSON at the core, so wrapping it in Rust, Python, Go etc. is straightforward. A language-agnostic spec + more SDKs is on the roadmap, but honestly feedback like this moves it up.
If you're interested in a Rust wrapper specifically, I'd love to build that with someone who'd actually use it. BTW the verification protocol is built in the SDK so it's client side, you don't have to rely on server-side verification.