DEV Community: Esteban Fuster Pozzi

A Private Messenger With No Server Anywhere: What One P2P Graph Database Can Carry

Esteban Fuster Pozzi — Tue, 22 Sep 2026 12:34:46 +0000

Every peer-to-peer database has a chat demo. It is the hello world of the genre: two browsers, a shared key, messages appearing on both screens, and the promise that this is what a world without servers looks like. Then you try to add identity, groups, a way to throw someone out, messages that expire — and the demo quietly acquires a server.

I wanted to know what happens if you refuse. dMessenger is a full private messenger — identity with a recovery phrase and passkeys, one-to-one conversations and groups with a roster, replies and reactions, message lifetimes, attachments and voice notes, invites by link or QR, an installable app that opens with no network — built on one GenosDB graph and nothing underneath. No relays holding messages. No server anywhere in the data path. And a test suite that proves every one of those claims in real browsers, over real WebRTC, before I was allowed to write them down.

Try it: estebanrfp.github.io/dMessenger — open it in two windows, or on two devices. Source: github.com/estebanrfp/dMessenger, MIT.

Where do the messages go when there is no server?

Into the graph — the same one every peer holds. A GenosDB database is named, and everyone who opens that name replicates it, peer to peer, with every operation signed by its author and verified by whoever receives it. There is exactly one database instance in dMessenger, for everything. That was the first design decision and the most important one, so it is worth saying why.

The obvious alternative — a database per conversation — works, and I measured it working: three instances in one page, three graphs, no bleed. But a second instance in the same page re-initialises the Security Manager and drops the active signer, which you can watch happen as an address that turns null mid-session. One graph, and everything separated inside it, along three axes that never touch each other:

axis	mechanism	what it separates
kind	`value.t` + one `db.map` query per view	conversations, messages, identities, keys, vouches
ownership	`value.owner`, id `${owner}:…`	who may write, link or delete a node — checked by every peer
confidentiality	an encrypted record + `acls.grant`	who may read, enforced by an envelope rather than by topology

The queries are the routing. The conversation list is a subscription to { t: 'conv', members: { $in: [me] } }; the open thread is a subscription to { t: 'msg', conv: id }, sorted by the engine. No store, no router, no array to keep in step with the screen. If you have read about how peer-to-peer databases differ, this is the part that only works when the database already syncs and already sorts.

End-to-end encryption without a key server

A private conversation is two nodes with different jobs. A public one, reactive, says who takes part and where the key lives — metadata every peer sees anyway. An encrypted record (db.sm.put) holds the key itself, and it reaches each member through acls.grant: one envelope per reader, wrapped for that reader's published key. Read control is cryptographic. The room replicates every byte of it to everyone, and only the members can open it — which is a test, not a claim: the suite adds a third peer, proves it is replicating the ciphertext, and then proves it cannot read it.

Each message is an ordinary public node whose body is ciphertext under that key. Public on purpose: it keeps realtime, ordering and pagination working, which an encrypted query cannot offer, while the content stays sealed. A reaction is a node too, ${reactor}:react:${messageId}, which does three jobs at once — reacting again replaces the earlier one, removing it is a remove only its owner can sign, and nobody can react in your name, because the id carries the owner the gate enforces. Forged one in the suite; it landed in the forger's copy and nowhere else.

Groups add the part that key servers usually do for you: removal. Take someone off the roster and two incompatible things must happen — they stop reading what comes next, without destroying what came before for everyone who stayed. So the key record holds an array of keys, one per epoch, and every message carries the epoch it was sealed under. revoke takes the envelope and rotates the record; a fresh key is appended for whoever still holds one.

Here it is live, in Bob's window, thirty seconds after he was removed:

What he read while he was in is still on his screen — no rotation takes that back, and any design that claims otherwise is lying. What came after is ciphertext for a key he cannot reach. Nobody asked his client to cooperate.

I should be precise about what this is not. Envelope encryption with a rotated key gives forward-only access control, not the per-message forward secrecy or post-compromise security of a double ratchet. It is honest, it is cheap — 19 µs to seal a kilobyte — and it is what the primitives give you without a server; the security audit is where the engine's own guarantees are written down.

Is a Nostr relay a server?

GenosDB introduces peers over Nostr relays and then moves the data over WebRTC. The question is fair, and the only honest answer is an experiment you can kill. The performance suite starts a relay it controls, lets two peers meet through it, kills it with SIGKILL, checks the port is closed — and sends twenty more messages. Twenty of twenty arrive, p50 45 ms. A public relay could not have been killed, and with a list of several, killing one would prove nothing. During 150 messages neither peer makes a single HTTP request; the bytes on the busiest ICE candidate pair say where the data went.

So: a relay is the phone book. The post goes by hand. That is also why the app scales the way the cellular mesh does rather than the way a chat server does — the room is a community, not a public network of strangers, and I say so in the README.

Roles nobody can grant themselves

A new identity is a guest. It can write — the base role writes, links and deletes on purpose, and ownership already scopes deleting to your own nodes, so the residual risk is spam, never takeover. What it cannot do is become anything else. Roles are set by a superadmin's signed decision, or by governance rules the engine evaluates every four seconds, last match wins:

{ if: { role: 'guest' }, offsetTimestamp: 8000, then: { assignRole: 'user' } },
{ if: { role: { $in: ['user', 'manager'] } }, then: { assignRole: 'user' } },
{ if: { role: { $in: ['user', 'manager'] }, vouches: { $gte: 2 } }, then: { assignRole: 'manager' } },

The first rule keys on time the engine itself observed, the one metric a modified client cannot forge. The third keys on vouches, which live on a node its subject may rewrite — self-service by design, which the guide is explicit about — so the tier it grants is deliberately weak: manager may publish, never delete. And publish is what creating a group costs. That is the whole ladder made real: a user cannot create a group; two signed vouches later, a manager can.

The demo ships the engine's canonical demo identities, so you can watch it without trusting me. Open two windows, press 🛡️ Superadmin in one — its window runs the engine — and 👩‍🦰 Alice in the other:

	when
Alice arrives as `guest`	0 s
the two windows see each other, over public relays	4 s
rule 1 makes her `user`, signed in the Superadmin's window	18 s
Superadmin and Bob vouch; she publishes her count	18 s
rule 3 makes her `manager`; New group lights up; she creates one; Bob sees it	22–23 s

Alice's own window says waiting for a superadmin window the whole time. She never ran the engine. Her role changed anyway, because another peer signed the decision and every peer accepted it. If you know role-based access control from the server side, this is the same vocabulary with the enforcement moved to every receiver.

What broke, and what it taught me

The engine did not break once. My constitution did, twice, and both times the test suite caught it before a user would have.

The manager that kept losing his job. The first group test promoted Alice to manager with a superadmin's signed decision. It passed — then failed a minute later with the button saying you are user. The governance rules govern the manager tier, so the floor rule overwrote the manual assignment on the next cycle. Documented behaviour: a rule decides over a term. Either keep standing rules to the tiers below the ones you assign by hand, or earn the tier the way the rule describes. The suite now earns it.

The guest who couldn't take it back. A guest retracting a reaction had its remove refused by every other peer — remove costs delete, which I had put above the floor. Since ownership already limits deleting to your own nodes, moving delete down was safe, and the ladder became honest: the base role can speak and take back what it said.

Deleting is not disappearing. Message lifetimes were the hardest feature, for a reason that has nothing to do with UI. In this engine a tombstone lives only in the operation window; a peer that held the message, went away, and comes back after the tombstone rolled out will bring the node back through its full state. So expiry cannot be "delete on expiry". It is a property of the receiver, enforced at three points that do not trust each other: no honest peer paints an expired message; a db.use middleware drops one at the door on every sync path — including a laggard's full state, which arrives as one operation carrying every node and gets filtered node by node; and the author removes its own as housekeeping. The suite shrinks the window to three operations, lets a returning device bring the node back, sends a sentinel to prove it is connected, and asserts nothing expired exists. Live, a 20-second message left both screens 20.5 s after it was sent, and both graphs held zero nodes.

The numbers

Measured by the second suite, pnpm perf, against the application — DOM included — in real Chromium over real WebRTC:

what	result
cold start, engine from the CDN, until the identity door is on screen	640 ms
warm start	226 ms
identity: key pair, mnemonic, volatile session	97 ms
peer discovery, relay introduction + ICE	~4 s
key exchange: conversation opened, envelope granted and delivered	125 ms
delivery latency, 50 messages one by one	p50 95 · p95 117 ms
burst of 100, until all are on the other peer	242 ms total, 2 ms per message
HTTP requests by either peer during 150 messages	0
relay killed after the introduction	20/20 delivered, p50 45 ms
catch-up after a partition, 30 messages missed	420 ms from page load
AES-GCM seal / open, 1 KB	19 µs / 19 µs

Latency is read the honest way: the sender stamps before sealing, the receiver stamps inside the same db.map callback the UI paints from, on one machine whose clock both share. That one measurement also fixed a bug — puts take 0 ms, so bursts shared a millisecond and were ordered by random id. Stamps are strictly increasing per session now.

From seven lines to a messenger

The engine's own realtime chat in seven lines is where this started, and if you have seen GunDB's chat examples, you have seen the same hello world. dMessenger is what that demo turns into when identity, ownership, key distribution, governance and lifetimes are the database's job rather than an afterthought bolted on with a server. It is about 3,100 lines of vanilla JavaScript, three runtime dependencies (identicons, QR generation, QR scanning), and the engine from a pinned CDN URL. Nothing is bundled underneath it.

It is also the third app in a series that keeps asking the same question — a code editor with no server came before it — and the first where the answer had to include cryptography that other people's messages depend on.

What it is not

Not interoperable with anything. Identities are GenosDB addresses; no federation, no bridge.
Not a double ratchet. Forward-only access control, as above.
Not a public network. A room replicates to everyone in it; the scope of a database is a community.
No push notifications. With no server, nothing wakes a closed page — the one thing a serverless design cannot offer.
Attachments are capped at 512 KB, because the room replicates every byte to every peer. Larger files belong on an ephemeral channel, not in the graph.

Try it, clone it

git clone https://github.com/estebanrfp/dMessenger && cd dMessenger
pnpm install && pnpm exec playwright install chromium
pnpm test    # 19 specs, real browsers, real WebRTC, a fresh room per test
pnpm perf    # the numbers above, on your machine
pnpm dev     # http://localhost:5605

Or skip all that: open the demo in two windows, press two buttons, and watch a role change that no client decided.

There Is No Server to Audit — GenosDB's Security Audit, and What It Confirmed

Esteban Fuster Pozzi — Sun, 20 Sep 2026 01:59:39 +0000

When you audit a normal database application, the first thing you do is ask where the server is. That is where authorization lives: one process, one place that decides who may read and who may write, one boundary to push against. Find a way past it and you have a finding.

GenosDB has no server. Every peer holds the whole graph, every peer may run modified code, and the relays that carry the traffic are assumed hostile. There is no single place where permission is granted, because permission is not granted anywhere — it is verified, independently, by every device that receives an operation.

So what do you audit? That question is more interesting than it sounds, and answering it is what the latest release came out of.

What a Finding Even Means Without a Server

In a client-server system, the threat model is implicit: the server is honest, the client is not. In GenosDB it has to be stated, because nothing is implicit. It is written down in SECURITY.md, and it is blunt:

Any peer may run modified code, and the network — relays, superpeers, other peers — is hostile. A peer decides on its own copy only; every other peer verifies what it receives and applies nothing it cannot verify.

Read that as an auditor and the target becomes clear. You are not looking for a way past a gate. You are looking for one thing:

Can a peer make another peer apply, accept or reveal something outside its authority?

That is the whole question. Not "can I send a bad operation" — of course you can, you control your own client. The question is whether the receiver applies it. A modified peer that writes nonsense into its own copy has achieved nothing; it has lied to itself. A modified peer that makes an honest peer store a role it never granted, or open a record it was never given the key to, has found something real.

This also means a whole class of "vulnerabilities" evaporates on contact. A room opened without the Security Manager has no gate, by design — anyone may write, and that is the documented behaviour of a public room, not a defect. Discipline about that distinction is most of what separates a useful audit from a long list of things that were never promised.

Closed Source, Open Protocol — and Why That Makes It Auditable

The engine ships minified. That usually ends the conversation with an auditor.

It does not here, because what the engine does is fully specified. CRYPTOGRAPHY.md describes identity derivation, what exactly is signed and in what canonical form, how signatures are verified and authorization decided, ordering and replay, the encrypted-record envelopes, passkeys, signaling and transport, and what is written to disk. Its last section is a list of commands anyone can run against the published bundle to confirm the code matches the document.

And there is a second layer that matters more than the first: the conformance vectors. They are 98 checks re-derived from the specification alone — WebCrypto for HKDF and AES-GCM, @noble/curves for secp256k1, @noble/hashes for keccak-256, msgpack and zlib. No GenosDB code runs in the verifier. If the spec and the bundle ever disagree, the vectors say so without anyone having to take my word for it:

npm pack genosdb@latest && tar xzf genosdb-*.tgz
node tests/vectors/verify.mjs --dist package/dist

A meta.json pins the SHA-256 of the exact dist/ files the vectors were produced beside, so the bundle you hold can be bound to the numbers you are checking. That is the difference between "trust the source" and "check the artifact".

How the Run Was Organized

The audit was run as a structured campaign under Cloudflare's security-audit skill, with a discipline I would keep regardless of the tooling:

Coverage first. Twenty-two units, each one a triple of surface × trust boundary × attack class, so the run could say what it had looked at and, just as importantly, what it had not.
Hunting and verification are different jobs. Every candidate was handed to a verifier that had not found it, and no verdict was accepted without a working reproduction — not an argument, a harness that runs.
Every refusal was re-read. A candidate that was dismissed went to a second verifier who was not shown the first conclusion. If a rejection was a misreading, this is what catches it.
Black box in parallel. A separate matrix of 46 cases, built with a different toolchain and no access to the sources, attacked the published bundles from a hostile browser over real WebRTC — a second graph, a second origin, its own storage.

The thing I would emphasise to anyone auditing a P2P system: run the negative controls. "The data appeared on the other peer" proves nothing on its own — it may have arrived through shared storage rather than the network, and a refusal may be a disconnection rather than a decision. Every negative case in that matrix carried a legitimate witness operation that had to arrive by the same path, so a silent failure could never be mistaken for a rejection.

What Held

