Hello. This is a quick post to introduce osbytes, an open source organization I co-own with Dillon Streator.

We are using it as a home for some of the libraries and products we have built while solving real problems in our own work. Some of it came directly out of Copia Cash, which I co-founded with Dillon.

TL;DR

Osbytes is a GitHub org I run with my buddy Dillon Streator. We are parking a bunch of our open source there for visibility.

This post introduces three projects (txob, Epoch Flow, crypt.fyi) and how Copia Cash, leans on txob and Epoch Flow in production. I will write a longer Copia Cash intro in its own blog later.

txob

I will give a light overview of txob. Dillon would probably be able to give a much better overview since he was the original author of the library and knows the business use case better than I do.

txob is a small library built around the transactional outbox idea for PostgreSQL (and MongoDB). You record “something happened” in the database in the same transaction as your real data change. Then a separate processor reads those rows and runs your handlers.

That means side effects like API calls, email, and webhooks happen after the commit. You also get at-least-once delivery, retries and backoff, near-real-time wakeups so you are not only slow-polling, graceful shutdown, and room to scale processing horizontally.

If I had to say it in one breath, it is the plumbing between “we saved the truth in Postgres” and “now do the slow or flaky stuff reliably.”

How Copia Cash uses it

At Copia Cash, the API runs txob’s EventProcessor against Postgres. It uses the txob/pg integration, including a wakeup path so new outbox rows get picked up quickly.

We wire typed handlers for things like receipt upload to OCR and matching, transaction sync follow-ups, and user lifecycle flows like waitlist, signup, and subscription. Those are the kinds of jobs that should not block the HTTP request or run outside the same transactional story as the domain write.

The pattern in the app is straightforward. Inside one DB transaction we update core tables and insert an outbox event. The payload comes from shared event types. txob then processes those rows, retries recoverable failures, and supports marking some errors as unprocessable so you do not retry forever.

Observability is hooked in via a Sentry-backed telemetry adapter on the processor, and shutdown paths call processor.stop() so work can drain cleanly.

Copia Cash uses txob to keep writes consistent with async, reliable follow-up work. That matters a lot in personal finance flows where reliability beats doing everything inline in the request.

Epoch Flow

Epoch Flow is a small, headless library for multi-step flows. Picture a wizard or onboarding flow, not a full form framework replacement.

You define one Zod schema and split it into steps. Only the fields on the current step are validated when someone clicks Next. Navigation is explicit, with next, back, and go to step actions, plus guards so people cannot skip ahead when it would not make sense.

It is built to sit next to tools you already use, Zod for shapes, optional tRPC for a typed final submit, and your own UI. There are no baked-in components or styling.

A notable piece for real onboarding UX is draft persistence. Answers can be debounced to storage, for example browser localStorage, so a refresh or a short interruption does not wipe progress. The core is a tiny state machine plus store. React gets hooks and a provider, so the whole thing stays lightweight.

How Copia Cash uses it (onboarding)

In Copia Cash, first-run onboarding is a guided sequence for goals, linking institutions, and preferences instead of one overwhelming form. Epoch Flow orchestrates that experience.

Each screen is a step with step-scoped validation, so people get immediate feedback without validating fields they have not reached yet. Draft saving means someone can leave mid-flow and come back without starting over, which matters for flows that include redirects like bank linking.

Behind the scenes, the same Zod-typed payload can be submitted through our tRPC API when they finish, so the client and server agree on the shape end to end. Styling and layout stay 100% Copia. Epoch Flow only handles flow state, persistence, and navigation. That is the glue that is tedious to reinvent but should not dictate how the product looks.

crypt.fyi

crypt.fyi (repo) is a secure secret-sharing stack. It is a way to send passwords, API keys, recovery codes, or small files without trusting the server with the plaintext. Encryption happens in the browser (or via the official client libraries). The service mainly stores encrypted blobs and enough metadata to enforce your rules. It never gets your raw secret or decryption key.

Design-wise it is zero-knowledge. The backend never sees unencrypted content or the keys needed to decrypt it.

Cryptography uses ML-KEM for post-quantum-oriented protection, paired with a tight security posture. That includes strict CSP, rate limiting, and careful handling of “burn” semantics so links do not get destroyed by bots prefetching URLs.

What you get as a user (or integrator)

You create a secret, set policies like time-to-live, burn after read, optional password, read limits, or IP allow-lists, then share a link. Recipients decrypt on their side. Optional webhooks can notify you when something was read, failed, or burned.

The project ships as an API, web app, CLI (@crypt.fyi/cli), Chrome extension, Docker images, and a @crypt.fyi/core package for talking to the API from TypeScript.

Across all of those you get the same story. Crypto stays on the client, sharing stays explicit, secrets default to ephemeral, and the server stays something you barely have to trust.

One line for a package roundup

crypt.fyi is our answer to “Slack/email is not a vault.” Ephemeral, zero-knowledge, strongly encrypted secret sharing, built so your data is not our data, end of story.

Wrapping up

That is the quick version of osbytes. The goal is to make the work easier to find, share more of what we are building, and hopefully give people useful pieces they can use in their own projects.

There are a few more projects coming that we already use in Copia Cash. I will write about those as they get cleaned up and moved over.