DEV Community: ternentdotdev

Your app doesn’t need a database. Here’s what it needs instead.

ternentdotdev — Mon, 30 Mar 2026 12:47:29 +0000

I've been building web apps for a while, and they all end up looking the same.

User does something → we update a database → we serve the latest state back.

It works. It scales. Everyone does it this way.

But it also means the database is the truth. And when the database is the truth, you have to trust whoever owns it — including yourself.

I’ve had moments where that broke down. Not catastrophically — but enough to realise we had no way to prove what actually happened.

State mutates. Logs drift. Backups lie.

So I started exploring a different shape.

The result is Concord — an app runtime where state is never stored. It's derived from a signed, portable history.

Think of it like this:

Imagine a todo app where the file proves nobody has tampered with it — and you can email it to someone and they can verify it instantly.

Instead of the app owning your state, you own a file that contains a signed history — and the app just projects from it.

Your data is just a file. You decide where it lives.

The core idea

Most apps store current state. Concord doesn't.

Every action is appended to a history as an event. Current state is whatever you get when you replay those events from the beginning. There's nothing to mutate — just a log of what happened, and a runtime that reconstructs the present from it.

This is called event sourcing.

But Concord takes it further — the history isn’t hidden inside a backend. It’s portable, signed, and self-verifying.

The insight is that history is more durable than state. You can always re-derive state from history. You can't go the other way.

const app = await createConcordApp({
  identity,
  storage,
  plugins: [createTodoPlugin()],
});

await app.load();

await app.command("todo.create-item", {
  id: crypto.randomUUID(),
  title: "\"Buy milk\","
});

await app.command("todo.complete-item", { id: "..." });

await app.commit({ metadata: { message: "morning tasks" } });

const todos = app.getReplayState("todo");

Commands stage entries locally. commit() seals them into history as a signed block.

If you've used git, this will feel familiar.

Replay is deterministic.

The ledger is just a file

Not a database you connect to. A file you can open.

The history — the ledger — is plain JSON.

{
  "commits": [
    {
      "commitId": "...",
      "author": "did:key:abc123...",
      "parentHash": "...",
      "proof": "...",
      "entries": []
    }
  ]
}

It can live anywhere. A Solid Pod. Google Drive. Dropbox. IPFS. A USB stick.

You can email it. You can AirDrop it.

The runtime doesn't care — storage is an adapter you plug in, not something the library owns.

const app = await createConcordApp({
  identity,
  storage: solidPodAdapter,
  plugins: [],
});

No storage backend? The ledger still works.

Export it. Move it. Load it somewhere else.

Tamper-evidence is not optional

Every entry is signed. Every commit is chained.

Change any committed byte — and verification fails.

The runtime refuses to derive state from corrupted history.

const verification = await app.verify();

If the ledger is invalid, the app won’t proceed.

Identity is a mnemonic phrase

Your identity is derived from a mnemonic phrase.

If you’ve used a hardware wallet before, it’s the same recovery model — just applied to application identity instead of money.

No account. No server. No reset flow.

Lose the phrase and the identity is gone. Keep it safe and you can regenerate everything.

Encryption is first-class

Every entry payload has an explicit type: plain, encrypted, or decrypted.

Encryption is part of the write path.

Permission groups manage access. Each group has a symmetric key.

Granting access is just wrapping that key for another user — no re-encryption required.

The same ledger can be shared with multiple people. Each sees only what they can decrypt.

What this enables

A password vault where the data is a file you hold
A task manager with a full audit history
A shared document with signed, attributed changes
Multi-party workflows without a central authority

Where it's at

Open source. Available now.

Runtime: https://npmjs.com/package/@ternent/concord
Ledger: https://npmjs.com/package/@ternent/ledger
Signing: https://npmjs.com/package/@ternent/seal-cli
Encryption: https://npmjs.com/package/@ternent/armour

Most apps ask you to trust their database.

Concord asks you to trust the history — and verify it yourself.

Would you ever build an app like this — or is this solving a problem you don’t have?

Designing a portable proof format for signing files in JavaScript

ternentdotdev — Tue, 17 Mar 2026 16:21:12 +0000

I recently needed a consistent way to sign content across environments - specifically in both Node and the browser.

Most existing approaches either rely on shelling out to system binaries or are tightly coupled to a particular runtime. I wanted something:

JS-native
Deterministic
Portable
With a clear, versioned proof format

So I ended up designing a small proof primitive and extracting it into its own tool.

The idea

Given:

A file
Some text
Or a directory

The tool:

Produces a deterministic representation
Signs it locally
Emits a versioned JSON proof

That proof can be published alongside the content and verified later. It’s self-contained and runtime-agnostic.

For directories, a stable manifest is generated first, so the proof reflects the structure and contents deterministically.

Why JSON?

The proof format is intentionally plain JSON.

That makes it:

Inspectable
Easy to store
Easy to transport
Easy to verify across environments

The same proof format is used in:

A CLI
A GitHub Action
A JavaScript library

So the representation doesn’t change depending on where it’s generated.

What this isn’t

It’s not trying to replace existing signing ecosystems.

It’s just a minimal, consistent proof format that works natively in JavaScript across environments.

If this sounds useful, it’s here:

👉 https://seal.ternent.dev/

JSON compression in the browser, with gzip and the Compression Streams API.

ternentdotdev — Sun, 19 Mar 2023 23:40:14 +0000

EDIT: ~~... just not yet in Firefox~~

Introduction