Forty of the 46 black-box cases held, against an attacker that controlled its own packets and its own identity: unsigned operations on all four sync paths; tampering with content, id, identity, address, timestamp and signature; guest writes, deletes and links; self-escalation to admin and superadmin; role claims planted in a first profile; demotion; replay of old promotions; ACL nodes without a grant and with a forged owner; a clock run forward; a bounded corpus of invalid signatures; a revoked reader trying to read what came after.

Twelve of the 22 coverage units closed with nothing to report — both authorship gates against a modified peer, catch-up and ordering, persistence and cross-tab copies, envelope cryptography and passkey custody, transport framing and the cellular overlay, signaling and the embedded relay, the release chain.

The Best Result Was a Design That Answered for Itself

My favourite moment of the whole run was a candidate the design answered on its own.

It looked clean. assignRole(address, role, expiresAt) grants a role until a date. Let the date pass, and a standing governance rule promotes that identity straight back to a permanent role. Written as a bug report, it reads like a serious one: an expiry that does not stick.

Except an expiry in GenosDB is not a countdown some engine owns. It is a term inside a signed decision, and every peer enforces it locally: past the date, that identity is a guest on every device, with nobody connected and no engine running anywhere. And the project's own decision log says what an expiry promises — it is final until the constitution decides again. A governance rule is the constitution deciding: the engine signs with a superadmin's key or it does not sign at all.

The verifier proved the other side of it empirically instead of arguing. It took the engine's own operation and signed it with the subject's key: refused by the gate. With a key from outside the constitution: refused. Only an address the clients themselves list as a superadmin can produce that effect — so no lower-trust peer can cause it or benefit from it.

Then it did the thing I did not expect: it ran the fix the candidate proposed. Applied to the full documented rule ladder, the expired node reads guest, matches the onboarding rule, and gets promoted to a permanent role anyway. Carry the term forward instead, and two cycles after it lapses you are back at a permanent role — which is precisely the renewal loop that an earlier release removed rule-level expiry to eliminate, more than a year of releases ago.

An audit rediscovered, from scratch and without being told, why a design decision existed. That is what a written decision log buys you, and it is worth more to me than a report with nothing in it.

What the candidate left behind is one sentence in the governance guide, stating the term in so many words: a rule decides over a term.

What the Release Strengthened

The release that followed strengthened four guarantees, each pinned by a test that fails without it:

The gate judges what a value carries as well as who signed it. On a node with an owner, a write by anyone but the owner carries the owner's policy unchanged — owner, collaborators and the envelope table — so a collaborator writes content, never policy, and a revoke holds against any later write from an older copy. Three lines of code, in the browser gate and its mirror in the Fallback Server.
A governance time objective is the engine's own observation, measured from when it first saw a node's current stamp — never the age of a stamp a peer signed for itself.
The priority path belongs to the constitution. A subject's write of its own role node never carries it.
Six demos render a peer's value as text, which is the rule the examples themselves state: no server sits between the writer and the reader.

The full report — method, what held, each item the release closed and how, and what this run explicitly did not cover — is published in docs/audits. The conformance suite came out of it larger than it went in: 84 tests in real browsers over real WebRTC, up from 76, and 107 gate verdicts, up from 87.

Audits Have a Home Now

Published audits live in docs/audits: one row and one report per run, with date, reviewer, scope and result. The README points there once and does not change again for an audit.

If you review GenosDB — as a researcher, a security team, or an organization evaluating it — I will list your report there, findings and all. The specification is public, the bundle is hashable, and the vectors run without a line of GenosDB code. Nothing about this arrangement requires you to believe me.

A Note on Where This Comes From

I have spent years building browser P2P databases — I wrote the official GUN documentation platform and contributed to that codebase before starting GenosDB. The reason this engine has a decision log, an invariant list and a battery that runs in real browsers over real WebRTC is that I have been on the other side of every one of those absences.

An audit of a serverless system is not a search for the hole in the wall. There is no wall. There are only receivers, each deciding alone, each having to be right without help. Testing that is harder than testing a server, and it is also the only way to find out whether "zero trust" is an architecture or a slogan.

⭐ Found this useful? Star GenosDB on GitHub — or spin it up in seconds: npm i genosdb.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

SQLite WASM vs GenosDB: Real Benchmarks on a 200k-Relation Dataset

Esteban Fuster Pozzi — Mon, 14 Sep 2026 17:41:28 +0000

Most people meet GenosDB through its P2P side: real-time sync, WebRTC rooms, decentralized apps without a backend. This post is about the other side, the one almost nobody asks about — GenosDB as a plain local-first store, no P2P involved. And instead of a synthetic benchmark, the numbers come from a real app, with a real dataset, against a real incumbent: SQLite compiled to WASM.

TL;DR — on a dataset of 9,783 geo-tagged stops, 4,359 routes and 208,229 relations, GenosDB returned byte-identical results on every query while being 5–100× faster, cut first-visit data transfer 25×, removed over a megabyte of WASM engine and worker code from the bundle, and eliminated the COOP/COEP header requirement entirely.

The app

The app is a community bus tracker for a large city, built on a public GTFS feed. Riders inside a bus become live GPS "feeders" over GenosDB's WebRTC data channels; everyone else watches buses move on a Leaflet map. It is exactly the kind of serverless, community-run product GenosDB was designed for, and it already used GenosDB for the networking side.

But it carried a second stack alongside. The static GTFS index — every stop, every route, and which routes serve which stops — lived in SQLite via sqlocal, shipped as a prebuilt 12.5 MB binary that every new visitor downloaded and copied into OPFS.

Which raised an obvious question: if GenosDB is already in the app for networking, can it also be the local database? We built a working branch to find out. The app itself is not mine to name, so what follows is the engineering, not the case study: the dataset is a public GTFS feed and every number below can be reproduced against one.

The swap

The refactor touched exactly two files of app logic (db/client.ts, db/queries.ts) plus the build script. No UI component changed. The four query functions kept their exact signatures.

The storage instance is local-only — note what's not in the options:

const { gdb } = await import('genosdb')

const db = await gdb('gtfs-index')  // no rtc — storage only

No rtc means no signaling, no peers, no sync: just a graph store persisted to OPFS through GenosDB's worker, with spatial queries available out of the box. The P2P instance (rtc: true) lives separately in the connection layer — static reference data has no business syncing between peers.

Instead of a 12.5 MB SQLite binary, the app now ships a 2.2 MB gtfs.json (~500 KB gzipped) and seeds the store on first visit:

await db.put({
  type: 'stop',
  sid: id,
  name,
  location: { latitude, longitude },  // indexed for spatial queries
  routeIds                            // the join table, denormalized
}, `stop-${id}`)

And the app's hottest query — "which stops are near the user?" — became a geo query:

const { results } = await db.map({
  query: {
    type: 'stop',  // top-level fields AND together
    location: { $near: { latitude, longitude, radius: 1 } }  // radius in km
  }
})

Choosing the model: measure, don't guess

The GTFS join table (208k stop↔route pairs) could be modeled two ways: as graph links (db.link(), one edge per pair) or as denormalized id arrays on the nodes. We benchmarked both at full scale before committing:

	links (208k edges)	arrays
Seed time	~4.2 s	~300 ms
Warm open	142 ms	136 ms
Lookup queries	0–11 ms	0–0.2 ms

Links work fine — 52k links/s sustained is nothing to apologize for — but for this access pattern (fetch a known node, follow its relations) arrays win on every axis, so arrays it is. The graph-y model would have been the showcase choice; the arrays are the engineering choice. Ship the engineering choice.

The numbers

Everything below was measured on the real dataset — 9,783 stops, 4,359 routes, 208,229 relations — on an M-series MacBook running Chromium, with the same inputs against both engines and results sorted and diffed. All four queries returned byte-identical results.

Query latency:

query	sqlocal (SQLite WASM)	GenosDB	speedup
closest stops (1 km radius)	29.7 ms	6.1 ms	~5×
routes for a stop (143 rows)	15.0 ms	0.2 ms	~75×
stops for a route (73 rows)	11.4 ms	0.1 ms	~100×
route search	2.7 ms	0.1 ms	~27×

Ingestion and startup:

phase	time
put 9,783 geo-tagged stops	171 ms (~57k ops/s)
put 4,359 routes	86 ms
total first-visit seed	~300 ms
warm open, return visits (14k nodes from OPFS)	~140 ms

Footprint:

	before	after
First-visit data download	12.5 MB	~500 KB gzipped
WASM in the bundle	860 KB engine + 209 KB worker	none
`dist/` total	19 MB	8.3 MB
COOP/COEP headers	required	not needed

That last row deserves a sentence. SQLite WASM needs SharedArrayBuffer, which needs cross-origin isolation headers on every deploy — the app's own docs flagged them as "breaking change if missing." GenosDB persists through OPFS from a worker without any of that. Deleting netlify.toml from the repo was the single most satisfying part of the diff.

Not just microbenchmarks

Query parity is necessary but not sufficient, so we also ran the entire product on the branch: mocked GPS in a dense downtown area, two separate browser origins — one as a live GPS feeder, one as a watcher. Stop discovery, route search, joining the P2P room, feeder broadcast, cross-origin feeder discovery ("1 bus ~75m" in the route list), and the blue bus marker moving on the watcher's map over real WebRTC with Nostr signaling. The watcher origin seeded its store from scratch along the way.

We also served the production build (not just the dev server) and re-ran the flow — worth calling out because bundling a library that resolves its own modules dynamically is exactly where builds tend to break. Vite inlines GenosDB's geo module into the main chunk, and every geo query works identically in the bundled app: same 29 stops, clean console.

Data model, methodology and verification steps were documented alongside the branch, and every measurement above came from the same machine, the same dataset and the same browser, with both engines' outputs sorted and diffed.

When should you reach for this?

The pattern generalizes to any app with a chunky, mostly-static reference dataset: product catalogs, map data, dictionaries, game content. The recipe:

Ship the dataset as gzipped JSON (a build script, not a database binary)
gdb('my-store') — add rtc only if the data should sync
Seed once behind your loading screen; version it with a meta node
Query with $near for spatial data, db.get for known ids, db.map for everything else

One library, one mental model — and if some of your data should be shared later, the P2P layer is one option away.

The production builds of GenosDB are free for personal and commercial use; the source is proprietary by deliberate governance choice. Install it with npm i genosdb — github.com/estebanrfp/gdb.

Originally published at genosdb.com/sqlite-wasm.

⭐ Found this useful? Star GenosDB on GitHub — or spin it up in seconds: npm i genosdb.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

PouchDB vs GenosDB: Offline-First Is Not the Same as Serverless

Esteban Fuster Pozzi — Mon, 14 Sep 2026 17:28:50 +0000

PouchDB is the reason a lot of us believed offline-first was practical at all. It landed in 2012 with a simple, powerful idea: run a database in the browser that speaks the CouchDB replication protocol, and let the two reconcile themselves. That protocol is genuinely excellent — fifteen years of adversarial use, revision trees, deterministic conflict handling — and PouchDB implements it faithfully.

It is also, and this is the whole point of this article, a client. PouchDB syncs with something. That something is CouchDB or Cloudant, and it is a server you operate and pay for.

If your architecture already includes that server, PouchDB is a fine answer and nothing here should talk you out of it. If you picked PouchDB because you wanted offline-first without a backend, the rest of this is worth reading.

Offline-First Is Not Serverless

The distinction gets blurred constantly, so it is worth stating plainly: an app can work offline and still require infrastructure. PouchDB gives you the first without giving you the second.

Ask any AI search engine today for peer-to-peer browser databases and watch PouchDB get excluded by name, with the reason spelled out: it requires a central server such as CouchDB for replication, so it is not truly P2P. That is not a criticism of PouchDB — it is a description of what it is.

PouchDB                          GenosDB

Browser ──► IndexedDB            Browser ──► Security Manager (signs)
   │                                │
   └──► replication protocol        └──► Graph Store (OPFS)
            │                              │
            ▼                              ├──► Peers (WebRTC)
     CouchDB / Cloudant                    │
     (your server, your bill)              └──► Nostr relays (discovery only)

Two peers running PouchDB cannot sync with each other. They sync with the same server, and the server makes them agree. Remove it and you have two isolated local databases.

GenosDB has no such component. Peers exchange signed operations directly over WebRTC, discovery runs through the public Nostr relay network — infrastructure that already exists and never sees your data — and authority comes from the signature on each operation rather than from a machine everyone trusts.

Where the Project Is Today

PouchDB was donated to the Apache Software Foundation and is now Apache PouchDB (incubating). Their own DISCLAIMER file states it:

"Apache PouchDB (incubating) is an effort undergoing incubation at the Apache Software Foundation (…) While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF."

This is good news, and I want to be clear about that. Moving under the ASF is how a project outlives its original maintainers — governance, trademark, succession. It is exactly the institutional durability that a single-maintainer project like GenosDB does not have, and if that matters to your organisation it is a real argument in PouchDB's favour.

What it also means is a transition period, and the release cadence shows it:

npm latest:  9.0.0  —  published June 2024
recent commits: "ASFify README.md and link to DISCLAIMER"
                "add ASF dropdown to main nav"
                dependency bumps
open issues: 189

Over two years on the same release, with recent activity concentrated on the incubation process rather than on features. Reasonable for a project in transition — just worth knowing before you build on it.

What the Open Issues Say

"IndexedDB adapter can break when opened in multiple tabs" — open since October 2020, 33 comments. The most-discussed open issue in the repository. Open your app in two tabs and the adapter can break.

This one is worth dwelling on, because multi-tab is not an edge case — it is Tuesday. Users open a second tab. In GenosDB, cross-tab coordination is part of the design: tabs share state through BroadcastChannel while the graph lives in OPFS, so a second tab is just another local reader of the same replica.

"Duplicate attachments for doc update (& putAttachment)" — open since December 2014, 23 comments. Twelve years.

"PouchDB in Next.js throws error" — open since September 2023, 16 comments. Modern bundler and SSR friction.

"PouchDB Adapter Memory is broken on Jest 27.x" — open since October 2021, 15 comments. Testing against the memory adapter breaks on a five-year-old Jest release.

"pouchdb-find: $or with multiple $regex and nested fields" — open since July 2022, 9 comments. The query layer has gaps at the edges.

The Weight, and the Bill

pouchdb    5,397 KB unpacked    14 direct dependencies
genosdb    2,007 KB unpacked     0 dependencies

But the dependency that matters is not in package.json. It is CouchDB — a JVM-era server you deploy, secure, back up and scale — or Cloudant, where you rent it by the hour. Every user you add is a row in someone's bill.

