Real-timealpha

Real-time Collaborative Editor

An exploration of CRDTs and operational transforms for building Google Docs-style collaborative editing experiences. I wanted to understand the offline story end to end, not just the happy multiplayer path. This prototype runs on Y.js with a tiny WebSocket relay, persists everything to IndexedDB on the client, and reconciles edits when you come back online. The interesting work is in the seams: presence, undo, and how you tell a user that their last 12 minutes of typing just collided with someone else's.

Y.jsWebSocketReactIndexedDB

What this is

A lab, not a product.

An exploration of CRDTs and operational transforms for building Google Docs-style collaborative editing experiences. I wanted to understand the offline story end to end, not just the happy multiplayer path. This prototype runs on Y.js with a tiny WebSocket relay, persists everything to IndexedDB on the client, and reconciles edits when you come back online. The interesting work is in the seams: presence, undo, and how you tell a user that their last 12 minutes of typing just collided with someone else's.

5

Features

4

Learnings

4

Technologies

Capabilities

What it does

The features that actually got built and run in this prototype.

feature_01.ts
Conflict-free concurrent editing using Y.js documents as the source of truth
feature_02.ts
Offline-first storage in IndexedDB with a sync queue, pairs with the local-first sync lab
feature_03.ts
Cursor presence indicators with stable colour assignment per user across reloads
feature_04.ts
Version history and time travel built on Y.js snapshots, not a separate audit log
feature_05.ts
Rich text and block support with selection-preserving remote updates

The stack

What it is built with

The libraries and runtimes I picked for this lab and why they earned their place.

Y.js
WebSocket
React
IndexedDB

What I learned

Learnings, in order of how much they surprised me

The things I would tell another engineer before they tried the same experiment.

01
Y.js gives you excellent CRDT primitives but you still own the state management around them. Treat it like a database, not a magic box
02
WebSocket reconnection strategies are the actual product. Most of my real time bugs were here, covered in the real-time blueprint
03
Offline sync conflicts need UX patterns, not just merge algorithms. Users need to see what happened
04
Undo across a multiplayer session is a hard problem and the right answer is usually scoped per-user undo stacks, not document-wide

Note: This is an experimental project in the alpha stage. It is a learning exercise and technical exploration rather than a production-ready solution. Patterns and code may change.

Real-time

Related labs

Other explorations in this area.

experimental

Local-First Sync Engine

A sync engine for local-first applications. The client owns a SQLite database in the browser (via WASM), every write goes there first, and a small server reconciles edits across clients. I built this to understand whether the local-first promise (offline, instant, multiplayer, but still synced) is actually achievable for everyday CRUD apps in 2026. Short answer: yes, but conflict resolution is still where the design work lives.

Want me to build something like this for you?

If this kind of work fits your roadmap, I take on a small number of paid projects each quarter.

Start a projectJust say hello
Previous

AI Code Review Assistant

Next

Edge ML Inference