When building web apps, we sometimes find ourselves with a need to persist large JSON objects. Either directly to the browser using Web Storage, or externally through the File or Fetch APIs.

This problem lead me to ask the question: Is there a better solution to storing raw or encoded JSON? Can we achieve some level of compression?

As it turns out, the answer is Yes and it's surprisingly simple with the Compression Streams API.

This example was created for the specific needs of Web Storage, File and Solid Pod persistence, for a scaling representation of JSON application state.

Background

To set the scene a little, the project I am working on doesn't communicate with a server. Application data is structured transactionally in a Merkle Tree (git, blockchain). The tree structure naturally grows with each interaction with the application and along with it, its memory and storage footprint.

To keep an eye on this growth, I built a small indicator in the control bar to visualise the size. I found as the JSON object grew, the data started to reach an extent I wasn't completely comfortable with, so I decided to take a look and see if I could do better.

This brought me to the Compression Streams API. A browser API that enables gzip compression on a ReadableStream, directly in the browser.

TL;DR After enabling gzip compression on my JSON data, I saw a size reduction of 98%, from 943kb to 10kb.

This wasn't a scientific test and the data didn't scale how it would organically in the app, but it serves as a fair benchmark that I will get the results I want from this API.

Solution

As the Compression Streams API is part of the Streams API, we first need to transform our JSON data object to a ReadableStream.

A Blob can be constructed from text, and JSON can be serialized to text, so to start we can create a Blob from our JSON and get our stream from there.

// Convert JSON to Stream
const stream = new Blob([JSON.stringify(data)], {
    type: 'application/json',
}).stream();

Now we have our ReadableStream, we can use the ReadableStream.pipeThrough method to pipe our data through the gzip CompressionStream transform.

// gzip stream
const compressedReadableStream = stream.pipeThrough(
    new CompressionStream("gzip")
);

Then to get this compressed stream back to our main code, we can create a new Response and handle the data like any other we would receive from the Fetch API.

// create Response
const compressedResponse = 
  await new Response(compressedReadableStream);

So what can we do with this data now it's compressed?

Well, quite a lot actually.

We could base64 encode it to a string and then store it in localStorage.

// Get response Blob
const blob = await compressedResponsed.blob();
// Get the ArrayBuffer
const buffer = await blob.arrayBuffer();

// convert ArrayBuffer to base64 encoded string
const compressedBase64 = btoa(
  String.fromCharCode(
    ...new Uint8Array(buffer)
  )
);

// Set in localStorage
localStorage.setItem('compressedData', compressedBase64);

We could save it as a File.

// Get response Blob
const blob = await compressedResponse.blob();

// Create a programmatic download link
const elem = window.document.createElement("a");
elem.href = window.URL.createObjectURL(blob);
elem.download = '';
document.body.appendChild(elem);
elem.click();
document.body.removeChild(elem);

Or we could take more traditional approach, sending through HTTPS and the Fetch API.

// Get response Blob
const blob = await compressedResponse.blob();

await fetch(url, {
  method: 'POST',
  body: blob,
  headers: {
    'Content-Encoding': 'gzip',
  }
});

And I'm sure there are many other techniques that can be used with our newly compressed JSON object.

Pretty cool, right? But how do we get our data back into a readable form in the browser?

To decompress, we first want to get our compressed data back into a ReadableStream.

Either directly from our Blob (or file/fetch Response)

const stream = compressedResponse.blob().stream();

Or decode back from base64.

// base64 encoding to Blob
const stream = new Blob([b64decode(compressedBase64)], {
  type: "application/json",
}).stream();

Edit: The b64 decode function I'm using looks like this.

export function b64decode(str: string): ArrayBuffer {
  const binary_string = window.atob(str);
  const len = binary_string.length;
  const bytes = new Uint8Array(new ArrayBuffer(len));
  for (let i = 0; i < len; i++) {
    bytes[i] = binary_string.charCodeAt(i);
  }
  return bytes;
}

Then again, this time with our compressed ReadableStream, we go back through the ReadableStream.pipeThrough method, piping our data through the gzip DecompressionStream.

const compressedReadableStream = stream.pipeThrough(
  new DecompressionStream("gzip")
);

We then go back into a Response, take the Blob and call the Blob.text() method to get the content back in string format.

  const resp = await new Response(compressedReadableStream);
  const blob = await resp.blob();

All to do now is parse this string back to JSON and we have our decompressed object, back in Javascript and ready to use.

const data = JSON.parse(await blob.text());

Demo and Results

I've put together a small CodeSandbox that takes a few online JSON sources and runs them through the gzip CompressionStream transform described in the solution above.

Oh, and yes. ❤️ VueJS.

Conclusion

Firstly, I had a blast writing this piece and exploring the Compression Streams API. It's simple to use and feels like a really nice addition to the Javascript ecosystem.

In terms of how useful the API itself is, it has solved a real problem for me in being able to reduce my persistent data footprint.

I have already built this into a small feature in my app, but I do plan to integrate it deeper and bake it into the core functionality soon. Which should be another interesting problem to solve as the app has integrated client-side encryption using Age (rage (rage-wasm)). But that's for another day...

It's a little disappointing that this API isn't fully supported yet, at only 72.53% support coverage, according to CanIUse. But I still think it's very worthwhile. We can implement this to fail gracefully where the Compression Streams API is not supported and forgo the performance boost, so that's not a deal breaker for me.

I'm not sure how often the Compression Streams API will be a tool I reach for, but I'm glad to have learnt it and I'm sure this won't be the last time I use it, or at the very least consider it.