GenosDB's operating cost is structurally zero. There is no server in the data path, so there is nothing that grows with your user count. Peer discovery rides public Nostr relays; if you prefer your own, GenosSIG runs an ephemeral relay on Cloudflare's free tier. Neither is a database you operate.

What Replaces the Server

If the server was doing real work, something has to take over. In GenosDB that something is cryptography.

Identity and permissions live in the client. The Security Manager provides WebAuthn-based identity and signs every operation with the author's key. Role-based access control — guest, user, manager, admin, superadmin — plus per-node ACLs and rule-based governance. A peer that receives an unauthorised operation rejects it because the signature does not check out, not because a server refused it.

Conflicts resolve without revision trees. Hybrid Logical Clocks give causal ordering without trusting device clocks, with a deterministic tie order. When two peers write the same value at once, the writer whose operation lost re-applies its edit over the winner as an ordinary signed write, so neither contribution disappears — and no application code has to resolve a conflict document.

Sync sends deltas. A device rejoining a 210-item space pulls 7.9 KB; the same reconciliation without deltas costs 83 KB. That is the Hybrid Delta Protocol.

Queries are reactive. $eq $ne $gt $gte $lt $lte $in $between $exists $startsWith $endsWith $contains $text $like $regex $not $and $or $edge $near, with cursor pagination and $edge for recursive graph traversal. Pass a callback and the query re-fires as peers write.

The Same App, Both Ways

A list that persists locally and syncs between users.

PouchDB:

import PouchDB from 'pouchdb'

const db = new PouchDB('notes')
const remote = new PouchDB('https://user:pass@couch.example.com/notes')

db.sync(remote, { live: true, retry: true })
  .on('change', () => render())
  .on('error', console.error)

await db.put({ _id: new Date().toISOString(), text: 'hello' })
const all = await db.allDocs({ include_docs: true })

// plus: a CouchDB instance, its credentials in the client,
// its users database, and its CORS configuration

GenosDB:

import { gdb } from 'genosdb'

const db = await gdb('notes', { rtc: true })

db.map({ order: 'desc' }, ({ id, value, action }) => render(id, value, action))
await db.put({ text: 'hello' })

Note the credentials line in the PouchDB version. Syncing straight from the browser means the remote URL — and whatever authenticates it — ships to the client, which is why most production deployments end up putting a proxy in front and writing permission logic there. That proxy is a backend.

Side by Side

	PouchDB	GenosDB
Model	Client of a CouchDB server	Peer-to-peer, no server
Sync between two browsers	Only through the server	Directly, over WebRTC
Required infrastructure	CouchDB or Cloudant	None
Operating cost	Grows with users	Structurally zero
Local storage	IndexedDB	OPFS
Multiple tabs	Open issue since 2020, 33 comments	BroadcastChannel, by design
Conflict resolution	Revision trees, app resolves	HLC + loser re-applies
Identity	CouchDB `_users`	WebAuthn, signed operations
Permissions	Server-side	RBAC + per-node ACLs, client-side
Data model	Documents	Graph with traversal
Size	5,397 KB, 14 dependencies	2,007 KB, zero
Governance	Apache Software Foundation	Single maintainer
Latest release	9.0.0, June 2024	continuous

What This Looks Like Running

In the browser, with nothing deployed behind it.

Collaborative block editor — two browsers, one document:

A Splitwise-style expense splitter with no backend:

A Hacker News clone where moderation is a signed constitution instead of an admin panel:

When PouchDB Is the Right Choice

You already run CouchDB. If CouchDB is your source of truth, PouchDB is the best client for it and this comparison is irrelevant to you.
You need the server to be authoritative. Server-side validation, audit at a single point, compliance requirements that demand a machine you control. GenosDB verifies cryptographically at every peer, but there is no central authority to appeal to.
You need institutional governance. This is the strongest argument PouchDB has, and it is honest to state it: the ASF provides continuity that does not depend on any one person. GenosDB is maintained by one developer. If your risk assessment weighs that heavily, it should point you to PouchDB.
You want an Apache-licensed dependency. PouchDB is Apache 2.0. GenosDB's bundle is free for personal and commercial use, but the source is proprietary by deliberate governance choice — it is not open source, and describing it as such would be inaccurate.

GenosDB is the better fit when the server is the thing you are trying to remove: when you want offline-first and serverless, per-node permissions without a backend to enforce them, and an operating cost that does not scale with your user count.

A Note on Where This Comes From

I have spent years building browser P2P databases. I wrote the official GUN documentation platform and contributed to that codebase before starting GenosDB, and the design decisions here came from trying to build apps where there was genuinely nothing behind them — no CouchDB, no proxy, no bill that grows with signups.

PouchDB was never trying to solve that. It was solving "how does a browser app keep working on a train", and it solved it so well that fifteen years later the protocol is still the reference. This article is only about the sentence that tends to get dropped: and then it syncs with your server.

If anything here is out of date or wrong, tell me and I will correct it — GitHub Discussions is open and I answer.

Originally published at genosdb.com/pouchdb.

⭐ Found this useful? Star GenosDB on GitHub — or spin it up in seconds: npm i genosdb.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

Automerge vs GenosDB: The Price of Keeping Every Version

Esteban Fuster Pozzi — Mon, 14 Sep 2026 15:27:09 +0000

Automerge is the most intellectually ambitious CRDT in JavaScript. It comes out of the Ink & Switch research on local-first software, its core is written in Rust and compiled to WebAssembly, and it does something the others do not: it keeps the entire history of every change, so you can rewind a document, inspect who wrote what, and merge branches of data the way you merge branches of code.

That is a genuine capability, and when you need it there is no substitute. But it is not free, and the invoice arrives in three places: memory, bundle weight, and the maturity of the layer you need to actually sync anything.

This article is about that invoice. If you want the argument about how convergence can work without a CRDT at all, that is a separate piece: real-time collaboration without a CRDT library. And if you are weighing Automerge against Yjs specifically, that comparison is here.

What Automerge Keeps

Every CRDT stores metadata beyond your data. Automerge stores more than most, on purpose: a full operation history, per-actor, that survives compaction and travels with the document. That is what makes getChanges, time travel and attribution possible.

The consequence is that a document is never just its current state. It is its current state plus every state it has ever been in, and both live in memory while you work.

The Invoice, Item by Item

Memory

These are all open issues in the Automerge repository:

Issue	Filed	Signal
Memory leak with `initSyncState`	Apr 2024	9 reactions, zero comments
High memory spike on load and save, sometimes causing OOM	Aug 2023	8 comments
Unexpected quadratic performance loading a collaborative document	Apr 2024	3 comments
Degrading performance over time	Jul 2024	open
Save and Load performance	May 2023	6 comments
Performance regression on main	Sep 2025	7 comments
Tiny `ReceiveSyncMessage` is slow	May 2025	open

Seven open issues about memory and speed, and the most-reacted of them — a memory leak in the sync-state initialiser — has been sitting since April 2024 without a single reply. There is also an open request from November 2025 titled "Consider publishing new benchmarks", which tells you something about how hard this is to measure from outside.

The WebAssembly tax

The Rust core has to reach the browser somehow, and that path is where a lot of developer time goes:

Issue	Filed	Comments
The WebAssembly module seems to be missing from the package	Dec 2023	17
Bundling with Parcel	Feb 2023	11
`wasm.__wbindgen_add_to_stack_pointer` is not a function	Oct 2023	6
Deno: `automerge_wasm_bg.wasm` is not vendored	Mar 2023	5
Running Automerge in a Service Worker	Oct 2023	4
`decodeChange()` panics (WASM `capacity_overflow`)	Apr 2026	open
Panic after `migrate_actors` unwrap	Oct 2025	open

Every bundler needs its own WASM incantation, and when the Rust side fails it fails as a panic — a capacity_overflow or an unwrap, surfacing in your browser console with no JavaScript stack to follow.

The package itself:

@automerge/automerge          45,455 KB unpacked
genosdb                        2,007 KB unpacked, zero dependencies

The sync layer is still alpha

Automerge merges documents; it does not move them between devices. For that there is automerge-repo, the official networking and storage layer. Its current state:

npm latest:  2.6.0-alpha.3
open issues: 97
other dist-tags: next, authors, subduction

The library you need in order to actually build a collaborative app has never shipped a stable release. That is not a hidden fact — the version number says it plainly — but it is easy to miss when you are evaluating Automerge itself, which is at a confident 3.4.1.

What GenosDB Does Instead

GenosDB also keeps an operation log — but for a different purpose, and with a different lifetime.

The oplog exists so a reconnecting device can receive only what it missed rather than a full state transfer: rejoining a 210-item space costs 7.9 KB, where the same reconciliation without deltas costs 83 KB. It is a synchronisation mechanism, described in the Hybrid Delta Protocol. What it is not is a permanent per-actor archive that has to be resident in memory for the document to be usable.

The trade is explicit: you give up time travel, and you stop paying for it.

Everything else is JavaScript, with no WebAssembly anywhere:

import { gdb } from 'genosdb'

const db = await gdb('my-room', { rtc: true })

No bundler configuration, no .wasm asset to vendor, no panics from a Rust layer — and no separate repo package in alpha, because persistence (OPFS), transport (WebRTC via GenosRTC) and peer discovery (public Nostr relays, no signaling server of your own) are in the same two-megabyte package.

And convergence still happens. Concurrent writes to the same value are reconciled by Hybrid Logical Clocks with a deterministic tie order, and the writer whose operation lost the race re-applies its edit over the winner as an ordinary signed write, so neither contribution is dropped.

What Arrives in the Same Package

Automerge, like Yjs, has no opinion about who you are or what you may do — that is outside its scope. GenosDB puts it inside the database:

Identity, via WebAuthn or a mnemonic, with every operation signed by its author.
Permissions: RBAC with guest/user/manager/admin/superadmin, per-node ACLs, and rule-based governance. Enforced by signature at every peer, with no trusted server.
Queries, reactive: $eq $gt $in $between $text $like $regex $and $or $edge $near, with cursor pagination and recursive graph traversal.
Encryption, per record, where each record carries its own wrapped key — a read costs 1.2 ms, against roughly 10.9 ms for the conventional PBKDF2-per-record approach.

The Same App, Both Ways

Automerge — document plus repo plus storage plus network adapter:

import { Repo } from '@automerge/automerge-repo'            // latest: 2.6.0-alpha.3
import { IndexedDBStorageAdapter } from '@automerge/automerge-repo-storage-indexeddb'
import { BrowserWebSocketClientAdapter } from '@automerge/automerge-repo-network-websocket'

const repo = new Repo({
  storage: new IndexedDBStorageAdapter(),
  network: [new BrowserWebSocketClientAdapter('wss://your-sync-server.example')]
})

const handle = repo.create()
handle.change(doc => { doc.blocks = [{ text: 'hello' }] })
handle.on('change', ({ doc }) => render(doc.blocks))

// plus: a WASM asset your bundler has to emit correctly
// plus: identity and permissions, which are yours to build

GenosDB:

import { gdb } from 'genosdb'

const db = await gdb('my-room', { rtc: true })

db.map({ order: 'desc' }, ({ id, value, action }) => render(id, value, action))
await db.put({ text: 'hello' })

Side by Side

	Automerge	GenosDB
Core	Rust compiled to WebAssembly	JavaScript, no WASM
Package size	45,455 KB unpacked	2,007 KB, zero dependencies
History	Full, permanent, in memory	Oplog for delta sync only
Time travel	Yes — a real strength	No
Sync layer	`automerge-repo`, alpha, 97 open issues	Built in, stable
Storage	Separate adapter package	OPFS, native
Network	Separate adapter + your server	WebRTC + public Nostr relays
Identity	None	WebAuthn / mnemonic, signed ops
Permissions	None	RBAC + per-node ACLs + governance
Queries	Walk the document in JS	Full operator set, reactive
Failure mode	Rust panic in the console	JavaScript exception

What This Looks Like Running

In the browser, with nothing deployed behind it.

Collaborative block editor — two browsers, one document:

dCode — branches, commits and pull requests, peer-to-peer:

A Hacker News clone where moderation is a signed constitution instead of an admin panel:

When Automerge Is the Right Choice

Be honest with yourself about one question: do you need the history, or do you just need the merge?

You need time travel or attribution. Rewinding a document, showing who changed what, branching and merging data like code — Automerge does this and GenosDB does not. If that is the product, the memory cost is the price of the feature and it is worth paying.
You are doing research on local-first software. Automerge is where that work happens, and the Ink & Switch material around it is the best writing on the subject.
Rich text with full editing history. The combination of a mature text CRDT and a permanent history is genuinely rare.
You want an open-source dependency. Automerge is MIT. GenosDB's bundle is free for personal and commercial use, but the source is proprietary by deliberate governance choice — it is not open source, and describing it as such would be inaccurate.

GenosDB is the better fit when the history is not the product: when you want the live collaboration, plus identity, permissions, relations and queries, in one dependency-free package that no bundler has to be taught about.

A Note on Where This Comes From

I have spent years building browser P2P databases — I wrote the official GUN documentation platform and contributed to that codebase before starting GenosDB. The decision not to keep a permanent operation history was one of the earliest and least comfortable ones, because history is genuinely useful. It was made after watching what it costs in memory on a device that is not a laptop.

Automerge chose the other side of that trade deliberately, and for the problems it targets it chose correctly. This article is only about making the trade visible before you inherit it.

If anything here is out of date or wrong, tell me and I will correct it — GitHub Discussions is open and I answer.

Originally published at genosdb.com/automerge.

⭐ Found this useful? Star GenosDB on GitHub — or spin it up in seconds: npm i genosdb.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

Yjs vs GenosDB: A CRDT Library, or a Database That Already Syncs

Esteban Fuster Pozzi — Mon, 14 Sep 2026 15:23:38 +0000

Yjs is the best CRDT implementation in JavaScript, and it is not close. 31.8 million downloads a month, a decade of work behind it, and a conflict-resolution engine so solid that most of the collaborative editors you have used are running it underneath. Nothing in this article disputes that.

What this article is about is a different question, and it is the one that decides your architecture: Yjs is a data structure, not an application. It merges concurrent edits. It does not store anything, does not talk to anyone, does not know who the user is and cannot tell you whether they were allowed to make that change. Every one of those lives in a separate package.

That division is a legitimate design — do one thing well — and for years the ecosystem around it filled the gaps. The problem is what has happened to that ecosystem lately.

What Yjs Actually Gives You

Yjs provides shared types — Y.Map, Y.Array, Y.Text, Y.XmlFragment — that converge automatically when several people edit them at once. Feed it updates from anywhere, in any order, possibly duplicated, and every replica ends up identical. That is a genuinely hard problem and Yjs solved it well enough to become the default.

It is also, deliberately, all it does. Persistence, transport, identity and authorization are somebody else's job — specifically, the providers.

The Provider Problem

This is the part that rarely makes it into comparisons. To turn Yjs into a working application you assemble packages, and their maintenance status is not uniform:

Package	Role	Unpacked	Latest npm release	Repo activity
`yjs`	The CRDT itself	2,253 KB	current	active
`y-websocket`	Sync via your own server	92 KB	Aug 2026	active
`y-webrtc`	Peer-to-peer sync	1,848 KB	Dec 2023	last push Apr 2024
`y-indexeddb`	Local persistence	1,097 KB	Nov 2023	last push Feb 2025
`y-protocols`	Encoding	1,045 KB	—	active

Read that table again, because the shape of it matters more than any single row: the only actively released provider is the one that requires you to run a server. The two that would give you peer-to-peer sync and local persistence have not shipped a release in nearly three years, and y-webrtc has 22 open issues waiting.

Assembled, the browser-and-P2P stack — yjs + y-indexeddb + y-webrtc + y-protocols — comes to roughly 6.2 MB unpacked across four packages, and still leaves identity, permissions and queries unanswered. GenosDB is 2 MB in one package with zero dependencies, with those three included.

There is nothing dishonest about this — these are volunteer packages in a large ecosystem, and y-webrtc still works for many people. But if your plan was "Yjs plus y-webrtc, no backend", you are building on two packages whose last release predates a great deal of what has changed in browsers since.

Even the community forum reflects the strain: an issue opened in June 2026 reports that discuss.yjs.dev went down because its Let's Encrypt certificate expired.

What the Open Issues Say

Yjs has 139 open issues. Most are small. These are not:

"Nest Y types inside JSON" — open since November 2020, 27 reactions. The most-requested change in the repository, six years old. Y types cannot be nested inside plain JSON values, so your data model has to be expressed in Yjs's vocabulary rather than in your own.

"TypeScript enhancement" — open since January 2023, 23 reactions — and "Improve typescript typing of .get()" — open since November 2021, 18 comments. Y.Map.get() cannot tell you what it returns. In practice you cast.

"Misordered updates result in temporarily missing Y.Map keys" — open since October 2023, 11 comments. Under certain orderings, keys can briefly vanish from a Y.Map. Temporary, but a correctness surprise in a library whose whole promise is convergence.

"Y.Map get does not return prelim content" — open since June 2020, 11 comments. Reading back what you just wrote does not always give you what you wrote.

What You Still Have to Build

Suppose the providers work perfectly. Here is what Yjs still does not answer, by design:

Who is this user? Yjs has no identity. Awareness carries a nickname and a cursor colour; it is not authentication.
Were they allowed to do that? There is no authorization layer. Any peer holding the document can modify any part of it. If you need "editors may write, viewers may not", you build it, and you build it somewhere trusted — which usually means the server you were trying to avoid.
Where do I query? Yjs has no query language. You walk the structure in JavaScript. There is no "give me the open tasks assigned to me, sorted by priority".
How do I relate things? Y types nest inside each other, but there are no relations or traversal between documents.

None of this is a flaw. It is what "a CRDT library" means. The question is only whether you want to assemble the rest yourself.

What Arrives in One Package Instead

GenosDB starts from the other end: it is a database that happens to synchronise, rather than a synchroniser you build a database around.

import { gdb } from 'genosdb'

const db = await gdb('my-room', { rtc: true })

That single line brings persistence (OPFS), peer-to-peer transport (WebRTC through GenosRTC), peer discovery over the public Nostr relay network — no signaling server of your own — cryptographic identity via WebAuthn, and a query engine. Zero dependencies, so there are no satellite packages whose release cadence you have to track.

Identity and permissions are part of the database. The Security Manager signs every operation with the author's key, and every peer verifies it independently. Role-based access control — guest, user, manager, admin, superadmin — plus per-node ACLs and rule-based governance. "Editors may write, viewers may not" is enforced by signature, with no trusted server anywhere.

Queries go to an engine, not to a for loop:

db.map({
  query: { status: 'open', assignee: me, priority: { $gte: 3 } },
  order: 'desc',
  $limit: 20
}, onRow)   // live: re-fires as peers write

$eq $ne $gt $gte $lt $lte $in $between $exists $startsWith $endsWith $contains $text $like $regex $not $and $or $edge $near, with cursor pagination and $edge for recursive graph traversal.

And convergence still happens — without a CRDT library. The mechanism deserves its own article, and it has one: GenosDB vs Yjs and Automerge: real-time collaboration without a CRDT library walks through the ordering model, one node per paragraph, and why the path is shorter. This article is about the packaging; that one is about the algorithm.

The Same App, Both Ways

A collaborative document that persists locally and syncs peer-to-peer.

Yjs:

import * as Y from 'yjs'
import { WebrtcProvider } from 'y-webrtc'          // last release: Dec 2023
import { IndexeddbPersistence } from 'y-indexeddb' // last release: Nov 2023

const doc = new Y.Doc()
new IndexeddbPersistence('my-room', doc)
new WebrtcProvider('my-room', doc, {
  signaling: ['wss://your-signaling-server.example']
})

const blocks = doc.getArray('blocks')
blocks.observe(() => render(blocks.toArray()))
blocks.push([{ text: 'hello' }])

// identity, permissions and queries: not included

GenosDB:

import { gdb } from 'genosdb'

const db = await gdb('my-room', { rtc: true })

db.map({ order: 'desc' }, ({ id, value, action }) => render(id, value, action))
await db.put({ text: 'hello' })

// identity, permissions and queries: already here

Side by Side

	Yjs	GenosDB
What it is	CRDT library	Database with sync built in
Persistence	`y-indexeddb` (Nov 2023)	OPFS, native
P2P transport	`y-webrtc` (Dec 2023)	GenosRTC, native
Server-free discovery	Signaling server of your own	Public Nostr relays
Identity	None (awareness ≠ auth)	WebAuthn or mnemonic, signed ops
Permissions	None	RBAC + per-node ACLs + governance
Queries	Walk the structure in JS	Full operator set, reactive
Relations	Nested types only	Graph with `$edge` traversal
Packages to track	4+	1, zero dependencies
Conflict resolution	CRDT	Signed ops + Hybrid Logical Clocks

What This Looks Like Running

All of it in the browser, nothing deployed behind it.

Collaborative block editor — two browsers, same document:

dCode — branches, commits and pull requests, peer-to-peer:

A collaborative whiteboard in a single file:

When Yjs Is the Right Choice

You are integrating a rich-text editor. ProseMirror, TipTap, Lexical, CodeMirror, Monaco, Slate — Yjs has mature, battle-tested bindings for all of them. If character-level collaborative rich text is the product, use Yjs.
You already have a backend and want y-websocket. That path is actively maintained and well documented, and the server does identity and permissions for you.
You need the strongest possible merge guarantees on text. Yjs's CRDT has a decade of adversarial use behind it.
You want an open-source dependency. Yjs is MIT. GenosDB's bundle is free for personal and commercial use but the source is proprietary by deliberate governance choice — it is not open source, and saying otherwise would be inaccurate.

GenosDB is the better fit when the document is not the whole product: when you also need identity, permissions, relations and queries, and would rather not assemble four packages — two of them without a release since 2023 — to get there.

A Note on Where This Comes From

I have spent years building browser P2P databases. I wrote the official GUN documentation platform and contributed to that codebase before starting GenosDB, and every decision described here came from hitting these walls in real projects: a merge engine that worked beautifully and left me writing the authentication, the persistence layer and the permission checks by hand.

Yjs did not fail at any of that — it never promised it. What changed is that assembling the rest is no longer free, now that the packages you would assemble are three years between releases.

If anything here is out of date or wrong, tell me and I will correct it — GitHub Discussions is open and I answer.

Originally published at genosdb.com/yjs.

⭐ Found this useful? Star GenosDB on GitHub — or spin it up in seconds: npm i genosdb.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

OrbitDB vs GenosDB: Built on IPFS, or Built on Nothing at All

Esteban Fuster Pozzi — Mon, 14 Sep 2026 15:03:14 +0000

OrbitDB did something important: it showed that a serverless, peer-to-peer database in the browser was not a thought experiment. It has been around since 2015, it is built on IPFS and libp2p, it uses Merkle-CRDTs for conflict-free merges, and a lot of what the decentralized web takes for granted today was proven there first.

It is also the clearest example of a design decision that defines everything downstream: OrbitDB is a database built on top of IPFS. Not one that can use IPFS — one that cannot exist without it. Storage, replication, addressing and identity all run through that layer.

This article looks at what that choice costs in practice, what OrbitDB's own open issues say about the gaps it left, and how a database designed without that dependency handles the same problems.

What Is OrbitDB?

From their README:

"OrbitDB is a serverless, distributed, peer-to-peer database. OrbitDB uses IPFS as its data storage and Libp2p Pubsub to automatically sync databases with peers."

It offers several database types (events, documents, keyvalue), an append-only log as the underlying model, and pluggable access controllers and encryption modules. If your project already lives inside the IPFS ecosystem — content addressing, CIDs, pinning services — OrbitDB fits naturally into it, and nothing below changes that.

The Cost of Standing on IPFS

Here is the official example from OrbitDB's own documentation for opening a database:

import { createLibp2p } from 'libp2p'
import { createHelia } from 'helia'
import { createOrbitDB } from '@orbitdb/core'
import { LevelBlockstore } from 'blockstore-level'
import { Libp2pOptions } from './config/libp2p.js'

const blockstore = new LevelBlockstore('./ipfs')
const libp2p = await createLibp2p(Libp2pOptions)
const ipfs = await createHelia({ libp2p, blockstore })
const orbitdb = await createOrbitDB({ ipfs })
const db = await orbitdb.open('my-db')

Five imports, a blockstore, a libp2p configuration file and a Helia node — before a single record is written. That is not boilerplate that a tutorial skipped; it is the architecture. And it has a weight:

Package	Unpacked	Direct dependencies
`@orbitdb/core`	2,577 KB	10
`helia` (required)	5,998 KB	31
`libp2p` (required)	2,768 KB	27
Total	≈ 11.3 MB	68
`genosdb`	2,007 KB	0

Resolved transitively, @orbitdb/core pulls 53 packages into a project. GenosDB pulls none — not a small tree, zero — so there is no transitive surface to audit and nothing upstream that can go unmaintained on your behalf.

In GenosDB the equivalent of everything above is one line:

const db = await gdb('my-db', { rtc: true })

Storage is OPFS in the browser. Peer discovery runs over the Nostr relay network, which already exists and never sees your data. Transport is WebRTC through GenosRTC. There is no node to boot, no blockstore to configure and no pubsub layer to tune.

What OrbitDB's Open Issues Tell You

The most honest way to assess a project is to read what its users asked for and never got. These are all open issues in the OrbitDB repository, with the dates they were filed:

"Query standard" — open since August 2018

OrbitDB has no query language. You iterate the log and filter in JavaScript. The request for a standard has sat open, with zero replies, for eight years.

GenosDB ships a query engine built into map(): $eq $ne $gt $gte $lt $lte $in $between $exists $startsWith $endsWith $contains $text $like $regex $not $and $or $edge $near, with sorting, cursor-based pagination and $edge for recursive graph traversal. Every query can be made reactive by passing a callback — it re-fires as peers write.

"Lamport clock can be set far into future making db progress halt" — open since November 2018

A peer with a wrong clock can push the Lamport counter so far ahead that the database stops making progress. Eight years open, seven comments, unresolved.

This is precisely the failure mode Hybrid Logical Clocks exist to prevent. GenosDB blends physical time with a logical counter, so causality is preserved without trusting any device's wall clock, and a misconfigured peer cannot stall everyone else.

"Ordering tie breaker can cause undefined ordering" — open since November 2018

Two entries with the same identity and timestamp can order unpredictably. Filed in 2018, zero comments since.

GenosDB defines a deterministic tie order, and for lists that users reorder by hand it uses fractional order keys, so inserting, moving and pasting in a shared list converges to the same result on every peer.

"Database Encryption & Read Protection" — open since October 2021, 15 comments

OrbitDB does support encryption, through a modular interface where you supply the module. The one the project maintains carries this warning in OrbitDB's own documentation:

"WARNING: SimpleEncryption is an unaudited encryption module. Use at your own risk."

In GenosDB, encryption is not a module you source and vet. The Security Manager is part of the database: WebAuthn-based identity, signing on every operation, and end-to-end encryption where each record carries its own wrapped key. Reading an encrypted record costs 1.2 ms; the conventional approach of deriving a PBKDF2 key per record costs around 10.9 ms, which over a 40-record list is the difference between ~50 ms and nearly two seconds.

"Typescript implementation" — open since May 2025, 19 comments

The most-discussed open issue in the repository.

"Database record limits for acceptable lookup performance" — open since February 2024

Users asking where the practical ceiling is. Still open.

Access Control: Write Lists, Not Roles

OrbitDB's access controllers, in their own words, "define the write access a user has to a database". You get two: an immutable one stored on IPFS and a mutable one backed by an OrbitDB keyvalue store. Both answer a single question — is this identity allowed to write to this database?

That leaves three things to you: read protection, granularity below the database level, and any notion of roles.

GenosDB answers all three inside the client. Role-based access control with a real hierarchy — guest, user, manager, admin, superadmin — ACLs at the level of individual nodes, and rule-based governance that promotes and demotes users automatically according to signed rules. Confidentiality is cryptographic rather than topological: a peer can relay data it is not allowed to read.

Availability Without a Pinning Service

Because OrbitDB stores data as IPFS blocks, a record survives only while some peer still holds that block. Pinning — a paid service or an always-on node — is therefore a durability requirement, not a convenience: stop pinning and the data can genuinely go away.

GenosDB inverts the relationship. Every peer keeps a full local replica in OPFS, so the data already exists, complete, on every device that has ever opened the app. Reading it needs no network at all, and nothing is lost when peers disconnect — there is no block to keep alive somewhere else. A device that comes back pulls only what it missed: rejoining a 210-item space costs 7.9 KB, where the same reconciliation without deltas costs 83 KB, thanks to the Hybrid Delta Protocol.

The optional always-on peer solves a different problem — not keeping data alive, but greeting a brand-new device that arrives when nobody else happens to be online. It is a peer you may choose to run, not infrastructure the design leans on.

The Same App, Both Ways

A shared list that syncs live between browsers. This is OrbitDB's own getting-started example, unedited:

import { createLibp2p } from 'libp2p'
import { createHelia } from 'helia'
import { createOrbitDB } from '@orbitdb/core'
import { LevelBlockstore } from 'blockstore-level'
import { Libp2pOptions } from './config/libp2p.js'

const blockstore = new LevelBlockstore('./ipfs/blocks')
const libp2p = await createLibp2p(Libp2pOptions)
const ipfs = await createHelia({ libp2p, blockstore })
const orbitdb = await createOrbitDB({ ipfs })

const db = await orbitdb.open('my-db')

await db.add('hello world 1')
console.log(await db.all())

await db.close()
await orbitdb.stop()
await ipfs.stop()

Note what all() is: a point-in-time read. To know when a peer writes something you subscribe to database events separately, and to find records matching a condition you load everything and filter in JavaScript — there is no query layer to push that down to.

The same thing in GenosDB:

import { gdb } from 'genosdb'

const db = await gdb('my-db', { rtc: true })

await db.put({ text: 'hello world 1', at: Date.now() })

// live: the callback re-fires as peers write
db.map({ order: 'desc' }, ({ id, value, action }) => render(id, value, action))

And when the list is not "everything", the query goes to the engine rather than to a .filter():

db.map({
  query: { status: 'open', priority: { $gte: 3 }, title: { $text: 'sync' } },
  order: 'desc',
  $limit: 20
}, onRow)

There is no libp2p configuration file because there is no libp2p, no blockstore because storage is OPFS, and no ipfs.stop() because there is no node to stop.

Side by Side

	OrbitDB	GenosDB
Foundation	IPFS + libp2p, required	None — runs standalone
Install weight	≈ 11.3 MB, 53 transitive packages	2 MB, zero dependencies
Setup	blockstore + libp2p + Helia + OrbitDB	`await gdb(name, { rtc: true })`
Data model	Append-only log (events, docs, keyvalue)	Graph with relations and traversal
Queries	None — iterate and filter in JS	Full operator set, reactive
Conflict resolution	Merkle-CRDTs + Lamport clocks	Hybrid Logical Clocks
Encryption	Modular; official module is unaudited	Built in, per-record wrapped keys
Access control	Write lists per database	RBAC + node-level ACLs + governance
Identity	Keypair	WebAuthn or mnemonic, signed operations
Availability	Survives only while a peer pins the block	Full replica on every device, always
TypeScript	Open issue since 2025	Typed

What This Looks Like Running

Everything below runs in the browser with nothing deployed behind it — no IPFS node, no pinning service, no backend.

Collaborative editing, no CRDT library:

dCode — a code editor with branches, commits and pull requests, peer-to-peer:

A Hacker News clone where moderation is a signed constitution instead of an admin panel:

A collaborative whiteboard in a single file:

When OrbitDB Is the Right Choice

You are already on IPFS. If your data is content-addressed, if CIDs matter to your model, or if you are pinning through an existing service, OrbitDB is native to that world and GenosDB is not.
You need a tamper-evident archive. OrbitDB's append-only Merkle log is content-addressed, so history cannot be quietly rewritten — valuable if auditability is the product. GenosDB signs every operation and keeps an oplog for synchronisation, but it is built to represent current state rather than to serve as a permanent ledger.
You want a fully open-source stack. OrbitDB is MIT. GenosDB's production bundle is free for personal and commercial use, but the source is proprietary by deliberate governance choice — it is not open source, and describing it as such would be inaccurate.
Content addressing is the feature. If deduplication and permanent addressing of blobs is what you are buying, that is IPFS's job and it does it well.

GenosDB is the better fit when the IPFS layer is a cost rather than a feature: when you want relational queries over a graph, roles and per-node permissions without a server, a two-megabyte dependency-free bundle, and an app that works with nothing deployed behind it.

A Note on Where This Comes From

I have spent years building browser P2P databases — I wrote the official GUN documentation platform and contributed to that codebase before starting GenosDB. Every design decision described here came from hitting these specific walls in real projects: queries I could not express, clocks I could not trust, permissions I could not enforce without a server, and bundles too heavy to justify.

None of this is a knock on OrbitDB's ambition. It asked the right question in 2015 and answered it with the tools available then. GenosDB is what happens when you ask the same question after OPFS, WebRTC, WebAuthn and Nostr exist, and conclude that the storage layer does not have to be someone else's network.

If anything here is out of date or wrong, tell me and I will correct it — GitHub Discussions is open and I answer.

Originally published at genosdb.com/orbitdb.

⭐ Found this useful? Star GenosDB on GitHub — or spin it up in seconds: npm i genosdb.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

RxDB vs GenosDB: Local-First With a Server, or Peer-First Without One

Esteban Fuster Pozzi — Mon, 14 Sep 2026 14:44:27 +0000

RxDB is one of the best-engineered local-first databases in JavaScript. It has 23,000 stars, 270,000 downloads a month, and a commit history that does not go quiet. If you are building an offline-capable app that syncs with a backend you already run, it is a genuinely good answer, and this article is not going to pretend otherwise.

But RxDB and GenosDB solve different problems, and the difference is not a feature list — it is where the authority lives. RxDB is a local database that replicates to a server. GenosDB is a peer-to-peer database with no server at all. Everything else in this comparison follows from that single line, including the parts where RxDB wins.

This is an honest walkthrough of what RxDB is, where its own documentation draws the line, and what a peer-first design does differently.

What Is RxDB?

RxDB (Reactive Database) is a local-first NoSQL database for JavaScript. It runs in the browser, Node.js, Electron and React Native, persists through a pluggable storage layer, and exposes documents and queries as RxJS observables. Queries follow MongoDB syntax and documents validate against JSON Schema.

Its real strength is the replication layer. RxDB ships official plugins for HTTP, GraphQL, CouchDB, Firestore, Supabase, Appwrite, MongoDB, NATS, WebSocket and WebRTC. If your data already lives somewhere, RxDB probably has a plugin for it.

It is also honest about itself, which is rare. RxDB publishes a page called Downsides of Local First / Offline First listing its own limitations, including "It only works with small datasets", "Browser storage is not really persistent" and "Realtime is a lie". That page is worth reading regardless of which database you pick.

The Architecture Question

Both databases store data in the browser and both can sync between clients. The difference shows up when you ask a simple question: when two peers disagree, who decides?

In RxDB, the server decides. Replication is a protocol between a client and an endpoint — pull and push handlers talking to something you operate. Conflict handling, authorization and identity are your backend's job, because that is where the trust lives.

In GenosDB there is no such place. Every operation is signed by its author before it leaves the browser, and every peer verifies it independently against a shared set of rules. Authority is not a server — it is a signature. That is the Zero-Trust model, and it is what makes running with no backend at all a coherent design rather than a missing feature.

RxDB                          GenosDB

Browser ──► RxStorage         Browser ──► Security Manager (signs)
   │                             │
   └──► replication plugin       └──► Graph Store (OPFS)
            │                            │
            ▼                            ├──► Peers (GenosRTC / WebRTC)
        Your backend                     │
        (authority)                      └──► Nostr relays (discovery only)

Where RxDB Draws the Line — In Its Own Words

RxDB does have a WebRTC replication plugin, so "RxDB can do P2P too" is technically true. The interesting part is what their documentation says about it.

You must operate a signaling server

From the official WebRTC replication docs:

"RxDB ships with a default signaling server (…) This server is made for demonstration purposes and tryouts. It is not reliable and might be offline at any time. In production you must always use your own signaling server instead!"

So the serverless setup has a server in it. You deploy it, you keep it up, you pay for it, and you add authentication to it — their docs say as much: "in production, you'd want to create a more robust signaling server with authentication and additional logic".

GenosDB does not have a signaling server to operate, because peer discovery runs over the Nostr relay network — public infrastructure that already exists, is already decentralized, and never sees your data. If you want your own, GenosSIG runs an ephemeral relay on Cloudflare's free plan. Neither option is a server you maintain.

It is not a full mesh, and they say so

Also from their docs:

"Notice that the peers still have to find each other through a signaling server, so this is not a full offline mesh."

That sentence is followed by a pointer to a different product (Ditto) for environments with no infrastructure at all.

OPFS and encryption are paid features

This is the part most comparisons miss. RxDB's core is Apache 2.0 and free. But on the pricing page, the free tier is capped at 13 open collections in parallel, and these sit behind Pro, from $99/month billed annually:

RxDB Pro feature	GenosDB
RxStorage OPFS	Default storage, free
WebCrypto Encryption	Built in, free
RxStorage IndexedDB	— (OPFS by default)
Fulltext search	`$text` operator, free
Worker / Sharding (Pro Plus, $239/mo)	Worker architecture, free

OPFS — the storage engine that makes browser persistence fast — costs $1,188 a year in RxDB. In GenosDB it is what you get when you run npm i genosdb, because the production bundle is free for personal and commercial use, with no tiers, no collection caps and no feature gates. The source is proprietary, which is a deliberate governance choice and is stated plainly — GenosDB is not open source, and calling it that would be inaccurate.

Permissions and authentication

RxDB lists this among its own downsides, and the reasoning is sound: in a local-first app the client holds the data, so enforcing who may read or write it is not something the client can be trusted to do. Their answer is the backend.

GenosDB's answer is cryptography. The Security Manager provides WebAuthn-based authentication, role-based access control, ACLs at node level and rule-based governance for promotion and demotion. A peer that receives an unsigned or unauthorized operation rejects it — not because a server said no, but because the signature does not check out.

This is the one axis where the difference is not a trade-off but a genuine capability gap, and it is why GenosDB can claim zero-trust and RxDB does not.

What Peer-First Buys You

Cellular Mesh instead of full mesh

A naive WebRTC mesh opens a connection between every pair of peers: n(n−1)/2 links, which collapses somewhere around 50–100 peers. Cellular Mesh partitions peers into cells with bridges between them, turning quadratic growth into something that scales linearly. This is handled by GenosRTC, GenosDB's own networking layer, with epoch-sealed topology so cell membership cannot be gamed mid-flight.

Hybrid Logical Clocks instead of wall clocks

Conflict resolution based on Date.now() breaks when device clocks drift, which they always do. GenosDB uses Hybrid Logical Clocks — causality without requiring synchronized time.

An operation log, so sync sends deltas

Every write goes through an operation log, so a device that reconnects pulls only what it missed instead of a full state transfer. Measured in a user's app: a device rejoining a 210-item space pulls 7.9 KB. The same reconciliation without deltas costs 83 KB — more than ten times the traffic, on every single reconnection. The mechanism is documented in the Hybrid Delta Protocol.

Encryption that does not re-derive a key per node

The standard way to encrypt data client-side is to derive an AES key with PBKDF2 — typically 100,000 iterations. It is what the Web Crypto guides recommend, it is cryptographically correct, and it costs roughly 22 ms every time it runs. Because that derivation happens once per record, on every read and every write, the cost scales with the size of the list you are rendering.

GenosDB derives nothing at read time. Each record carries its own key, already wrapped for the reader, so a read is one ECDH plus an AES decrypt. Same machine, same data:

Operation	Standard per-record PBKDF2	GenosDB
Read, per node	10.9 ms	1.2 ms
Write, per node	11.1 ms	1.5 ms
Reading 40 encrypted records	~1,790 ms	~50 ms

That last row is the difference between a list that renders instantly and one that stalls for nearly two seconds — same guarantees, same hardware.

Zero runtime dependencies

GenosDB ships with none. No transitive tree, no supply-chain surface to audit, nothing to patch when an upstream package is abandoned. That is not a small claim in 2026 — see GunDB's supply chain for what the alternative looks like.

Side by Side

	RxDB	GenosDB
Model	Local-first, replicates to a backend	Peer-to-peer, no backend
Data model	Documents + JSON Schema	Graph, schemaless
Authority	Your server	Cryptographic signature per operation
Signaling	Your own server, required in production	Nostr relays (public) or GenosSIG
P2P topology	Full mesh via plugin	Cellular Mesh, native
Conflict resolution	Custom handlers	Hybrid Logical Clocks
Storage	Dexie free · OPFS from $99/mo	OPFS, free
Encryption	Pro tier	Built in, free
Access control	Your backend	RBAC + ACLs + governance, in the client
Collections (free tier)	13 in parallel	Unlimited
Runtime dependencies	Several	Zero
Source	Apache 2.0 core, commercial plugins	Proprietary source, free bundle
Schema migrations	Required	None

The Same App, Both Ways

A shared list that syncs live between browsers. Nothing exotic — the "hello world" of collaborative apps.

RxDB, following their own documentation:

import { createRxDatabase } from 'rxdb'
import { getRxStorageDexie } from 'rxdb/plugins/storage-dexie'
import { replicateWebRTC, getConnectionHandlerSimplePeer } from 'rxdb/plugins/replication-webrtc'

const db = await createRxDatabase({
  name: 'notes',
  storage: getRxStorageDexie()          // OPFS storage is a Pro feature
})

await db.addCollections({
  notes: {
    schema: {
      version: 0,
      primaryKey: 'id',
      type: 'object',
      properties: {
        id:   { type: 'string', maxLength: 100 },
        text: { type: 'string' },
        at:   { type: 'number' }
      },
      required: ['id', 'text']
    }
  }
})

const pool = await replicateWebRTC({
  collection: db.notes,
  topic: 'my-app-notes-room',
  connectionHandlerCreator: getConnectionHandlerSimplePeer({
    // "You can use the server provided by RxDB for tryouts,
    //  but in production you should use your own server instead."
    signalingServerUrl: 'wss://signaling.rxdb.info/'
  }),
  pull: {},
  push: {}
})
pool.error$.subscribe(err => console.error('WebRTC Error:', err))

await db.notes.insert({ id: crypto.randomUUID(), text: 'hello', at: Date.now() })
db.notes.find().$.subscribe(render)

GenosDB:

import { gdb } from 'genosdb'

const db = await gdb('my-app-notes-room', { rtc: true })

await db.put({ text: 'hello', at: Date.now() })
db.map({ order: 'desc' }, ({ id, value, action }) => render(id, value, action))

No schema to declare, no migration path to maintain, no storage plugin to license, and no signaling server to deploy — peer discovery is already handled over Nostr relays.

To be fair to RxDB: that schema is not only ceremony. It buys validation, typed documents and a migration system, and if your data has a fixed shape enforced across a team, you may want exactly that. The question is whether you are paying for it in a project that does not need it.

What This Looks Like Running

The claim "no backend" is easy to make and easy to check. Every one of these runs entirely in the browser, with nothing deployed behind it.

Collaborative editing without a CRDT library — a block editor where two browsers edit the same document live:

dCode — a code editor with branches, commits and pull requests, peer-to-peer:

A Hacker News clone where moderation is a signed constitution rather than an admin panel:

A collaborative whiteboard, in a single file:

There are more of them — kanban boards, expense splitters, chat, file transfer, audio and video streaming, a Godot multiplayer plugin, and a WebGPU planet with no backend. The point of publishing so many is that "serverless" should be demonstrable, not asserted.

When RxDB Is the Right Choice

I would rather be useful than win an argument, so:

You already have a backend. If Postgres, Supabase, Firestore or CouchDB is your source of truth and you want offline capability on top, RxDB is built exactly for that and GenosDB is not.
You need schemas and validation enforced. RxDB's JSON Schema layer catches bad data at the boundary. GenosDB is schemaless by design.
You need server-enforced authorization. GenosDB verifies cryptographically at every peer, but there is no central authority to appeal to. For some compliance requirements, that is the wrong shape.
Your dataset is too large for a full replica per browser. Both have this limit; RxDB's storage tiers give you more room to negotiate it.
You want an open-source core. RxDB's is Apache 2.0. GenosDB's source is not public, and no amount of free licensing changes that.

And in return, GenosDB is the better fit when there is genuinely nothing behind the app: real-time collaboration with no backend to run, offline-first apps where each device holds a full replica, multiplayer browser games, or any product whose cost model cannot survive a per-seat sync bill.

A Note on Where This Comes From

I have spent years inside browser P2P databases. I built the official GUN documentation platform and contributed to that codebase before starting GenosDB, and the design decisions described here — OPFS instead of localStorage, HLC instead of wall clocks, an oplog for delta sync, signatures instead of a trusted server — all came from hitting those specific walls in real projects, not from a whiteboard.

RxDB is not the enemy in that story. It is a well-run project solving a different problem, by a maintainer who documents his own limitations in public, which I respect and have tried to match here. If anything in this comparison is out of date or wrong, tell me and I will correct it — GitHub Discussions is open and I answer.

Originally published at genosdb.com/rxdb.

⭐ Found this useful? Star GenosDB on GitHub — or spin it up in seconds: npm i genosdb.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

A GitHub With No Server: dCode, a Peer-to-Peer Code Editor and Code Host in One Page, Just GenosDB

Esteban Fuster Pozzi — Sun, 06 Sep 2026 22:51:19 +0000

Two people open the same file. Both type. Their carets are on each other's screens. One of them commits; the other forks, proposes, and the owner merges. Every commit in the timeline can be run. And there is no server anywhere — not for the editing, not for the history, not for the merge.

That is dCode: a real-time collaborative code editor and a GitHub-style code host in one page, for projects that are one HTML file — HTML, CSS and JavaScript together, the way CodePen or JSFiddle hold a pen. It is four files of plain JavaScript, about seven hundred lines of application, on top of GenosDB, a peer-to-peer graph database that lives in the browser.

Alice's window. Bob's caret is on line 15; the page on the right re-ran a moment after his last keystroke; the timeline below is the history of main, and every row of it runs.

This is the sequel to Real-Time Collaborative Editing Without a CRDT, which showed that a block editor — one node per paragraph — reaches the live experience of Yjs and Automerge without a CRDT library, because a graph database with ownership, ordering and an ephemeral channel already carries the pieces. This article takes the same technique to code, and then goes where an editor alone cannot: the things GitHub runs servers for.

What GitHub Runs Servers For

A code host is a list of guarantees, and each of them is usually a server's job.

On GitHub, on CodePen	On dCode
A server holds the repositories, a server runs the collaboration	Every visitor holds the graph; peers sync it directly over WebRTC, live typing included
An account is a row in a database	An identity is a key pair on your device: a mnemonic recovers it, a passkey keeps it
A shared editor needs a CRDT library and a relay	A line is a node: two people on different lines never collide, two on the same line keep both edits when they touch different places, carets ride an ephemeral channel
Branch protection is a server rule	A branch is a node its owner owns: only the owner, and the addresses granted `write`, can move its head — refused on every peer otherwise
A commit is trusted because the server says so	A commit's id begins with its author's address and ends with a hash of its content: nobody else can create it, rewrite it or delete it, anywhere
A pull request's state is a column	Whether a proposal is merged is read from the graph by every peer: the proposed commit is an ancestor of the target's head, or it is not
History is browsed	History runs: a project is one HTML file, so any commit opens in a sandboxed frame as it was
Offline is an error	A commit made with no peer in sight waits on this device's disk and lands when a path exists, signed like any other

Every row on the right is a property of the graph, not a feature of the application. The application is short because it has almost nothing to enforce.

Two Layers, One Graph

dCode keeps two kinds of state in one GenosDB graph, and the difference between them is the whole design.

Left, the buffer: plain nodes anyone on the branch may write. Right, the history: nodes only their owner may write. One subscription feeds both.

The buffer is shared. Every line of a branch's code is a plain node — { type: "line", branch, text, order } — that anyone on the branch may rewrite, split, merge, move or remove. It is the working tree, and it is live: what one person types, the others see character by character.

The history is owned. A repository, a branch, a commit and a pull request are nodes created with GenosDB's ACL layer, db.sm.acls.set. The creator becomes the owner, and the engine refuses anyone else's edit or deletion — on every peer, live or through catch-up. Nothing in the history can be changed by someone who did not write it.

Both layers arrive through one subscription:

await db.map({ query: { type: { $in: ["repo", "branch", "commit", "pr", "line"] } } }, ({ id, value, action }) => {
  if (action === "removed") nodes.delete(id); else nodes.set(id, { id, value })
  // lines go straight to the editor; everything else redraws the timeline, the branches, the pull requests
})

Branches, the timeline, the diff of a commit and the state of every pull request are pure functions of that store. Nothing ticks over the wire; nothing is asked of anyone.

The Editor Is the Block Editor, for Code

The block editor made a document out of paragraph nodes. dCode makes a file out of line nodes, and inherits every property that article argued for:

Line-level last-write-wins. Two people on different lines never collide, because there is no shared node to fight over. Two carets on the same line keep both edits when they touch different places; only the same span at the same instant is the later writer's — and they can see each other.
Fractional order keys. A line inserted between keys 13 and 15 gets a key in the gap. Two peers inserting at the same place mint different keys, both survive, and every peer sorts them identically: a sorted db.map breaks ties on the node id, in the direction of the sort. Enter splits a line into two nodes and keeps the indentation; Backspace at the start of a line merges it into the one above; Alt+↑/↓ moves a line by giving it a new key; a multi-line paste mints all its keys in one batch, so a thousand pasted lines cost the precision of one insert, not one halving per line. The pattern, its float64 limit and the engine's rule are written up in the Ordered Lists guide.
Awareness is ephemeral. Carets, selections and the line being typed travel on a GenosRTC channel that never touches the database — which is also how Yjs does awareness. Keystrokes are coalesced to one message per frame; the debounced put remains the truth that persists, repairs and survives offline.

// The truth: one node per line, written 250 ms after the last keystroke.
db.put({ type: "line", repo, branch, text, order }, lineId)

// The experience: the line being typed, keystroke by keystroke, on the room's channel.
db.room.channel("presence").send({ kind: "text", block: lineId, start, end, text })

Two things a code editor needs that a document did not: line numbers, which are positions derived from the order and never stored, and syntax colours, painted per line by the language the line is in — HTML, the CSS inside <style>, the JavaScript inside <script>. The same pass that finds those regions gives the HTML · CSS · JS views: filters over the one file, showing the <style> block or the <script> block with the file's own line numbers. The same nodes, edited and synced the same way; a line born in the CSS view is inside <style> and stays visible there.

The CSS view: two lines, numbered 7 and 8 because that is where they are in the file. An edit here is an edit of the same node the HTML view shows.

The page on the right re-runs a moment after the last change, in a sandboxed frame with no access to the host page. Download .html saves the buffer as one file — HTML, CSS and JavaScript together — and every commit in the timeline downloads as it was.

A Commit That Names Itself

A commit is a node holding the whole file, a message, its parents and the branch it was made on. What makes it history rather than data is its id.

The id is built by the author and enforced by every peer: the address says who may sign for it, the hash says what it holds.

const id = `${me}:${await sha256([repo, parents.join(","), message, content, at].join("\n"))}`
await db.sm.acls.set({ type: "commit", repo, branch, parents, message, content, at }, id)

GenosDB's authorship gate has a rule for ids that begin with an address: on a peer that never saw the node, an operation on that id is accepted only when it is signed by that address. So nobody else can create a commit under Alice's name, on any peer, ever. And because the rest of the id is a hash of what the commit holds, Alice cannot rewrite it either: change one byte and you have a different commit, while the old one stays where every peer keeps it. Immutable history, with no server to keep it.

A Branch Only Its Owner Moves

A branch is an owned node with a head. The owner moves it; the owner can grant write to collaborators with db.sm.acls.grant; everyone else's write of that node is refused by every receiver. That is GitHub's branch protection, and it costs the application zero lines: the engine enforces it.

What does someone without write do? They edit the shared buffer like anyone — and when they commit, the commit goes to a branch of their own, forked from the head they stood on, with a copy of the buffer. A fork is a branch you own in someone else's repository. Then they propose.

The test suite includes the negative, because a zero-trust claim is only as good as its refusal. Bob, from the browser console, writes Alice's branch node with his own head, past the application. His own graph believes him — a tampered client can always lie to itself. Every other peer refuses the operation, and the proof is not silence: Bob's next honest commit lands on Alice's screen while main has not moved.

Two collaborators pushing to one head at the same moment is the other case a server usually arbitrates. Here the hybrid logical clock keeps one head; the other commit stays in the graph, behind, and merges like any other — the same outcome as a rejected non-fast-forward push, resolved by the clock instead of an error.

Pull Requests Nobody Marks as Merged

A pull request is a node its proposer owns: from one branch, into another, with the commit it proposes. The proposer updates it when their branch moves, or withdraws it. The target's owner merges it. And merged is never written by anyone: every peer derives it from the graph — the proposed commit is an ancestor of the target's head, or it is not.

Three merges, one rule: the target's owner writes, every peer reads. The shared buffer follows the new head in all three.

When the target's head is an ancestor of the proposal, the merge is a fast-forward: one write on the branch node. Otherwise a line-based three-way merge runs from the newest common ancestor — a region changed on one side takes that side, changed the same way on both is taken once — and the owner commits the result with both heads as parents. Adjacent changes are one region and a conflict, as in git.

After the merge. Nobody wrote "merged" anywhere: Bob's commit is now an ancestor of main's head, and every peer reads the same thing.

A conflict is the interesting case, because the buffer is shared. The marked text lands in the target branch's buffer — on every screen, Bob's included — and the owner resolves it in the editor, with everyone watching. The commit made from the resolution has two parents and is the merge. Markers left in the file are refused, in words.

Both changed the heading. The markers are in main's buffer for everyone to see; the next commit on main will be the merge.

The timeline is a graph in the margin: one lane per branch, one row per commit, and every row runs.

Offline Is a Commit Like Any Other

Close the network and keep working. The buffer is on this device's disk — GenosDB persists the graph in the browser's Origin Private File System — and a commit made with no peer in sight is a commit: signed, owned, waiting. When a path exists again, it travels through the delta sync and lands on every peer that accepts it under the same rules as a live one. There is no "offline mode" in the application, because there is nothing for it to do: the same code path that handles a live write handles a write that spent an hour on disk.

This is the behaviour the tests exercise with a peer pointed at a relay nobody listens on: it creates a repository and commits alone, comes back on the live relay, and a second visitor finds the repository, the commit and the buffer, line for line.

Private Repositories: The Engine Keeps the Key

Everything above is readable by the room, on purpose: a public repository on dCode is public the way a public repository on GitHub is. A private one is a different promise, and a system with no server has to keep it with cryptography, because there is nobody to ask who is asking.

GenosDB has the primitive. db.sm.put writes an encrypted node: the value is sealed with a content key, and that key is wrapped once per reader — an envelope per address — inside the node itself. grant on it adds an envelope; revoke removes one and rotates the key. dCode uses exactly one such node per private repository: its vault, holding the repository's key ring, newest key first.

From there the application does the small part. Tick Private when creating a repository and the owner's session mints a key and puts it in the vault. Every line of the buffer and every commit is then sealed with that key — AES-GCM, in the browser — before it is written as an ordinary node, and the live keystrokes on the ephemeral channel are sealed the same way. The name, the description, the branch names, the commit messages and the pull request titles stay readable, so the timeline still makes sense to someone who cannot open the code. A member is an address the owner grants read on the vault: the engine wraps the key for them, their browser fetches it, opens what is already on its disk and whatever arrives afterwards, and the editor appears — the grant reaches their page on its own, through the same subscription that does everything else. Revoking a member turns two keys at once: the engine rotates the vault's, and the application adds a new key to the repository's ring, so what is written afterwards never opens for them.

Two details are worth the space. First, the code is opened in memory and never written back in clear: a member's disk holds the same ciphertext as everyone else's, and the test suite reads the OPFS file of every peer — the owner's included — to prove it. Second, the authority is not a member: the constitution's superadmin, who can restrict any identity, meets the same locked door as a stranger. In a system with no server, "private" cannot mean "the admin can see it"; it means whoever holds an envelope, and nobody else.

What it does not do, said plainly: a revocation is forward-only — what a former member already read, they read — and the ordinary nodes that carry the ciphertext can still be vandalised by anyone in the room, since writing to a shared buffer is free. Both are the trade-offs a shared document has too; the code is no less private for them, and the history stays owned and signed either way.

The Constitution: Writing Is Free, Nothing Owned Is Touchable

dCode is governed the way dNews is: by a constitution every peer runs, rendered verbatim on its own page. Its roles are short, because the ownership rules above do the work:

guest — everyone, from the first second: reads everything, writes nodes of its own and edits or removes the lines of any shared buffer. Nothing owned by someone else.
restricted — lost the right to write. Its repositories, branches and commits stay exactly where they are, signed by it.
superadmin — the authority. Its only power is to restrict an identity, with its signature. It cannot touch a repository, a branch or a commit it does not own.

Writing is free from the first second — as on any code host, you sign up and you push — because on an owned node a write or a deletion is only ever the owner's. The one permission worth a sentence is delete: a shared buffer must be able to lose a line, so guests may remove plain nodes; owned nodes stay gated by ownership. Everything GenosDB's zero-trust model enforces — signatures on every operation, verification on every peer, roles valid only with the authority's signature — applies here without a line of application code.

What It Deliberately Does Not Do

Interleaving inside one span. Two people on the same line keep both edits when they touch different places: the engine re-applies the losing write over the winner, and the editor lands it under the caret. Only the same span at the same instant is the later writer's, with the carets in view. That is the dividing line the previous article draws, and it holds for code.
Folders, binaries, git interoperability. A project is one HTML file. That is what makes every commit runnable, and it is the size of project this is for.
Declining a pull request from the target side. A pull request is the proposer's node; the target's owner ignores it, or merges it. The proposer withdraws it.

Try It

The application is four files, with no build step and nothing to deploy:

👉 Open dCode — sign in as alice in one window and bob in another, create a repository, type in both, commit, fork, propose, merge. Tick Private on a repository and open it as a third identity to meet the locked door; the name at the top right opens your identity view, where a passkey can take a phrase session so it survives a reload.
📄 Read the source — the model is documented in the README and in the constitution; the tests say what each claim rests on.
📝 Real-Time Collaborative Editing Without a CRDT — the technique the editor is built on, with the fractional keys and the tie rule explained.
🧭 See how GenosDB compares across other P2P and distributed databases, or read the full GunDB guide if that is where you are coming from.

⭐ If you like it, the best way to support the project is a star on GitHub — and a star is the one thing here no AI can give. Models can write code, review it and explain it; only a person can decide that a project deserves a star. If you are that person: dCode for the application and GenosDB for the engine that makes it possible. Or spin the engine up in seconds: npm i genosdb.

This article is part of the official documentation of GenosDB (GDB).
GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

A Hacker News Clone With No Server — Four Files, a Constitution Every Peer Runs, Just GenosDB

Esteban Fuster Pozzi — Sat, 05 Sep 2026 02:32:29 +0000

Every Hacker News Clone Ends With a Server

The Hacker News clone is the "hello world" of web frameworks. There is one for Vue, one for React, one for Svelte, one for every backend-as-a-service — and they all end the same way: a server holds the stories, a database holds the votes, an auth service holds the accounts, and the front end asks them politely. The orange bar is the easy part.

This one has no server. Four files, no build, no backend, no accounts. Open the page and your browser holds the whole site — every story, comment, vote and flag — as a graph that syncs peer-to-peer over WebRTC with every other browser that has it open. Nobody hosts it. Nobody moderates it either: a constitution every peer runs decides who may write, what a vote weighs, and when an item dies — and that constitution is a file in the repository. The engine underneath is GenosDB, a graph database that lives in the browser, signs every write, and syncs between peers with nothing in the middle.

Live: dNews — sign in with one click, submit, vote; open a second browser and watch it follow.
Source: estebanrfp/dNews — index.html, styles.css, app.js (under 500 lines) and constitution.js.

The Whole Idea in Three Sentences

The graph is the site, and every visitor holds it. There is no API to call: db.map is a live query over the nodes on your own disk, and the peers keep those nodes the same.
Every node is signed and owned. A story, a comment, a vote and a flag are nodes created by an identity; the engine refuses anyone else's edit or deletion, on every peer. "Who voted" is not a field you trust the site about — it is the owner nobody could forge.
Nobody decides; everybody calculates. Points, karma, trust, ranking and the death of an item are derived by each browser from the same signed nodes, with the same rules. The only signature that grants anything is the authority's, and its only power is signing roles.

What a Shared Constitution Changes

Every community site runs on rules. The difference is where they live. On a forum with moderators, the rules live in people: a ban is a judgement, a removed post is a mood, a shadowban is a decision nobody announced, and the same comment survives on Monday and dies on Friday depending on who is on shift. That is not a complaint about moderators; it is what any system built on human discretion does, and nobody can audit it from outside.

A distributed site can put the rules somewhere else. Here they live in a file that every peer runs, and that changes five concrete things:

	Moderators	A shared constitution
Who the rule applies to	Whoever the moderator notices	Everyone, identically — the same code runs in every browser
When you learn the rule	After it hits you	Before you post: the constitution page is the file itself
Can a decision be checked?	No — the log, if any, is theirs	Yes — every flag and vote is a signed node; anyone recounts the verdict
Can content be removed quietly?	Yes	No — nothing has a path to delete another's node; a killed item stays in grey, with its reason
How rules change	Silently, in a policy nobody diffs	By pull request, in public, one diff at a time

Two things fall out of that which no amount of good will can give a moderated site. The rule cannot have a prejudice, because it cannot see who you are — only what your nodes say and what trusted members did about them. And power is bounded by construction: the one signature that grants anything belongs to the authority, and the engine gives it exactly one thing to sign, roles, by rules everyone can read. It cannot edit a post, delete a comment, or move a story down the page, because there is no operation for it. A system in which the moderator cannot abuse a power is different in kind from one in which the moderator promises not to.

None of this makes a community wise — a bad rule, applied to everyone with perfect consistency, is still a bad rule. It makes it legible: the rule is the argument, and the argument is a file you can fork.

Step 1 — One Subscription, Every Page

const db = await gdb("dnews", {
  rtc: true,
  sm: { superAdmins: [CONSTITUTION.authority], customRoles: CONSTITUTION.roles, governanceRules, acls: true },
})

// One live query feeds a store; the front page, a thread, a profile are
// pure functions of it. Nothing is fetched, nothing ticks over the wire.
const nodes = new Map()
await db.map({ query: { $or: [{ type: { $in: ["story", "comment", "vote", "flag", "vouch"] } }, { role: { $exists: true } }] } },
  ({ id, value, timestamp, action }) => {
    if (action === "removed") nodes.delete(id)
    else nodes.set(id, { id, value, timestamp })
    scheduleRender()
  })

That is the whole data layer. gdb(name, { rtc: true }) opens a local database under that name and joins the room of the same name; the sm block installs the constitution — the authority's address, the roles, the rules — and every peer must carry the same one, or their signatures mean different things. The callback fires once per node already on disk, then once per change from any peer; the $or pulls the user: nodes too, which is where the Security Manager keeps each identity's role.

The front page is HN's own formula over that store — (points − 1) / (hours + 2)^1.8 — computed when you look at it. newest, past, ask, show, jobs, threads: the same store, a different filter.

Step 2 — A Vote Is a Node You Own

On Hacker News a vote is a row in a table you cannot see. Here it is a node, and the node has an owner:

// No id: with `owner` on the value the engine names the node `${owner}:${uuid}`,
// and every peer refuses a write or a deletion from anyone else.
const create = async (value) => {
  await db.sm.executeWithPermission("write")          // the engine's own verdict, before the write
  return db.sm.acls.set({ ...value, at: Date.now() })  // the creator becomes the owner
}

await create({ type: "vote", item: storyId, dir: 1 })
await create({ type: "comment", text, parent: storyId, story: storyId })

db.sm.acls.set writes the node with the signer as owner; the engine checks that ownership on every path a node can arrive through — live from a peer, or in the catch-up when you come back — so a modified client cannot cast a vote in your name, and neither can the authority. Taking a vote back is a write of dir: 0 on your own node, never a deletion; the site keeps no history, but it never rewrites one either.

Step 3 — The Constitution Is a File

Everything that decides who may do what is in constitution.js, and the site renders that file, verbatim, on its constitution page. Two kinds of rule live in it, and the difference is the point:

roles: {
  guest:      { can: ["read", "sync"] },                                  // where everyone starts
  restricted: { can: ["read", "sync"] },                                  // lost the right to write
  user:       { can: ["write", "link", "sync"], inherits: ["guest"] },    // posts, comments, votes, flags
  superadmin: { can: ["assignRole"], inherits: ["user"] },                // the authority: signs roles, nothing else
},
rules: [ // evaluated in order, the last match wins
  { if: { role: "guest" }, offsetTimestamp: 10_000,                      then: { assignRole: "user" } },
  { if: { role: { $in: ["user", "restricted"] } },                       then: { assignRole: "user" } },
  { if: { role: { $in: ["user", "restricted"] }, karma: { $lte: -10 } }, then: { assignRole: "restricted" } },
],
thresholds: { gravity: 1.8, vouchKarma: 10, vouchPenalty: 5, flagKarma: 5, flagsToKill: 3, downvoteKarma: 20, deadScore: -5 },

Roles and rules are enforced by the engine. A guest's write is refused on every receiver. A role is only valid with the authority's signature, and the governance engine assigns roles from these rules — last match wins, so demotion is just another rule: fall to −10 karma and the third rule catches you, climb back and the second one does. It runs on whichever device the authority is signed in on: whoever presses the one-click identity. The engine can also give that key to an always-on superpeer — a real option, and a possible next step for dNews; today it runs on browsers alone.

Thresholds are derived by every peer. Three flags from trusted members with enough karma kill an item; a killed item stays visible in grey, with the reason, to anyone who turns showdead on. No moderator decided it, and anyone can recount it.

To change a rule, open a pull request. The discussion is public, the diff is the amendment, and the site renders the file as merged.

Step 4 — Writing Is Free, Influence Is Earned

A site where anyone can create an identity in a second has to answer one question: what stops a hundred fake accounts from voting a story to the top? Hacker News answers it with IP addresses and heuristics you cannot see. dNews answers it in the open:

// Trust is a chain of signed vouches that starts at the authority. A vote
// or a flag counts only from a trusted owner — a hundred fresh identities
// voting for each other add up to zero.
const trusted = new Set([AUTHORITY])
let grew = true
while (grew) {
  grew = false
  for (const v of vouches) {
    const from = v.value.owner.toLowerCase(), to = v.value.for.toLowerCase()
    if (trusted.has(from) && !trusted.has(to)) { trusted.add(to); grew = true }
  }
}
const countVote = (voter, dir) => trusted.has(voter) && (dir > 0 || upKarma.get(voter) >= T.downvoteKarma)

Anyone may post the moment the constitution makes them a user. But a vote or a flag counts only if its owner is trusted, and trust is a chain of vouches: a trusted member with enough karma vouches for a newcomer by writing a node only they could have written. Every profile says who vouched for whom, and vouching costs — a voucher loses karma for every invitee that ends up restricted. Sybil-resistant by a public web of trust, not sybil-proof; nothing open is, and the site says so on its constitution page.

Step 5 — Karma You Can Recount

The role rules read karma from each user's node, and a rule is only worth what the writer of its metric is worth — a number you write about yourself is self-service promotion. So the authority counts it: whoever holds that identity tallies the signed votes with the code above and writes the result on each user node, signed. Your own browser runs the same code over the same nodes, and the profile shows both numbers:

If the two ever differ, the authority is behind or lying — and everyone can see which. That is the part no forum with moderators can offer: you can audit the moderator, because the moderator is a file and a signature.

What It Does Not Do — and Why That Is the Design

Nobody edits or deletes anyone else's post. Not a moderator, not the authority: the engine has no path for it. What the community can do is kill an item, in the open, by the rule above.
Two members writing the same node at once never happens — every node has one owner. Two members voting at once are two nodes, and every peer counts both.
A mnemonic session lives in memory and ends with the tab; a passkey keeps it on the device. Your identity is a key pair, and the phrase is the only way back.
The engine holds one copy per visitor. Close every browser that has the site open and the graph sleeps until one comes back. An always-on superpeer would keep it awake — the engine offers one, dNews does not use it yet.

Run It

git clone https://github.com/estebanrfp/dNews && cd dNews
bun tests/server.mjs        # http://localhost:5705 — any static server will do

There is nothing to build: the engine arrives from a CDN with one import. ?room=anything opens a private sandbox of the whole site; the tests use it, and so can you. Three Playwright tests run one browser context per visitor over real WebRTC: a newcomer promoted by the constitution, a story and a thread crossing between peers, an unvouched vote that weighs nothing until someone vouches, and a device that comes back to find its graph on disk.

The examples catalogue has forty more pages built the same way, and the Security Manager guide and the governance guide cover every call used here.

⭐ Found this useful? Star GenosDB on GitHub — or spin it up in seconds: npm i genosdb.

This article is part of the official documentation of GenosDB (GDB).

GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

📰 Articles | concepts, tutorials and use cases

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

A Stream Overlay You Control From Your Phone — No Server, One File in OBS, Just GenosDB

Esteban Fuster Pozzi — Fri, 04 Sep 2026 20:05:08 +0000

The Usual Way Puts a Server Between You and OBS

Every overlay tool works the same way. Cloud widgets — StreamElements, Streamlabs — keep the state on their servers and make you log in. The self-hosted ones run a Node or Python process, an MQTT broker or a WebSocket relay on your machine, and your phone talks to that. In every case there is a machine, an account, or both, between the hand holding the phone and the Browser Source in OBS.

This tutorial removes the machine. One HTML file, no server, no accounts. Add its URL to OBS as a Browser Source; open the same URL with /control on your phone. The lower third, the ticker, the countdown and the alerts travel from the phone to OBS peer-to-peer, over WebRTC, through GenosDB — a graph database that lives in the browser and syncs between peers with nothing in the middle.

Live demo: obs-overlay.html — name a stream, then open the two links.
Source: one file on GitHub, about 430 lines.

The Whole Idea in Three Sentences

The name you give the stream is the link, and the link is the room. #friday-live is what OBS loads; #friday-live/control is what your phone opens. Both join the database named after the stream, and that database is the room every peer syncs in.
Three pieces are three nodes. The lower third, the ticker and the countdown each live in one node with a fixed id. Whoever holds the link can rewrite them, and every screen showing the stream repaints.
Alerts are moments, not state. A "new follower" pops on screen for four seconds and is gone. It rides an ephemeral channel and is never stored — the one rule the GenosDB API reference insists on: persistent state in the graph, transient events on the channel.

Step 1 — One File, Two Modes

import { gdb } from "https://cdn.jsdelivr.net/npm/genosdb@latest/dist/index.min.js"

const [key, mode] = location.hash.slice(1).split("/")   // "friday-live" · "control" or nothing
const db = await gdb(`overlay-${decodeURIComponent(key)}`, { rtc: true })

That is the whole backend. gdb(name, { rtc: true }) opens a local database under that name and joins the room of the same name; peers find each other through public relays that carry only the handshake, and the data itself goes directly between browsers over WebRTC. The phone and OBS are two peers of that room. So is a second phone, if a co-host opens the same link.

The rest of the file is an if: with mode === "control" the page draws the remote; without it, the overlay.

Step 2 — Three Pieces, Three Nodes

A fixed id per piece is safe here, because the database belongs to one stream. Writing is db.put with that id:

// { type: "lower-third", name, title, on }
// { type: "ticker",      text, on }
// { type: "timer",       label, endsAt, on }
const state = { "lower-third": null, ticker: null, timer: null }

const write = (id, patch) =>
  db.put((state[id] = { ...(state[id] ?? {}), type: id, ...patch }), id)

One detail is worth pausing on, because it is where the first bug lived. The patch lands on the local state before the put. Without that, two changes made in the same instant — a name typed, then the switch pressed — compose badly: the second one reads a state that is still a frame behind the first, and overwrites it. Typing, in the file, updates state on every keystroke and only writes after a 250 ms pause; a switch pressed mid-typing flushes the text with it. One put per pause, never one per key.

Step 3 — One Subscription Paints Every Screen

The overlay and every control panel share the same code for reading: one live query over the three types.

await db.map({ query: { type: { $in: ["lower-third", "ticker", "timer"] } } }, ({ id, value, action }) => {
  state[id] = action === "removed" ? null : value
  paint()   // the overlay slides the lower third in; the remote mirrors the switches
})

db.map with a callback fires once per existing node, then once per change — from this page, from the phone, from a second phone — through the same callback. There is no "send to OBS" step and no polling: OBS's page holds a live query, and the phone's put is what satisfies it.

Because the remote reads through the same subscription, two phones agree with each other: the switch you press shows as Showing on the co-host's phone the moment it lands.

Step 4 — A Countdown Nobody Ticks

The naive countdown sends "11:59", "11:58" … from the phone. This one sends nothing. The phone stores an end time, and every screen derives the remaining seconds on its own clock:

const remaining = () => Math.max(0, Math.ceil(((state.timer?.endsAt ?? 0) - Date.now()) / 1000))
const clock = (s) => `${String(Math.floor(s / 60)).padStart(2, "0")}:${String(s % 60).padStart(2, "0")}`

// on the phone
$("timer-start").addEventListener("click", () =>
  write("timer", { endsAt: Date.now() + minutes * 60_000, on: true }))

One node, written once. OBS, a second OBS, and both phones show the same second, and the room carries no traffic while the timer runs. If a clock is off by a second, that screen is off by a second — which is the honest cost of having no server clock, and the same cost every distributed timer pays.

Step 5 — Alerts Are Moments, Not State

An alert is the opposite kind of thing. Nobody needs to know, an hour later, that ada_lovelace followed at 18:04:12. So it never touches the graph:

const alerts = db.room.channel("alerts")

// phone
alerts.send({ text: "New follower: ada_lovelace" })

// overlay
alerts.on("message", ({ text }) => {
  const card = document.createElement("div")
  card.className = "alert"          // pops in, stays 4 s, fades — pure CSS
  card.textContent = text
  $("alerts").append(card)
  card.addEventListener("animationend", () => card.remove())
})

db.room.channel(name) is GenosDB's ephemeral lane: a named data channel to every peer in the room, no persistence, no catch-up. An overlay that joins later never sees old alerts, and that is correct — it also never sees old cursor positions in a collaborative editor, which is the same idea. The rule from the API reference is one question: does this need to survive a reload? The lower third does. An alert does not.

Step 6 — Put It in OBS

In OBS, add a Browser source to your scene.
URL: the overlay link (the one without /control). Width 1920, height 1080.
Open the control link on your phone. Type a name, press Showing.

OBS's Browser Source is Chromium, and it injects a window.obsstudio object into every page it loads. The file uses that to decide what to paint:

if (!window.obsstudio) {
  document.body.classList.add("stage")       // an ordinary browser: a dark stage with the two links
  $("stage-hint").classList.remove("hidden")
}

Inside OBS the body stays transparent and only the pieces paint. Anywhere else, the same URL shows a dark stage with the overlay on it and the control link underneath, so the file explains itself when someone opens it by hand.

What It Does Not Do — and What It Would Take

Whoever has the link controls the overlay. For a stream that is exactly right — you, a co-host, a moderator you trust — and the link is not something you post in chat.
Two phones editing the same field at the same moment: both edits survive when they touch different parts of it; only the same words at the same instant are the later writer's, deterministically on every peer. Different pieces never collide.
No history, no undo, by design: three nodes hold the present, and alerts hold nothing.

All of that is one decision — no identity — and GenosDB has the layer for the day the overlay needs one: a Security Manager that gives each phone a cryptographic identity, signs every operation, and lets a node carry an owner so only its author, and whoever they grant, can change it — enforced by every peer, not by a server. The Security Manager guide covers it; for an overlay it is a configuration option.

Run It

Open the live demo, name a stream, and paste the overlay link into OBS. Or save the file and serve it from anywhere static; the only dependency is one import:

import { gdb } from "https://cdn.jsdelivr.net/npm/genosdb@latest/dist/index.min.js"

The examples catalogue has forty more pages built the same way — the thermostat is this overlay's smaller sibling, one tab commanding another — and the API reference covers every call used here.

⭐ Found this useful? Star GenosDB on GitHub — or spin it up in seconds: npm i genosdb.

This article is part of the official documentation of GenosDB (GDB).

GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

📰 Articles | concepts, tutorials and use cases

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

Build a Splitwise-Style Expense Splitter With No Backend — 500 Lines, No Accounts, Just GenosDB

Esteban Fuster Pozzi — Fri, 04 Sep 2026 20:04:58 +0000

What the "Clone" Guides Don't Tell You

Search for how to build an app like Splitwise and you get two kinds of answers. Agencies quote 12 to 24 weeks and a five-figure budget. GitHub clones — MERN, Appwrite, Firebase — hand you a server, a database, an auth flow and a deployment before a single expense is split.

Both are answering a question you may not have asked. An expense splitter is a small problem: a few people, a list of who paid what, and one number per person. The size comes from the infrastructure, not from the problem.

This tutorial builds the whole thing in one HTML file, about 500 lines, with no server and no accounts. Two phones open the same link and see the same balances, live. Here is the finished app with a four-person trip loaded:

Live demo: split-expenses.html — open it in two windows.
Source: one file on GitHub.

It runs on GenosDB, a graph database that lives in the browser and syncs peer-to-peer over WebRTC. Everything below is plain JavaScript against its API.

The Whole Idea in Three Sentences

The group is the link. The name you give the group becomes the URL, and the URL is the room every device syncs in. Whoever holds the link is in — there is no invitation table because there is no table.
An expense is a node. Who paid, how much, split among whom. That is everything the app stores.
A balance is never stored. It is derived, on every change, from the whole set of expenses — which is what makes the sync visible: two windows either show the same balances or you can see they have not converged yet.

Everything else is HTML.

Step 1 — The Group Is the Link

import { gdb } from "https://cdn.jsdelivr.net/npm/genosdb@latest/dist/index.min.js"

// The link carries the group's name; the name is the database name; the
// database name is the room every peer syncs in.
const group = decodeURIComponent(location.hash.slice(1))
const db = await gdb(`split-${group}`, { rtc: true })

That is the entire backend. gdb(name, { rtc: true }) opens a local database under that name — persisted in the browser's own storage — and joins the room of the same name. Peers discover each other through public relays that carry nothing but the handshake; the data itself travels directly between browsers over WebRTC. Close every tab and the data is still on each device; open one again and it syncs with whoever is there.

When the page opens without a hash, it shows a single field: Name your group. Submitting it writes the name into the hash and reloads. Sharing the link is the invitation.

Step 2 — People and Expenses Are Nodes

A person is a node. An expense is a node. Both are written with db.put, which returns the node's id:

// A person
await db.put({ type: "member", name: "Alice", at: Date.now() })

// An expense: who paid, how much (integer cents), split among whom
await db.put({
  type: "expense",
  title: "Dinner",
  cents: 9600,
  payer: aliceId,
  split: [aliceId, bobId, carolId, danaId],
  at: Date.now()
})

Amounts are integer cents, never floats. That is not pedantry: every peer will compute the balances on its own, and 0.1 + 0.2 is how two devices end up disagreeing by a cent forever.

Nothing else is written. There is no balances collection, no group document holding totals, no counter to keep in step. If you have ever debugged a cached total that drifted from its source, you know why.

Step 3 — Two Live Queries Feed One View

The page subscribes once to each kind of node, and lets the engine sort:

await db.map({ query: { type: "member" }, field: "at", order: "asc" }, ({ id, value, action }) => {
  action === "removed" ? members.delete(id) : members.set(id, value)
  renderMembers()
  renderBalances()
})

await db.map({ query: { type: "expense" }, field: "at", order: "desc" }, ({ id, value, action }) => {
  if (action === "removed") { expenses.delete(id); rowOf(id)?.remove() }
  else {
    expenses.set(id, value)
    const row = buildExpenseRow(id, value)
    if (action === "initial") list.append(row)       // arrives already newest-first
    else if (action === "added") list.prepend(row)   // newest by definition
    else rowOf(id)?.replaceWith(row)                 // updated: rebuilt in place
  }
  renderBalances()
})

db.map with a callback is a live query. It fires once per existing node (initial), then once per change — added, updated, removed — whether the change came from this window, another tab, or another device. There is no polling, no "refresh" button, and no second code path for remote changes: a peer's expense arrives through exactly the same callback as your own.

Two things fall out of this for free. A device that was offline writes locally and syncs when it is back — the callback fires on the other devices as if the expense had just been added. And a device that opens the link for the first time receives the whole set from whoever is online, one initial event per node.

Step 4 — A Balance Is a Sum Over Everything That Arrived

This is the heart of the app, and it is fourteen lines:

const balances = () => {
  const balance = new Map([...members.keys()].map((id) => [id, 0]))
  for (const { cents, payer, split } of expenses.values()) {
    const parts = split.filter((id) => balance.has(id)).sort()
    if (!parts.length || !balance.has(payer)) continue
    const share = Math.floor(cents / parts.length), rest = cents - share * parts.length
    balance.set(payer, balance.get(payer) + cents)
    parts.forEach((id, i) => balance.set(id, balance.get(id) - share - (i < rest ? 1 : 0)))
  }
  return balance
}

What you paid, minus your share of everything you took part in, over every expense. It runs on every change, and it costs nothing at the scale of a group.

Two details make it converge everywhere:

The split rounds down and hands the leftover cents to the first participants in id order. 10.00 among three is 3.34, 3.33, 3.33 — and which person gets the extra cent is decided by sorting ids, so every device decides the same.
The balances of a group therefore sum to exactly zero, always. If your app ever shows a group that does not, it is not a rounding bug: it is two peers that have not converged yet.

That second point is the reason to build the app this way. A stored total can be wrong quietly. A derived total is wrong visibly — and only until the last expense arrives.

Step 5 — Who Pays Whom

Settling up is the classic greedy pass: the largest debtor pays the largest creditor, repeat. It produces at most n − 1 transfers, and ties break on id so every peer lists the same ones:

const settleUp = (balance) => {
  const byOwed = (a, b) => b.cents - a.cents || (a.id < b.id ? -1 : 1)
  const debtors = [...balance].filter(([, c]) => c < 0).map(([id, c]) => ({ id, cents: -c })).sort(byOwed)
  const creditors = [...balance].filter(([, c]) => c > 0).map(([id, c]) => ({ id, cents: c })).sort(byOwed)
  const transfers = []
  for (let i = 0, j = 0; i < debtors.length && j < creditors.length;) {
    const cents = Math.min(debtors[i].cents, creditors[j].cents)
    transfers.push({ from: debtors[i].id, to: creditors[j].id, cents })
    if (!(debtors[i].cents -= cents)) i++
    if (!(creditors[j].cents -= cents)) j++
  }
  return transfers
}

And when someone actually pays? A settlement is one more expense — paid by the debtor, split among exactly one person, the creditor:

db.put({ type: "expense", kind: "payment", title: "Settlement", cents, payer: from, split: [to], at: Date.now() })

No special case, no second node type, no "mark as settled" flag to keep in sync. The derived balances close by themselves, and the transfer disappears from the list on every device.

Step 6 — Open It in Two Windows

Add three people in one window. Add a dinner paid by Alice. The other window shows Alice +20.00 · Bob −10.00 · Carol −10.00 the moment the node lands. Add a taxi from the second window, split between two — both windows now agree on +15.50 · −5.50 · −10.00 and on the same two transfers. Mark one as paid, and it is gone from both.

Nothing in the page compares states or reconciles totals. It cannot: there is no total to reconcile. Each window derives its numbers from the expenses it holds, and the expenses are what the database keeps identical. When the sets are equal, the numbers are equal, and you can see it.

What It Does Not Do — and What It Would Take

This is a tutorial, and it is honest about its scope:

Anyone with the link can add, edit and delete anything. That is the Splitwise-with-friends model, and it is fine for a trip. It is not fine for strangers.
Two people editing the same expense at the same moment: both edits survive when they change different things — the amount and who paid, say; only the same field at the same instant is the later writer's, on every peer. Different expenses never collide.
The group's name is the link, so a guessable name is a guessable group.

All three are the same decision — no identity — and GenosDB has the layer for the day you want it: a Security Manager that gives each device a cryptographic identity (a passkey, or a recovery phrase), signs every operation, and lets a node carry an owner so that only its author — and whoever they grant — can change it, enforced by every peer rather than by a server. Adding it to this app is a configuration option and one field per node; the Security Manager guide and the zero-trust model cover it.

Run It

Open the live demo in two windows, or save the file and open it from any static host. The only dependency is one import:

import { gdb } from "https://cdn.jsdelivr.net/npm/genosdb@latest/dist/index.min.js"

The examples catalogue has forty more pages built the same way, and the API reference covers every call used here.

⭐ Found this useful? Star GenosDB on GitHub — or spin it up in seconds: npm i genosdb.

This article is part of the official documentation of GenosDB (GDB).

GenosDB is a distributed, modular, peer-to-peer graph database built with a Zero-Trust Security Model, created by Esteban Fuster Pozzi (estebanrfp).

📄 Whitepaper | overview of GenosDB design and architecture

🛠 Roadmap | planned features and future updates

💡 Examples | code snippets and usage demos

📖 Documentation | full reference guide

🔍 API Reference | detailed API methods

📰 Articles | concepts, tutorials and use cases

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn