DEV Community: Esteban Fuster Pozzi

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

GenosDB vs Yjs and Automerge: Real-Time Collaboration Without a CRDT Library

Esteban Fuster Pozzi — Mon, 31 Aug 2026 17:58:45 +0000

The Problem Everyone Solves the Same Way

Two people open the same document. Both type. Nobody loses a word.

The standard answer to that requirement is a CRDT library — usually Yjs or Automerge. Both are excellent, and both solve the hardest part of the problem: merging concurrent edits without a coordinator. But a CRDT library is a merge engine, not an application backend. Once it is in place, the rest of the system is still missing — and most of what is missing is what your app actually spends its code on.

This article looks at what each library does, what it leaves for you to build, and how the same live experience can be reached with a database that already carries the missing pieces.

What Yjs Actually Does

Yjs is a shared-types library built on YATA, a sequence CRDT. Its data structures — Y.Text, Y.Array, Y.Map — merge concurrent operations deterministically, so every peer converges on the same document regardless of arrival order.

Its strengths are real and worth naming:

Character-level merge. Two cursors inside the same sentence interleave correctly. This is the hard case, and Yjs handles it.
State vectors. A peer describes what it has as {clientID → clock}, and the other side computes an exact delta. Efficient when writers are few and stable.
Editor bindings. Adapters exist for ProseMirror, CodeMirror, Monaco, Quill and TipTap — separate packages, each on its own release cycle.
Pure JavaScript, with tombstone garbage collection and Y.mergeUpdates for compacting history without instantiating a document. A Rust port (yrs) exists for native peers.

What Yjs is not, by design, is a stack. It is a merge engine, and everything around it is a separate decision:

Transport. The public demos run against a y-websocket server. There are WebRTC providers, but the well-trodden path — the one every tutorial takes — is a server relaying updates.
Persistence. y-indexeddb is a separate package, wired by you.
Identity, permissions, queries. Not in scope. A Yjs document has no concept of who wrote what, no roles, and nothing to query — it is a document, not a database.

One detail is worth pulling out, because it shapes everything below: awareness — the cursors, selections, names and colours you see moving on screen — is not CRDT data even in Yjs. It travels on a separate, ephemeral protocol and dies with the session. Yjs made that call deliberately: presence is not history, so it should not pay the price of history.

What Automerge Actually Does

Automerge takes a different route: an operation-based CRDT with full history. Every change is a node in a hash-addressed DAG — the same idea as a Git commit graph — so a document carries its own past, and time travel and per-character attribution come for free.

Its strengths:

Character-level merge, like Yjs, plus rich text with marks.
History as a first-class citizen. Every version is reachable and every change is attributable, without you designing a versioning scheme.
Efficient sync protocol. Peers exchange heads plus Bloom filters; identical heads mean nothing is transferred.
Cross-platform core in Rust, compiled to WASM for the browser.

And its costs, which are the flip side of the same design:

A document never forgets. History is the data model, so opening a long-lived document means loading its past, and the cost grows with the document's lifetime rather than with its current size.
WASM in the bundle. Fine for most apps, awkward for some environments and for cold-start budgets.
Access control is a separate layer. Keyhive is the answer being built for it, and it is explicitly experimental.
A sync server in the standard setup. automerge-repo ships one, and the documented path uses it.

The Dividing Line, Stated Plainly

There is exactly one thing these libraries do that a plain database does not: interleave two edits inside the same span of text, at the same instant, character by character. It is a narrower case than it sounds. Two people typing into the same paragraph at once keep both edits when they touch different places: the store keeps the winner, and the writer whose write lost the race re-applies its own edit over it as an ordinary signed write — no CRDT, no merged value that nobody signed (how it works). Only the same span at the same instant is the later writer's, with both carets in view — and an application that needs even that can add it itself, keystroke by keystroke on the ephemeral channel, where it needs it rather than everywhere. The Keystrokes example does exactly that: one paragraph everyone types into at once, inside the same word if you like, with the channel and the graph shown side by side as they happen.

That capability is genuinely hard to build, and it is the reason both projects exist. It is also, in the collaborative applications most teams actually ship, the rarest case in the room — and the one that human beings avoid on their own the moment they can see where everyone else is standing. That is the observation Notion, Linear and every block editor since have been built on: make presence visible and collisions mostly stop happening.

Everything else people reach for a CRDT to get — concurrent edits across a document, ordering that survives simultaneous inserts, offline writes that reconcile on reconnect, live cursors — does not require a sequence CRDT at all. It requires the right granularity and a presence channel.

The Other Path: One Node per Paragraph

GenosDB is a peer-to-peer graph database, not an editor library. But because a document can be modelled as data, collaborative editing falls out of the database's own primitives. The live example is a continuous document — write, press Enter, keep writing — implemented in one HTML file with no editor framework and no CRDT dependency. The technique has four parts:

A paragraph is a node. Editing a paragraph rewrites only that node, so two people working on different paragraphs never overwrite each other — there is no shared node to fight over. Last-write-wins is a problem only when two writers share a node, and at paragraph granularity they usually do not — and when they do, both edits survive unless they touch the same span.
Fractional order keys. A paragraph inserted between order 1 and 2 gets a key in the gap. Two peers inserting into the same gap concurrently mint different keys, so both survive, and every peer sorts them identically — an engine guarantee, see Ordering, Precisely below. No counters to coordinate, no rebalancing to synchronise.
Structure is graph operations. Enter splits a paragraph into two nodes; Backspace at the start merges a paragraph into the previous one and deletes it; pasting multi-line text creates one node per line. Concurrent structural edits land on different nodes, so they compose instead of conflicting.
Awareness on an ephemeral channel. Named, coloured carets and live selections travel over a GenosRTC data channel and never touch the graph — the same architectural decision Yjs made, reached from the same reasoning. And the paragraph being typed is broadcast keystroke by keystroke, so remote windows move character by character, while the debounced database write remains the truth that persists and repairs.

The result behaves like the CRDT demos: type in one window, watch it appear letter by letter in the other, with a named cursor showing where your collaborator is.

Every window is a separate peer. The coloured cursors and selections travel on the ephemeral channel; the text itself lives in the graph.

Ordering, Precisely

The second bullet above makes a promise that deserves a mechanism: every peer sorts them identically. Here is exactly what holds it up, and where it stops.

A key is a double. A paragraph inserted between order 1 and 2 gets a key at a random point in the gap — random so that two peers inserting into the same gap at the same instant mint different keys, and both survive. A float64 carries 53 bits of mantissa, and each insert into the same gap keeps about half of what is left: after roughly fifty successive inserts between the same two paragraphs, the next key rounds onto its neighbour and the two tie. Typing a document top to bottom never gets there, because every new paragraph opens a fresh gap of one. A multi-line paste is the one action that would, so it mints its keys in a single batch: the gap is divided once, into one slot per line, and each line lands inside its own slot. Two hundred pasted lines spend about eight bits of the mantissa instead of exhausting all fifty-three.

Same gap, same scale. Inserting one key at a time halves what is left until a key lands on the neighbour; a paste divides the gap once and never gets close.

The example draws this live. Beside the document, every paragraph's key sits on a number line, to scale: the four warm dots are a paste that just landed, spread once across one gap, and the panel says how many halvings the gap under the caret has left.

One peer's window. The other peer's named caret sits in the last paragraph; on the right, the keys the paragraphs are sorted by, the paste's four dots still warm and the gap under the caret with 47 halvings left.

The engine settles ties. A sorted db.map breaks a tie on the node id, in the direction of the sort. Two replicas holding the same nodes read results, the initial events and every $limit/$after page in the same order, whatever order their nodes arrived in, and desc is the exact reverse of asc. Before, a tie fell to arrival order, which differs on every peer, and the examples had to compensate by hand. The rule costs one comparison per tie and thirty-nine bytes gzipped.

Where the key lives is the whole difference. Bartosz Sypytkowski, who maintains Yrs — Yjs in Rust — arrived at the same trade from inside the CRDT world. Scaling fractional indexes to a million spreadsheet rows, he sets interleaving aside as a cost the granularity absorbs, and spends his design on packing each key into eight bytes and on a move semantics of tombstones and pointers. He needs that machinery because in his model the key is the row's identity: to move a row you delete it and insert another, and two concurrent moves leave two rows unless a move CRDT reconciles them. In GenosDB the node id is the identity and order is a field it carries. Moving a paragraph is one put; two peers moving the same paragraph at once resolve, by last-write-wins on the hybrid logical clock, to one paragraph in one place — no tombstone, no pointer, no second key space.

In a fractional-index CRDT the key names the row, so a move is a delete plus an insert. In GenosDB the id names the paragraph and position is a value it carries, so a move is the write it already knows how to do.

The same technique, taken to code, is the subject of the next article: A GitHub With No Server applies one-node-per-line editing to a code editor and adds what GitHub runs servers for — owned commits, branch protection and pull requests — from the same graph.

That is also the honest boundary. There are no string keys, no rebalancing and no move CRDT here, by design: a document is hundreds of blocks, not a million rows, and the float, the batch and the tie rule cover that range with nothing to maintain. Should a table with a million rows ever be the target, his post is the map. The pattern, its limit and the engine's rule are written up in the Ordered Lists guide.

The same keys now run a second example, a spreadsheet: rows and columns are identities, position is a key, and a cell is a node named after its row and its column — so a row moves with its cells in one put, and a column inserted in the middle shifts the letters, not the data. It also answers the figure that opens his post: Alice and Bob typing into A3 of an empty sheet while apart, and ending with six rows and two cells. Here the base grid is never written. A row nobody inserted has the same id and the same key on every peer, so both write the same cell and end with one value — his virtual key, at no cost.

Why the Path Is Shorter

Both approaches produce live text on a remote screen. The difference is what a single keystroke has to do to get there.

In the standard CRDT setup, a keystroke is encoded into one or more CRDT operations, sent to a sync server, relayed to each peer, integrated into the receiving replica's structure, and rendered back through an editor binding. Every step is fast; there are simply several of them, and one of them is a round trip through infrastructure you have to run.

In the block-editor example, a keystroke is one hop over a direct WebRTC data channel — coalesced to at most one message per animation frame — and the receiver assigns a string to a native textarea. No encoding step, no integration step, no binding, no server. The graph write that persists it happens behind the live view, debounced, and repairs anything the network dropped.

That is an architectural difference, not a benchmark: fewer stages and no relay hop. It is also why the demo is a single file you can save and open, with nothing to deploy.

What Comes in the Same Package

This is where the comparison stops being about merge algorithms. A CRDT library gives you a document. GenosDB gives you a database that happens to be able to hold one — so the surrounding application does not need a second stack:

Queries. db.map({ query, field, order, $limit }) — filters, ordering, pagination, full-text matching and recursive graph traversal with $edge. A document is a query result, not a special case.
Identity. Cryptographic, sovereign identities with mnemonic recovery and WebAuthn passkeys built in. Every operation can be signed by its author.
Permissions. Role-based access control and node-level ACLs, enforced independently by every peer against the verified signer — a zero-trust model, not a client-side courtesy.
Encryption. Field-level and record-level, with cryptographic read revocation.
Persistence. OPFS-backed, offline by default. No adapter to choose.
Transport. WebRTC peer-to-peer with automatic peer discovery and a Cellular Mesh overlay that keeps connection counts flat as rooms grow, instead of the O(n²) full mesh. No sync server anywhere in the picture.

None of that is bolted on for the editor: it is the same engine every other GenosDB application uses. The editor is roughly two hundred lines on top of it.

Offline Is Not a Feature You Add

The claim worth testing in a peer-to-peer system is not what happens while everyone is connected — it is what happens when they are not.

Run the example across multiple devices, disconnect the network entirely, write a different paragraph on each one, and reconnect. Every document converges, no matter how many peers wrote offline or in which order — because the graph is stored locally, the operation log carries what each peer missed, and a state digest lets converged peers exchange nothing at all. The live cursors come back on their own.

That behaviour is not editor code. It is the database doing what it does for every application built on it.

What the Choice Actually Is

The choice is not between three merge algorithms. It is between a library that owns your document and a database that holds it:

A sequence CRDT — Yjs, Automerge — owns the document. It interleaves keystrokes inside the same words, and in Automerge's case keeps the whole history. It does so blindly: after hours apart, two versions of a paragraph are woven into a text nobody wrote, with no conflict to show anyone. It comes as a library with its own data model, metadata that grows with every character ever typed, and a sync server or a second transport beside it.
GenosDB holds the document as data. Two people on the same paragraph keep both edits when they touch different places; the same span at the same instant is the later writer's, in view, never woven; and an application that needs keystroke-level interleaving adds it where it needs it, on the ephemeral channel, instead of paying for it everywhere. Queries, identity, permissions, encryption, offline persistence and peer-to-peer transport come with the same nodes, and every value is one writer's, signed.

They are not mutually exclusive, either. Because GenosDB stores arbitrary values, binary CRDT updates can travel as ordinary nodes in the graph — the transport, persistence, identity and access control come from the database, and the merge engine stays whatever you chose. The point is not that CRDTs are unnecessary. It is that most collaborative applications reach for one to get things a database should already give them.

Try It

The example is a single HTML file, with no build step and nothing to deploy:

👉 Open the Block Editor — then open it again in a second window and type in both.
📄 Read the source — the technique is documented in comments, in place.
⌨️ Open Keystrokes — the narrow case, added where an app wants it: one paragraph everyone types into at once; on the right, the channel keystroke by keystroke, the graph snapshot by snapshot, and a hash proving every window shows the same text.
🧮 Open the Spreadsheet — the same keys in two dimensions; type into A3 in both windows and watch one cell, not two rows.
🌿 Open dCode — the block editor's technique on a code editor: one node per line, named carets, the page running beside the code as you type, and underneath it a code host with branches, forks and pull requests, every commit signed, owned and runnable. No server. The sequel to this article, A GitHub With No Server, explains how.
🧭 See how GenosDB compares across other P2P and distributed databases, or read the full GunDB guide if that is where you are coming from.

⭐ 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

GenosDB + GenosRTC: A Scalable Browser-Native P2P Graph Database with Cellular Mesh WebRTC Architecture

Esteban Fuster Pozzi — Fri, 17 Jul 2026 11:22:34 +0000

When comparing GenosDB + GenosRTC against the current browser-P2P ecosystem — Gun, PeerJS, simple-peer, Trystero, y-webrtc — it is important to distinguish between two very different things: exceptional execution of existing technologies and genuine architectural innovation.

GenosDB delivers both. This article breaks down exactly where each one lives, with architecture diagrams and links to the full technical documentation.

📦 npm: genosdb
🗂 Repository: github.com/estebanrfp/gdb
📖 Documentation index: docs/index.md
📄 Whitepaper: WHITEPAPER.md
🧠 Wiki: GitHub Wiki · DeepWiki

What is GenosDB?
The Full Stack at a Glance
Layer 1 — Production-Grade P2P Signaling (GenosRTC)
Layer 2 — The Real Innovation: Cellular Mesh
Layer 3 — The Database Engine: Delta Sync, HLC, Last-Write-Wins
Layer 4 — Zero-Trust Security: RBAC, ACLs, Governance
Market Comparison
Why the Combination Is the Moat
Getting Started in 30 Seconds
FAQ
Documentation Map

What is GenosDB?

GenosDB (GDB) is a distributed, modular, peer-to-peer graph database that runs entirely in the browser — no servers, no backend, no infrastructure. It combines:

A graph data model (nodes + directed edges) with a rich query engine — see the GDB API Reference and Features overview
Real-time P2P synchronization over WebRTC via GenosRTC
A Zero-Trust Security Model with cryptographic identities, WebAuthn, RBAC, node-level ACLs, and rule-based governance
Zero runtime dependencies, with geospatial $near queries built into the engine

Your Web App
    │
    │ await gdb("my-db", { rtc: true })
    ▼
GenosDB
│
├─► Query Engine      (20+ operators, $edge, $near)
│
├─► Security Manager  (RBAC · ACLs · WebAuthn)
│
└─► Sync Core         (HLC · oplog · LWW)
     │
     ├─► Persistence Worker  (OPFS → IndexedDB)
     │
     └─► GenosRTC            (WebRTC + Nostr + Cells)
          │
          ▼
     Other Peers (P2P)

The Full Stack at a Glance

The platform is built as four independent layers. The first one is excellent engineering on known ideas. The other three are where the architectural differentiation lives.

Layer	Technology	Status vs. market
Signaling & transport	WebRTC + Nostr relays	Production-grade execution
Network topology	Cellular Mesh overlay	No browser-native equivalent
Data consistency	HLC + oplog delta sync + per-node last-write-wins, and concurrent writes to one node keep both	Rare in browser P2P
Security	Zero-trust RBAC + ACLs + signed governance	Unique vertical integration

Layer 1 — Production-Grade P2P Signaling (GenosRTC)

Decentralized WebRTC signaling over Nostr is not new. The implementation details are what matter — and GenosRTC's details are production-grade (full architecture breakdown):

Pool of 5 pre-generated WebRTC offers for near-instant connection establishment — no offer-generation latency on peer discovery
Intelligent relay management: primary relays plus adaptive fallback strategies with dynamic scheduling
Automatic detection and exclusion of relays demanding Proof-of-Work, keeping signaling latency predictable
Connectivity-aware reconnection driven by browser online/visibility events with exponential backoff
AES-GCM SDP encryption with SHA-256(secret:appId:roomId) key derivation — signaling metadata is never readable by relays
16KB chunked transfers with binary metadata and per-chunk progress tracking
Audio/video streaming with track replacement and per-stream metadata (GenosRTC guide)

Nostr Relays
    │
    │ peer discovery only
    ▼
Peer A announces topic
    │
    ▼
Peer B discovers Peer A
    │
    ├─► OFFER    (pooled, AES-GCM SDP)
    │
    └─► ANSWER   (encrypted)
         │
         ▼
Direct WebRTC channel   (E2E, no relays)
│
├─► named channels
│
├─► 16KB chunks + progress
│
└─► audio/video streams

Libraries such as PeerJS or simple-peer do not even address the signaling problem — they assume you run your own signaling server. Finding all of these concerns solved together, in a dependency-free package, is rare.

However, the true differentiation is not the signaling layer.

Layer 2 — The Real Innovation: Cellular Mesh

Cellular Mesh was designed to solve the fundamental scalability problem of every traditional WebRTC full-mesh architecture: O(N²) connection growth.

Solutions such as Trystero, PeerJS, Gun, and y-webrtc all ultimately rely on topologies that become increasingly inefficient as peer counts grow. In practice, these architectures hit serious performance and stability limitations once networks reach dozens of simultaneous participants:

FULL MESH (market standard)
    │
    │ N·(N-1)/2 connections
    ▼
  8 peers  →    28 links
 50 peers  → 1,225 links
100 peers  → 4,950 links  💥

CELLULAR MESH (GenosRTC)
    │
    │ ~O(N) connections
    ▼
Peers
│
├─► Cell A   ● ● ● ◉
│
├─► Cell B   ● ● ● ◉
│
└─► Cell C   ● ● ● ◉

◉ bridge peer   (deterministically elected)
│
└─► forwards to neighbor cells
     (cell → bridge → cell, TTL-bounded)

GenosRTC addresses this with a self-organizing Cellular Mesh overlay that currently has no direct equivalent in the browser-P2P market:

Deterministic cell assignment — nodes are mapped to cells with no coordinator and no negotiation
Epoch-sealed topology — the whole layout derives from a sealed roster snapshot; a room of N peers forms ceil(N / cellSize) cells (one knob, default 10), and no topology data ever travels the wire
Deterministic bridge election with succession — one bridge per cell, chosen by a per-cell hash of the sealed roster, with no coordinator and no negotiation; the rank order doubles as a succession line, so a dead bridge is replaced at the next seal without a single message
Total cell isolation — enforced at three independent layers, so inter-cell data flows exclusively through elected bridges:

cell isolation  (three independent layers)
│
├─► connections   exist only along sealed roles
│
├─► sending       every frame audience-targeted at the source
│
└─► receiving     a role guard drops anything else

Dynamic TTL — message propagation uses TTL = min(150, ceil(log2(cells + 1)) * 2 + 3), so flood depth adapts to the actual topology instead of being a magic number
Ring-buffer deduplication — duplicate suppression over the last 5,000 message IDs, preventing routing loops at near-zero memory cost
Bye beacons and census-driven membership — a departing peer clears itself from the census in one relay hop; cleanup follows the sealed roster, and topology changes collapse into atomic epoch seals

The result is a structured, self-organizing overlay network running entirely on pure browser WebRTC. A live visualization is available in the repository: the mesh monitor.

Conceptually, the closest comparison is libp2p + gossipsub. But that approach requires substantially more infrastructure, a significantly heavier stack, and far greater operational complexity. No existing browser-native solution provides a comparable architecture as a lightweight, transparent overlay enabled with a single flag:

const db = await gdb("my-app", { rtc: { cells: true } })

To the best of our knowledge, Cellular Mesh is not an evolution of an existing browser-P2P pattern — it is a fundamentally different networking model, and today it remains unique to GenosRTC.

Layer 3 — The Database Engine: Delta Sync, HLC, Last-Write-Wins

A scalable transport is useless without a consistency model that survives it. GenosDB pairs Cellular Mesh with a sync engine designed for hostile network conditions:

Hybrid Delta Protocol

The Hybrid Delta Protocol is a dual-mode engine: delta updates for speed, full-state fallback for reliability.

Peer reconnects (watermark T)
    │
    ▼
does the oplog still cover T?
│
├─► YES → DELTA SYNC
│    │
│    └─► only ops newer than T
│        (MessagePack + compressed)
│
└─► NO → FULL-STATE SYNC
     │
     ├─► compressed graph snapshot
     │
     └─► reset oplog + watermark

Hybrid Logical Clocks + LWW

Every operation carries an HLC timestamp {physical, logical} guaranteeing causal ordering without trusting wall clocks. Conflicts resolve deterministically via Last-Write-Wins, with clock-skew capping so a peer with a broken clock cannot poison the graph. Two peers writing the same node at the same instant, each over the same value, keep both contributions: the store keeps the winner, and the peer whose write lost re-applies its own edit over it as an ordinary signed write — fields from whoever changed them, the one region each side changed in a string, the winner's for the same span (how it works). No CRDT and no metadata persisted.

Non-Blocking Persistence

A dedicated persistence worker writes through a tiered storage strategy — synchronous OPFS → async OPFS → IndexedDB — with cross-tab safety via the Web Locks API. Large graph saves never block the UI.

Query Engine

The map() query engine supports 20+ operators — comparison, logical, text/regex/like, cursor-based pagination ($after / $before / $limit), and the recursive $edge graph-traversal operator — all with real-time subscriptions. Full CRUD docs: put · get · link · remove · overview.

Layer 4 — Zero-Trust Security: RBAC, ACLs, Governance

This is where vertical integration becomes a moat. In a P2P network you cannot trust any peer — so GenosDB assumes none of them (Distributed Trust Model, Zero-Trust Security Model):

op arrives from the network
    │
    │ every peer verifies it
    ▼
verify ECDSA signature      ✗ reject
    │ (recover the signer)
    ▼
check RBAC role + expiry    ✗ reject
    │ (guest → superadmin)
    ▼
check node-level ACLs       ✗ reject
    │ (verified signer only)
    ▼
apply to graph

Cryptographic identity: every user is an ECDSA keypair, protected by WebAuthn passkeys or recoverable via BIP39 mnemonic (SM API Reference, SM Architecture)
Hierarchical RBAC with role expiry — guest → user → manager → admin → superadmin, every grant signed by an authorized signer
Node-level ACLs — owner/collaborator permissions per node, enforced against malicious peers: the permission check uses the cryptographically verified signer, never a claimed identity (ACLs Module)
Rule-based governance — automatic role promotion/demotion where rule conditions are native GenosDB queries, evaluated last-match-wins and signed by an online superadmin (Governance Guide)

Every operation can be cryptographically validated. Every identity can be independently verified. Every node enforces ACL policy without centralized infrastructure and without assuming any other peer is trustworthy.

Market Comparison

Capability	GenosDB + GenosRTC	Gun	Trystero	PeerJS / simple-peer	y-webrtc
Serverless signaling	✅ Nostr	⚠️ needs relays	✅ Nostr et al.	❌ own server	⚠️ signaling server
Scalable topology (>100 peers)	✅ Cellular Mesh	❌	❌ full mesh	❌ full mesh	❌ full mesh
Graph data model + queries	✅ 20+ operators, `$edge`	⚠️ graph, limited queries	❌ transport only	❌ transport only	❌ (Yjs CRDT docs)
Delta sync + full-state fallback	✅	⚠️	❌	❌	⚠️ Yjs
Causal ordering (HLC)	✅	❌	❌	❌	⚠️ vector-ish
Zero-trust RBAC + role expiry	✅ signed, enforced	❌	❌	❌	❌
Node-level ACLs vs malicious peers	✅	⚠️ SEA (different model)	❌	❌	❌
Rule-based governance	✅	❌	❌	❌	❌
Runtime dependencies	0	several	minimal	several	Yjs stack

A note on Gun: its SEA layer provides cryptographic identity and encryption, but it has no equivalent to a zero-trust RBAC model with signed role grants, role expiry, rule-based governance, and node-level ACLs that remain enforced in the presence of malicious peers across the network.

Why the Combination Is the Moat

GenosDB's competitive advantage is not WebRTC itself. It is not Nostr. It is not decentralized signaling.

The defensible innovation is Cellular Mesh and its native integration with GenosDB's consistency, synchronization, and security model:

Cellular Mesh         (scale)
    +
Hybrid Delta + HLC    (consistency)
    +
Signed RBAC + ACLs    (trust)
    │
    ▼
a fully distributed, zero-trust,
browser-native data platform —
beyond the full-mesh ceiling,
with no servers at all

Each layer alone is valuable. Together they represent a unique architectural approach to browser-native distributed systems — one that, as of today, has no direct equivalent in the browser-P2P market.

Getting Started in 30 Seconds

import { gdb } from "genosdb"

// P2P database with cellular mesh, no servers
const db = await gdb("my-app", { rtc: { cells: true } })

// Write
const id = await db.put({ name: "Alice", role: "builder" })

// Real-time reactive query
const { unsubscribe } = await db.map(
  { query: { role: "builder" }, realtime: true },
  ({ id, value, action }) => console.log(action, id, value)
)

// Graph edges
await db.link(id, await db.put({ name: "Bob" }))

📦 Install: npm install genosdb — bundler configuration for Vite, Webpack, Bun, esbuild, and CDN
🧪 50+ live examples: examples catalog — chat, kanban, whiteboard, collaborative editors, video rooms, geolocation
🧯 Optional high-availability superpeer: Fallback Server

FAQ

Is GenosDB really serverless?
Yes. Peer discovery uses public Nostr relays (or your own); all data flows peer-to-peer over encrypted WebRTC channels. An optional fallback superpeer can improve availability, but nothing requires it.

How many peers can a room handle?
Standard mesh is comfortable for small rooms; with { cells: true } the Cellular Mesh overlay replaces O(N²) connection growth with cell-local connectivity plus health-elected bridges, designed to scale to very large peer counts.

What happens when a peer goes offline and comes back?
The Hybrid Delta Protocol sends only the missed operations; if the peer is too far behind, it transparently falls back to a compressed full-state snapshot.

How are conflicts resolved?
Deterministic Last-Write-Wins ordered by Hybrid Logical Clocks, with clock-skew capping — and when two peers write the same node at the same instant, over the same value, both contributions are kept rather than one lost (the loser's rescue).

Can untrusted users join?
That is the default assumption. The Zero-Trust Security Model starts everyone as a write-blocked guest; promotion happens through signed role grants or automatic governance rules, and node-level ACLs hold even against malicious peers.

Does it work offline?
Yes — local-first by design. Data persists in OPFS/IndexedDB via a non-blocking worker and syncs when connectivity returns.

Documentation Map

Area	Links
Core API	API Reference · Features · CRUD · put · get · map · link · remove · pagination
GenosRTC	API Reference · Architecture · Guide · Cellular Mesh · Nostr relay deployment
Security	Zero-Trust Model · Distributed Trust · SM API · SM Architecture · ACLs · Governance
Internals	Worker Architecture · Hybrid Delta Protocol · Hybrid Logical Clock · Fallback Server
Project	README · Whitepaper · Examples · Resources · Wiki · DeepWiki · npm

Keywords: GenosDB, GenosRTC, P2P database, WebRTC mesh, decentralized database, browser database, Nostr signaling, CRDT alternative, distributed systems, zero-trust security, real-time sync, serverless, local-first, offline-first, graph database, JavaScript P2P

Author

Esteban Fuster Pozzi (@estebanrfp) — Full Stack JavaScript Developer

🌐 estebanrfp.com · LinkedIn · Creator of GenosDB

A Live WebGPU Planet With No Backend — Powered by GenosDB

Esteban Fuster Pozzi — Fri, 17 Jul 2026 11:22:33 +0000

Most database demos are to-do lists. I wanted to find out what happens when you
put one under real load — so I built a planet.

OVGrid is a cube-sphere planet you explore as an avatar, right in your
browser: procedural terrain, weather, vegetation, day/night, real-time
multiplayer presence, and land you can own and trade on-chain. It runs at
real scale on WebGPU.

▶ Play it live (no install, no account): https://world.ovgrid.com

But the rendering isn't the interesting part. The interesting part is that
there is no backend. No game server, no API, no socket server. A single
distributed database — GenosDB — drives the
entire live state of the world. This post is about how that works.

First, the planet: Floating Origin

A planet is 795 km in radius. GPUs work in 32-bit floats, which run out of
precision long before you get that big — geometry jitters, z-fighting explodes,
the avatar shakes. The fix is Floating Origin:

The CPU holds every world coordinate in Float64 (full precision).
Each frame, positions are rebased relative to the camera and only the small camera-relative deltas are handed to the GPU as Float32.

The camera is effectively always at the origin, so the numbers the GPU sees stay
tiny and precise — jitter-free all the way down to street-level LOD. A dynamic
quadtree on the cube-sphere subdivides terrain near you, and a GPU-baked height
grid gives exact ground for collision and physics. (Full write-up:
floating-origin-guide.md.)

That's the foundation. Now the twist.

The twist: a database is the backend

Live multiplayer worlds usually need a server: something authoritative that
clients connect to, that holds state and relays updates. OVGrid has none. Instead,
every client runs GenosDB, a serverless, peer-to-peer, real-time graph
database, and the world is the database.

Here's the capability map:

What you see in the world	What GenosDB is doing
Other players appear as animated avatars at the right position, altitude and animation	P2P presence over WebRTC (`GenosRTC`), synced ~12 times a second — no game server
The land map and the marketplace update live as data changes	Reactive reads (`db.map`) — the UI subscribes to a query and re-renders on every change
Land and assets you own, read instantly even offline	On-chain mirror — Polygon is the source of truth, GenosDB caches it for fast, offline, reactive reads
Sign in with biometrics or a seed phrase; actions are signed	Decentralized identity + RBAC via the Security Manager (WebAuthn / BIP39)

Reactive reads: the UI never polls

The land map and the on-chain marketplace are different frontends that read the
same database the same way — a live query with a callback that fires on every
change, whether the change came from this peer or another:

// Subscribe once. The callback re-fires whenever matching data changes —
// locally OR from a remote peer. No polling, no manual refresh.
db.map({ query: { type: 'parcel' } }, ({ id, value, action }) => {
  renderLandMap()   // re-render the 3D world on each change
  // ...and the marketplace subscribes to the very same data
})

Broadcasting your avatar is just a write:

// Position, yaw and animation, ~12 Hz. Peers receive it and animate your avatar.
db.put({ type: 'presence', pos, yaw, anim }, `presence_${myId}`)

The pattern I'm proudest of: the read layer never changes

A parcel of land might be claimed locally (instant, optimistic) or minted
on-chain (an ERC-1155 token on Polygon). Two completely different write paths —
one is a local DB op, the other is a blockchain transaction confirmed over
minutes.

And yet the world reads both the same way: a db.map subscription. A sync
layer mirrors the chain into GenosDB, so the 3D client never waits on an RPC, never
hits the chain on the render path, and works offline. The blockchain is the source
of truth; GenosDB is the abstraction that makes it feel instant.

What "no server" actually means

The honest question is: if there's no backend, how do peers find each other?

Transport: WebRTC data channels, peer-to-peer.
Signaling: Nostr relays — a decentralized signaling layer, so there's no central matchmaking server either.
Conflict resolution: a Hybrid Logical Clock orders concurrent writes deterministically, so peers converge without a coordinator.

The result: open two browser tabs, walk around in one, and your avatar appears and
moves in the other — with nothing running in between but the open internet.

It's open source — and it documents itself

OVGrid is fully public:

→ https://github.com/estebanrfp/ovgrid

A couple of things worth a look:

Every tunable in the world — terrain noise, cloud layers, ocean, lighting, weather, vegetation — is documented parameter-by-parameter in docs/configuration/.
The repo is indexed by DeepWiki, so you can ask the codebase questions in natural language.

If you've ever wanted to see a serverless, P2P, real-time database do something
harder than a to-do list — go fly around a planet, then read how a single DB holds
it all together.

Play: https://world.ovgrid.com · Code: https://github.com/estebanrfp/ovgrid · Database: https://github.com/estebanrfp/gdb

Serverless P2P Multiplayer in Godot — No Backend, Just GenosDB

Esteban Fuster Pozzi — Fri, 17 Jul 2026 11:21:14 +0000

Try it first: open the live demo in two browser tabs → https://estebanrfp.github.io/godot-genosdb/ Each tab is a different player. Walk around, chop a tree — it falls in every window. Say hi in the chat. No server is running. Anywhere.

The challenge

Multiplayer usually means servers: a backend, sockets, authoritative state, deployment, scaling, cost. For a small game — or just a prototype — that's a lot of plumbing before the fun part.

What if the players' browsers just talked directly to each other, and the shared world simply… persisted, on its own?

That's what this demo does: a top-down, Stardew-style co-op farm built in Godot 4, exported to the Web, where every connected browser is another farmer in the same world — running on no backend at all. The secret is GenosDB.

What is GenosDB?

GenosDB is a decentralized graph database that runs entirely in the browser. Two parts matter here:

GenosRTC — peer-to-peer transport over WebRTC, with decentralized signaling via Nostr relays (no signaling server you run). Peers find each other and open direct data channels.
A reactive, persistent graph — you put nodes and map queries, and changes sync to every peer and persist (OPFS). New peers automatically receive the current state.

No backend. No database server. No signaling server. It's all client-side.

The key idea: a hybrid model

Not all multiplayer state is equal, and GenosDB lets you treat it accordingly. The demo splits the world into two layers — and this is the pattern worth stealing:

State	Example	How	Why
Ephemeral	Player positions & chat messages	a data channel (`channel.send`)	fast, ~16 Hz, throwaway
Persistent	Chopped trees + the shared wood total	the graph (`db.put` / `db.map` / `db.remove`)	synced and stored; late-joiners see the world as it is, and Reset wipes it for everyone

That second row is the magic. When you chop a tree you don't shout "I chopped tree 3!" (only people currently listening hear it). You write it into a shared graph — and anyone who opens a new tab later gets the already-chopped world via GenosDB's initial event. Chops survive reloads. That's a database, working P2P, for free.

It's a real little game now — and every feature is a GenosDB call

The demo grew from a tech sketch into a cozy co-op game, and each mechanic still maps cleanly to GenosDB:

🪓 Chop trees with an axe — a 4-directional animated farmer. Felled trees regrow, and the shared wood counter (real felled trees, race-free) reads the same for everyone, derived straight from the synced graph.
💬 P2P chat — type a message and it pops as a speech bubble over your farmer in every window (the ephemeral data channel again).
♻️ Reset — one button wipes the shared world for all peers. That's db.remove, propagated P2P.
🎨 Cozy pixel-art world, sound effects and ambient music — and all art & audio are CC0 (credits in the repo).

All of it serverless. All of it P2P.

Connecting Godot to GenosDB

GenosDB is browser-only, and Godot reaches the browser through its Web (HTML5) export + JavaScriptBridge. So I built a small bridge and packaged it as a plugin — godot-genosdb — that auto-injects the JS bridge into your exported index.html. Enable it, export to Web, done. Nothing to bundle, no HTML to edit.

The API mirrors GenosDB

On purpose: learn the plugin and you've learned GenosDB.

func _ready():
    Net.peer_join.connect(func(id): spawn_farmer(id))
    Net.message.connect(_on_remote_state)      # ephemeral (positions + chat)
    Net.graph_changed.connect(_on_world)       # persistent
    Net.join("my-room")                         # = gdb("my-room", {rtc:true})
    Net.map({})                                 # = db.map({}, cb)

func _physics_process(_d):
    Net.send({ "x": position.x, "y": position.y })   # = channel.send(...)

func chop_tree():
    Net.put({ "type": "tree", "hp": 0 }, "tree_3")   # = db.put(node, id)

func reset_world():
    Net.remove("tree_3")                              # = db.remove(id)

GenosDB (JS)	Godot (`Net`)
`gdb(name, {rtc:true})`	`Net.join(name)`
`channel.send(data)`	`Net.send(data)` → signal `message`
`db.put(node, id)`	`Net.put(data, id)` → signal `graph_changed`
`db.map(query, cb)`	`Net.map(query)`
`db.remove(id)`	`Net.remove(id)`
`room.on('peer:join' / 'leave')`	signals `peer_join` / `peer_leave`

Try it / use it

▶ Live demo (two tabs!): https://estebanrfp.github.io/godot-genosdb/
Plugin + full source (MIT, assets CC0): https://github.com/estebanrfp/godot-genosdb
GenosDB: https://github.com/estebanrfp/gdb

Install is three steps: copy addons/godot_genosdb/, enable it in Project Settings → Plugins, export to Web. P2P is Web-only; on desktop the API is a safe no-op, so the same code runs as single-player in the editor.

Why this matters

For jams, prototypes, collaborative toys, or "presence" features, serverless P2P removes an entire category of work. And because GenosDB gives you a persistent reactive graph — not just a raw WebRTC pipe — your shared world is consistent, survives reconnects, and welcomes late-joiners with zero extra code.

Two browser tabs. One shared world. No backend. Just GenosDB.

Serverless P2P NFT Marketplace on Polygon — Powered by GenosDB

Esteban Fuster Pozzi — Fri, 17 Jul 2026 11:21:12 +0000

Most dapps hammer an RPC and shove a wallet extension in your face. I took the on-chain marketplace from OVGrid and rebuilt it as a ~1,600-line example where the database is the read layer — and your identity is your wallet.

Open two browser tabs at dMarket. Browse the marketplace in both — no wallet, no sign-up, no spinner waiting on an RPC. The items are just there, and a change in one tab shows up in the other. That isn't a backend doing the work. It's a peer-to-peer graph database.

dMarket is a small, faithful slice of the marketplace that runs inside OVGrid — the WebGPU planet I wrote about here. I pulled the blockchain layer out, trimmed it to ~1,600 readable lines of vanilla JavaScript with no build step, and kept it pointed at the same real contracts OVGrid uses on Polygon. It exists so you can copy a pattern that actually works instead of reinventing it.

The problem with most blockchain front-ends

Every wallet, every render, every visitor hits the same RPC for the same data. There's no real-time sync between users unless you stand up an indexer and a websocket server — a backend, the very thing crypto was supposed to get rid of. And before anyone can even look, you make them install MetaMask.

I wanted to show a different shape.

First, what GenosDB is

GenosDB is a peer-to-peer graph database that runs entirely in the browser. No central server: data lives locally (OPFS), replicates between peers over WebRTC, and every operation is signed by your own key. You read it reactively with db.map(query, cb). (More in the examples.)

The key idea: the chain is the truth, GenosDB is the mirror

Polygon stays the source of truth for ownership — money is money. But you don't read from the chain on every render. You read it once, write the result into GenosDB, and from then on everyone reads the database:

// Read the chain (authoritative) once, mirror it into GenosDB:
const listings = await chain.getActiveListings()        // 2 Multicall3 calls
await Promise.all(listings.map(l =>
  db.put({ type: 'listing', ...l }, `listing_${l.listingId}`)
))

// Everywhere else, read reactively — never the RPC again:
db.map(({ id, value, action }) => repaint())            // the ONE reactive read

After a buy or a listing confirms on-chain, the same thing happens: db.put the new state, and db.map streams it to every connected peer. The read layer never changes whether an item was just discovered on-chain or just created by someone two seconds ago. The database is the abstraction — fast, offline-capable, peer-to-peer, with no indexer in the middle.

The part I'm proudest of: your identity is your wallet

GenosDB's Security Manager already gives every user a cryptographic identity — an address and a private key derived from a recovery phrase. Here's the thing nobody points out: that's an Ethereum account. The same key that signs your peer-to-peer database operations signs your Polygon transactions.

// A GenosDB login hands you a usable wallet. One key, two worlds.
const id = await db.sm.loginOrRecoverUserWithMnemonic(phrase) // { address, privateKey }
const wallet = new ethers.Wallet(id.privateKey, provider)     // signs on-chain txs
// wallet.address === db.sm.getActiveEthAddress()   ✓  no MetaMask

No extension, no second wallet, no bridging. You log in once and you can both sync P2P and transact on-chain with the exact same identity. dMarket even asserts the two match before it ever signs. See the Security Manager docs.

What GenosDB actually buys you here

What a marketplace needs	How dMarket does it with GenosDB
Live updates between users	`db.map()` over WebRTC — no indexer, no websocket backend
Browse instantly, even offline	local-first reads from GenosDB (OPFS)
A wallet	the GenosDB identity is the wallet — no MetaMask
"Who owns what"	mirrored P2P, re-derivable from the chain anytime

Simplified, but real

dMarket is deliberately a reference example, not the full product. It does mint, list, buy and offer — and stops there. No auctions, bundles, rentals, royalties, analytics or a 3-D world; that breadth lives in OVGrid. But what's here is the real, battle-tested integration: real ABIs, real contracts on Polygon Amoy, the real identity bridge. Read dMarket to learn the pattern; study OVGrid to see it at full scale.

Browsing works for anyone with no wallet — that's the GenosDB showcase. To actually transact you connect an identity and grab free test POL from the Amoy faucet; the README is honest about the prerequisites.

Try it / read it

▶ Play it live — estebanrfp.github.io/dMarket (open two tabs)
💻 Read the code — github.com/estebanrfp/dMarket (~1,600 lines, no build)
🌍 The full world it came from — OVGrid
🗄️ The database — GenosDB · reactive reads · identity & security

Why this matters

We keep rebuilding the same backend — an indexer here, a websocket there, a wallet popup in front — to do things a peer-to-peer database can just do. dMarket is a small proof that you can put a real blockchain behind a real-time, offline-capable, serverless front end, and have the whole thing be readable in an afternoon.

The chain is the truth. The database is the mirror. Your identity is your wallet. No backend.

What Socket.dev Shows About GunDB's Supply Chain in 2026 — and How GenosDB Answers It

Esteban Fuster Pozzi — Thu, 16 Jul 2026 18:50:43 +0000

A technical, source-cited comparison of the install-time supply-chain surface of gun (GunDB) as reported by Socket.dev, and how GenosDB — a zero-dependency, zero-trust, real-time peer-to-peer graph database — is designed to keep that surface empty. If you are weighing GunDB for production, or looking for a maintained GunDB alternative, this is the security-and-architecture comparison in full.

Reading time: ~18 min. Written by Esteban Fuster Pozzi, maintainer of GenosDB.

Context

Full disclosure: I built GenosDB, so I have a stake in this comparison — read it knowing that. Here's the rest of the context, so you can weigh it for yourself.

I spent years working with GunDB — building on it, building its documentation platform, and getting to know genuinely talented developers along the way. GunDB made real-time, offline-first, peer-to-peer data feel possible years before the rest of the ecosystem caught up, and it shaped how I think about decentralized systems.

GunDB defined a category: a real-time, offline-first, peer-to-peer graph database that runs in the browser. It is a reference point for decentralized, serverless data on the web, alongside projects like OrbitDB, Scuttlebutt and RxDB. GenosDB works in the same category — a distributed graph database with real-time P2P sync — and this post compares it with GunDB on one specific axis: the security and supply-chain posture of the data/sync layer, as measured by an external tool that scans npm packages statically, Socket.dev.

Socket now provides a complete, itemized report of GunDB's install-time surface. This is the value of the exercise: what used to be described informally ("Gun's dependency tree is heavy") is now a set of concrete, countable facts. This post presents those facts, explains what each alert measures, traces the architectural pattern behind them, and describes how GenosDB's design produces a different report.

Everything here is verifiable. Every count comes straight from Socket's public pages, quoted as reported.

What Socket.dev measures

Socket statically analyzes the behavior of every package in a dependency graph — whether it spawns a shell, reads environment variables, runs an install script, ships obfuscated or minified blobs, or contacts external URLs — and it does this transitively, across the full tree that an install would resolve.

Two properties of the method matter for reading the report:

It is transitive. The counts below aggregate GunDB's entire dependency graph — every package Gun pulls in, directly and indirectly. A single npm install gun resolves this whole tree onto your machine.
It is behavioral, not just CVE-based. Socket flags capabilities and code patterns (install scripts, eval, native binaries, obfuscation) because these are the primitives that supply-chain attacks use. The jscrambler npm compromise Socket documented on July 11, 2026 — a malicious preinstall hook running hidden native binaries across Linux, macOS and Windows — is a recent example of this exact shape.

With that method in mind, here is the report.

The report: every Socket alert on `gun@0.2020.1241`

Source: socket.dev/npm/package/gun/alerts/0.2020.1241?tab=dependencies. Counts are "instances / packages affected" across Gun's dependency tree, quoted as Socket reports them.

A. Known vulnerabilities (CVEs)

Alert	Severity	Reach
Critical CVE	🔴 Vulnerability	4 instances in 4 packages
High CVE	🟠 Vulnerability	24 instances in 16 packages
Medium CVE	🟡 Vulnerability	16 instances in 14 packages
Low CVE	Vulnerability	5 instances in 4 packages

The dependency tree carries published, catalogued CVEs at every severity tier, including four critical ones. Each is a documented compromise path with an identifier, present in a package Gun depends on. The path to remediation for a dependency CVE is a version bump upstream; as section C shows, that upstream cadence has stopped, so these fixes are not arriving.

The mechanism is timing: Gun's last release is from 2020, which froze its dependency ranges. Every CVE disclosed in those dependencies since then resolves into a fresh npm install gun today.

B. Supply-chain behavior

Obfuscated code — 2 instances in 2 packages. Files packaged to conceal their behavior. Socket's classification: a potential malware indicator.

Uses eval / dynamic code execution — 38 instances in 38 packages. Runtime eval() constructs and executes code that is absent from the audited source. It bypasses static analysis and requires relaxed CSP to run.

Install scripts — 2 instances in 2 packages. preinstall/postinstall hooks execute automatically during npm install, with access to the shell, environment variables, and CI tokens. Two packages in Gun's tree run code at install time — the jscrambler vector.

Shell access — 20 instances in 20 packages. Twenty packages can spawn a system shell, i.e. execute arbitrary commands.

Network access — 22 instances in 22 packages. Twenty-two packages can open network connections. Combined with the environment and filesystem access below, this is the full read-secrets-and-transmit capability set.

Filesystem access — 78 instances in 78 packages. Seventy-eight packages can read the disk, and therefore any sensitive data on it.

Environment-variable access — 75 instances in 75 packages. Seventy-five packages read process.env, where credentials and tokens live. Socket's classification associates this with credential harvesting.

URL strings — 78 instances in 77 packages. Hardcoded URLs / external IPs the package may contact at runtime — the potential destinations for data.

Dynamic requires — 19 instances in 19 packages. Modules resolved at runtime rather than statically, which loads code a scanner cannot see in advance.

Debug / reflection access — 15 instances in 15 packages. Debug, reflection and dynamic-execution features that expand runtime self-modification.

Native code — 2 instances in 2 packages. Compiled binaries / shared libraries, which are opaque to source review.

AI-detected potential code anomaly — 52 instances in 50 packages. Socket's ML flagged unusual behavior across fifty packages for human review.

Trivial package — 23 instances in 23 packages. Twenty-three dependencies under ~10 lines of code. Each is a full third-party trust relationship, and an independent takeover target, for logic that could be inlined.

AI-detected potential typosquats — names in the tree close to far more popular packages (Socket names camelcase and babel-plugin-transform-react-jsx as the likely targets). Typosquatting is a primary malware-delivery technique.

Nonexistent author / New author — packages published by an npm account that no longer exists, and (36 instances in 36 packages) first-time publishers. Both correlate with account-takeover and namespace-hijack events.

Potential vulnerability — flagged by initial human review, pending confirmation.

C. Maintenance

Unmaintained — 201 instances in 201 packages. Two hundred and one packages in the tree have gone more than five years without an update. This is the majority of the tree, and it is the reason the CVEs in section A stay open: the upstream cadence that would ship fixes has stopped.

Deprecated — 23 instances in 23 packages. Twenty-three dependencies the maintainers themselves marked as superseded.

D. Quality

Minified code — 12 instances in 9 packages. Source shipped minified, which reduces auditability. Unpopular package — 2 instances in 2 packages. Low-usage dependencies, with fewer reviewers. Floating dependency — a dependency on a floating range that can pull a breaking major without notice.

E. License

Multiple license problems, unidentified license, copyleft license, non-permissive license. For commercial software, the tree introduces license ambiguity and copyleft/non-permissive terms that carry legal obligations.

The pattern behind the numbers

The counts aggregate GunDB's transitive tree, and read together they describe one coherent architectural situation:

A large dependency graph — hundreds of packages, the majority unmaintained for five-plus years — carrying four critical CVEs (plus dozens of high and medium) with no upstream path to a fix, alongside install scripts, native binaries, obfuscated files, and typosquat-adjacent names.

This describes the architecture of trust the design asks you to accept: a broad, deep dependency tree, taken on faith, frozen since 2020. Two design choices produce it:

A broad runtime dependency tree. Every convenience pulled from npm is a permanent, transitively-multiplied trust relationship. Gun's tree grew the way most 2018-era JavaScript libraries' trees grew.
A dormant maintenance cadence. With the last release in 2020, the tree accumulates CVEs over time and sheds none, because remediation depends on upstream updates that have stopped.

npm audit fix operates on this tree; it cannot restructure it. The path to a different report is a different architecture — one that keeps the tree empty from the start. That architecture is the design goal of GenosDB.

The maintainer's own account

The maintenance status is also on the record from the source. GunDB's creator, Mark Nadal, characterizes Gun as "actively used and in production" and scalable to millions of monthly users. In the same statement he describes the current maintenance cadence directly: he reached "about 70%" through fixing known bugs, has stepped back from day-to-day upkeep since around 2020, and frames the reduced-support period as running with "no promised timeline" until the next Gun release, pointing users to community forks for prioritized fixes in the meantime.

These are the maintainer's own words: a production claim on one side, and a paused upstream maintenance cadence with unresolved known bugs on the other. When you choose a foundation to build on for the long term, the useful question is not which claim to believe — it is what you can run and confirm yourself. That is the axis where GenosDB is designed to be checked.

How GenosDB produces a different report

GenosDB (GDB) is a distributed, real-time, peer-to-peer graph database — the same category as GunDB. The comparison here is on the same axis: the security and supply-chain posture of the data/sync layer, measured by the same tool.

Here is GenosDB's Socket.dev report:

Metric	GenosDB	Meaning
Dependencies	0	A self-contained package; the audit target is the package itself.
Vulnerability	100 / 100	Clean.
Supply-chain security	79	Strong, and rising as the package ages.
Quality	99	—
Maintenance	96	100+ versions on a weekly release cadence held since inception.
License	80	A single, declared license.

Mapped back to Gun's report, class by class:

1. Zero dependencies

GenosDB ships zero runtime dependencies, which Socket confirms: Dependencies: 0.

Every alert in sections B, C, D and E is an alert about a dependency. A self-contained package resolves the entire category structurally: the audit target is one package, and it is the exact artifact a scanner analyzes, because what ships on npm is the whole product.

The primitives GenosDB builds on — Ethereum key/signature handling, MessagePack serialization, Pako compression — are pinned to exact versions, reviewed on each bump, and bundled into the published dist at build time. They live in devDependencies and travel inside the artifact rather than resolving fresh from npm on each install. This vendored-and-pinned model is why Socket reports 0: at install time, the package is complete on its own.

2. Clean vulnerability score

With a self-contained package, section A's dependency CVEs are absent, and GenosDB's own code carries a clean vulnerability score (Socket: 100). The active release cadence (section 4) means a future finding has a channel to a fix.

3. A minimal install-time footprint

Install runs files only. GenosDB's package.json defines no preinstall/postinstall hooks, so npm install genosdb copies the package and stops there.
Pure JavaScript, pure ESM ("type": "module"). The artifact is readable source, transparent to review.
The sync and security layers are built from static code, keeping runtime dynamic execution out of the architecture.

4. Active maintenance

GenosDB has more than 100 published versions on a weekly release cadence held since the project began, and a maintenance score of 96. Development runs on a Spec-Driven Development method: Esteban Fuster Pozzi as architect and accountable owner, supported by qualified developers and a cluster of audited AI systems whose output is verified against written specifications before it ships. A self-contained base plus a specification-first cadence is what holds the report above stable as the project grows.

5. A single declared license

GenosDB ships under one declared license (Socket: License 80), with a THIRD_PARTY_LICENSES.md accounting for the bundled primitives. A self-contained package keeps license terms singular and explicit.

6. Bundle, license, and governance

GenosDB's published bundle is free, public, and licensed for commercial use — free to install, inspect, run in production, and ship commercially. Its source is curated on a Spec-Driven Development method — Esteban Fuster Pozzi as accountable architect, qualified developers, and a cluster of audited AI systems working against written specifications — and that process is what keeps the dependency surface at zero: dependencies are chosen deliberately, primitives are pinned and reviewed on each bump, and every change is validated against a spec before it ships. The properties in sections 1–5 are the direct output of that model.

Auditability tracks the artifact you run. The published bundle is complete JavaScript on npm, and it is exactly what Socket.dev — and you — analyze. You audit the code that executes on your machine.

A door stays open for the future. As the project matures, additional developers qualified in Spec-Driven Development may be incorporated — selected by consensus — to secure continuity over the very long term, extending the same specification-first discipline that produces the report above.

7. The feature surface is demonstrated, not asserted

A database is worth what you can run. GenosDB ships its entire feature surface as self-contained, runnable example apps — more than fifty of them in the repository, each a single HTML file you open and use on the same engine you would deploy. The set spans the whole surface: CRUD and cursor pagination; real-time chat, kanban, collaborative whiteboard and rich-text editors, live cursors and presence; peer-to-peer audio, video and file streaming; geo-spatial queries; the full security suite — RBAC, WebAuthn, node-level ACLs, governance, client-side encryption; and cellular-mesh scaling monitors. Every capability described in this post has a working demo behind it.

This is the falsifiable form of a database claim. Rather than "trust that it works," the standing invitation is "open these and watch them work" — the same way you would evaluate any foundation before you build on it. Verification, not belief, is the design stance, from the install-time report down to each example.

The data plane: cryptographic enforcement at runtime

Sections 1–6 concern the install-time surface. A peer-to-peer database also governs a second axis at runtime: once peers are connected, who is authorized to change what. With no server to enforce rules, GenosDB enforces them cryptographically, and each peer verifies every operation independently. From the distributed trust model and the source:

Signed operations. Every write is signed by the author's Ethereum key (signOutgoingOperations) and verified by each receiving peer (verifyIncomingOperations) before it applies. Identity is cryptographic.
Zero-trust default. A new identity is a write-blocked guest with a single welcome exception — creating its own user node — where the engine forces the role to guest, so first-message self-promotion resolves to guest. Higher permissions arrive when a superadmin signs a promotion.
RBAC. A guest → user → manager → admin → superadmin hierarchy, enforced locally by each peer's Security Manager. A peer verifies the signed role that authorizes each operation, so a locally-edited client acts within its actual granted role on the network.
Node-level ACLs, enforced across peers. Per-node read/write/delete grants are checked against the cryptographically-verified author of each incoming operation, on every peer. A node accepts writes from its owner and collaborators.
Governance. A superadmin declares promotion/demotion rules as native GenosDB queries; the engine resolves each user's role by last-match-wins and signs every change for peers to verify — optionally 24/7 via an always-on Fallback Server.
Decentralized signaling. The real-time layer (GenosRTC) discovers peers over Nostr relays with its own audited crypto/codec, and can encrypt the signaling channel with a shared password.
Client-side encryption. db.sm.put() / db.sm.get() store data end-to-end encrypted — readable by its author and by the addresses they grant, with cryptographic revocation (per-record key rotation) via db.sm.acls. The envelope format is also faster than the one it replaced, which derived a key with PBKDF2 (100,000 iterations) per record on every read and write — measured in-browser on 0.28: reads 10.9 → 1.2 ms per record, writes 11.1 → 1.5 ms, a 40-record sm.map ~440 → ~50 ms.

The two axes share one design principle: replace trust with verification. Peers verify every operation cryptographically; the package stays self-contained.

Downloads, and the last word

A download is a trial, not an outcome. npm counts package fetches — installs, CI runs, mirrors, reinstalls — not developers who shipped a system and kept it running. Popularity measures how many people arrive at a technology, not how many build something durable on it and stay. For a foundational dependency, that gap is where the risk lives: reputation brings developers in the door, and a paused maintenance cadence with unpatchable issues is what some of them find on the other side.

No download count settles that. A clean install-time report, a self-contained package, and a feature surface you can run exist to put the decision where it belongs — with the developer who tries it. Build the same small thing on each, and let the result speak. The last word is the developer's.

The ask

I want help spreading GenosDB, and I'm asking for it directly.

The value an independent maintainer benefits from most is reach and scrutiny:

If the architecture makes sense to you, say so where developers will see it. A star on github.com/estebanrfp/gdb, a reshare, or a mention in a thread where someone is choosing a real-time P2P database moves an independent project forward.
Test it adversarially. The public bundle and the live demos are enough: run two browsers, try to forge a signed operation or promote past the zero-trust guard, and report what you find via SECURITY.md. Black-box scrutiny is the highest-value contribution to a security-adjacent project.
Port one feature from GunDB. A single slice is enough to feel the zero-dependency, zero-trust version and to tell me where it can improve.
If you align with this approach and you're strong technically, introduce yourself. Contribution opens progressively to a small, vetted, aligned team chosen by consensus, and I'm keeping a list for when that starts.

GunDB defined this category. The goal here is to give it a foundation that a 2026 supply-chain scanner reports clean — and to invite the people who care about that to help prove it, or test it, in public.

The surface is measured now. Let's build on the one that stays empty.

Frequently asked questions

Is GunDB still maintained in 2026? GunDB remains widely installed and is used in production. Active upstream maintenance of the current line, though, is paused by the maintainer's own account since around 2020 — known bugs remain, there is no committed timeline for the next release, and users are pointed to community forks for prioritized fixes. Socket.dev's scan reflects it: the majority of Gun's dependency tree is flagged as unmaintained.

Is GunDB safe to use in production? It depends on your risk tolerance. GunDB has real production deployments and a decade of decentralized-data work in its own source. On the supply-chain axis, Socket.dev reports its dependency tree carries four critical CVEs (plus dozens of high and medium), install scripts, obfuscated code and native binaries, with most of the tree unmaintained for five-plus years — issues without an upstream path to a fix while maintenance is paused. Weigh that install-time surface against your use case.

What is a maintained alternative to GunDB? GenosDB is a maintained, actively-released alternative in the same category — a distributed, real-time, peer-to-peer graph database in pure JavaScript, reporting zero dependencies and a clean vulnerability score on Socket.dev. Other decentralized options include OrbitDB (on IPFS/libp2p), Scuttlebutt and RxDB; see this P2P database comparison for the wider landscape.

How does GenosDB compare to GunDB? Both are real-time, offline-first, peer-to-peer graph databases. GenosDB ships zero runtime dependencies (versus GunDB's flagged transitive tree), a zero-trust security model with signed operations, RBAC, node-level ACLs and governance, and OPFS + Web Worker persistence that keeps the main thread non-blocking (GunDB's default persistence is commonly localStorage, a synchronous ~5 MB store on the main thread). Its real-time layer, GenosRTC, pairs WebRTC with decentralized Nostr signaling.

How does GenosDB compare to OrbitDB, Scuttlebutt or RxDB? OrbitDB builds on IPFS/libp2p; Scuttlebutt is a log-based social protocol; RxDB is a local-first database with pluggable replication. GenosDB is browser-native and serverless, with integrated WebRTC transport and Nostr signaling, a MongoDB-style query layer with recursive graph traversal, and a built-in zero-trust security model — at zero runtime dependencies. Full landscape: Best P2P & CRDT databases in 2026.

Does GenosDB have dependencies? Zero, at install time — Socket.dev reports Dependencies: 0. The primitives it builds on (Ethereum signatures, MessagePack, Pako) are pinned, reviewed and bundled into the published artifact at build time, rather than resolved from npm as a transitive tree.

Is GenosDB free and open source? The GenosDB bundle is free, public and licensed for commercial use — free to install, inspect, run in production and ship commercially. The source is curated under a Spec-Driven Development method, and contribution opens progressively to qualified, consensus-selected developers to secure continuity over the long term.

GenosDB — distributed, real-time, peer-to-peer graph database. Zero dependencies, zero-trust, serverless. 🔗 github.com/estebanrfp/gdb · npm: genosdb · Socket report

Author

Esteban Fuster Pozzi (@estebanrfp) - Full Stack JavaScript Developer

Sources & verification

GunDB Socket report: socket.dev/npm/package/gun/alerts/0.2020.1241?tab=dependencies (all alert counts quoted verbatim).
GenosDB Socket report: socket.dev/npm/package/genosdb (scores; 0 dependencies).
GenosDB security model: SECURITY.md, docs/zero-trust-security-model.md, docs/genosdb-distributed-trust-model.md, docs/genosdb-features.md in the GenosDB repository.
Architecture claims (signing/verification, ACLs, governance, Nostr signaling) verified against the GenosDB, GenosRTC and GenosSRV source.

My personal take

These figures are a snapshot: CVE counts, unmaintained packages and Socket scores all shift as the community patches, so re-run the scan whenever you read this and let today's numbers speak.

GunDB stays a solid choice for prototypes, internal tools and many wonderful production apps.

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

📚 Wiki | additional notes and guides

💬 GitHub Discussions | community questions and feedback

🗂 Repository | Minified production-ready files

📦 Install via npm | quick setup instructions

🌐 Website | GitHub | LinkedIn

From Babylon.js to Native WebGPU: How OVGrid Migrated to a Framework-Free Engine

Esteban Fuster Pozzi — Tue, 17 Feb 2026 17:43:37 +0000

In 2020, OVGrid started as an experiment in building dynamic 3D virtual worlds using Babylon.js — one of the most mature WebGL frameworks available. We explored terraforming, dynamic textures, height maps, and real-time rendering. The results were promising.

OVGrid's first 3D environment tests with Babylon.js (2020)

Early terrain generation and texture mapping experiments

%[https://www.youtube.com/watch?v=_hfYsrHMAeI]

Babylon.js gave us a solid foundation: a scene graph, a physics engine, material system, and a large community. For a prototype, it was the right choice. But as OVGrid's ambitions grew — planetary-scale terrain, atmospheric scattering, thousands of instanced objects — the framework started showing its limits.

Why We Left Babylon.js

Babylon.js is an excellent framework. It even added WebGPU support. So why leave?

The answer isn't about Babylon.js being bad. It's about what happens when you need total control over every GPU instruction.

Bundle Size and Dependencies

A full Babylon.js build adds significant weight to your application. For a project that targets instant browser access with zero downloads, every kilobyte matters. OVGrid needed to be lean — a PWA that loads in seconds, even on mobile.

GPU Pipeline Control

When you're writing custom atmospheric scattering shaders, cascaded shadow maps with 4 layers, and GPU-driven terrain instancing, you need direct access to the WebGPU pipeline. Working through a framework's abstraction layer means fighting against it when your needs diverge from its assumptions.

The Abstraction Tax

Every abstraction has a cost. Babylon.js manages its own render loop, its own resource lifecycle, its own state. When you need a Floating Origin system that keeps the camera at (0,0,0) and offsets the entire world in Float64 — or when you need to reduce terrain draw calls to one single call per frame — you need the GPU to do exactly what you tell it. No middleware.

Philosophy: Pure JavaScript, Zero Frameworks

OVGrid's philosophy aligns with a broader conviction: the best code is the code you fully understand and control. No framework updates breaking your build. No dependency chains. No black boxes. Just JavaScript, WGSL shaders, and the WebGPU API.

The Migration

The transition wasn't a weekend refactor. It was a deliberate, incremental process.

Phase 1 — Custom Render Pipeline. We replaced Babylon.js's render loop with a direct WebGPU pipeline. This alone gave us the ability to control exactly which compute and render passes execute per frame.

Phase 2 — Shader Rewrite. Every shader was rewritten in WGSL from scratch. Atmospheric scattering, terrain rendering, vegetation instancing — all hand-tuned for OVGrid's specific needs. No generic material system overhead.

Phase 3 — Floating Origin. The camera stays at (0,0,0) in GPU space. World coordinates use Float64 on the CPU, and only relative offsets are sent to the GPU. This eliminates the floating-point jitter that plagues every large-scale WebGL application.

Phase 4 — GPU-Driven Instancing. Terrain chunks, vegetation, and objects are rendered with a single instanced draw call per category. The GPU decides visibility, LOD, and placement.

Phase 5 — Modular Architecture. Using Bun as the bundler, we split the UI into lazy-loaded modules. Configuration panels load on first interaction. The main bundle stays minimal.

The Results

The numbers speak for themselves:

120 FPS sustained during planetary traversal — from ground level to orbit
One draw call for all terrain chunks per frame
Sub-second initial page load as a PWA
Zero dependencies — no node_modules, no framework updates, no breaking changes
Full mobile support — the same codebase runs on desktop and mobile browsers with WebGPU

When Frameworks Make Sense

This isn't an anti-framework manifesto. Babylon.js is the right choice for many projects — games, product configurators, architectural visualization. If your project fits within a framework's model, use it.

But when you're building a planetary-scale virtual world that needs to push every boundary of what the browser can do, the framework becomes the ceiling. Removing it becomes the unlock.

What's Next

OVGrid continues to evolve. The migration to native WebGPU was the foundation. On top of it, we're building:

GenosDB integration for P2P identity and real-time world state
Polygon blockchain for OVG tokens and ERC-1155 metaverse assets
Ready Player Me avatars for cross-platform identity
Cascaded Shadow Maps with 4-layer precision up to 10km

The browser is no longer the limitation. It's the platform.

Written by Esteban Fuster Pozzi (estebanrfp), creator of GenosDB and OVGrid.

Scaling the Metaverse: Building a Planetary-Scale Engine with WebGPU

Esteban Fuster Pozzi — Tue, 17 Feb 2026 16:37:58 +0000

How OVGrid is pushing the boundaries of the mobile and desktop web with deep modularization, blockchain integration, and high-precision rendering.

In the rapidly evolving landscape of web-based graphics, the leap from WebGL to WebGPU isn't just an upgrade — it's a paradigm shift. Today, I'm thrilled to share a deep dive into OVGrid, a project designed to prove that the browser can handle massive, planetary-scale environments with the fidelity and performance of native applications.

The Objective: Zero-Latency Exploration

The goal of OVGrid was simple yet ambitious: to create a seamless planetary traversal experience. Whether you are walking on the grass of a procedurally generated biome or orbiting at 500km altitude, the transition should be fluid, and the performance should remain at a solid 120 FPS.

To achieve this, we've implemented an architecture that prioritizes the "Single Source of Truth" rule:

CPU (JavaScript): Decides what exists. It handles the high-precision world coordinates (Float64), Level of Detail (LOD) logic, and physics state.
GPU (WGSL): Decides how it looks. It handles the heavy lifting of ray-tracing, atmospheric scattering, and instanced geometry.

Deep Modularization: The Phase 6 Milestone

Our latest engineering milestone, Phase 6: Granular UI Lazy Loading, addresses one of the most significant challenges in web apps: the initial payload.

By splitting our monolithic UI into independent modules — such as EnvironmentUI and TerrainUI — we've achieved a state where the browser only downloads and executes the code you actually use.

Using Bun as our bundler, we've reduced the main bundle size significantly. Now, configuration panels are triggered by fast keyboard shortcuts (T for Terrain, V for Environment), loading their specific HTML and logic only on first interaction. This "pay-as-you-go" script execution ensures that the experience remains snappy from the first second of the page load.

Engineering the Planet

At the core of the visual experience is a high-precision Floating Origin system. By keeping the camera at (0,0,0) in the shader and passing only relative offsets, we eliminate the floating-point "jitter" that typically plagues large-scale environments.

Other key technical pillars include:

Cascaded Shadow Maps (CSM): 4-layer cascades that provide razor-sharp shadows for your avatar while covering terrain up to 10km away.
Nervland-style LOD Rings: An adaptive subdivision system that maintains a highly detailed central block while progressively simplifying the periphery.
GPU-Driven Instancing: We've reduced terrain draw calls from hundreds to one single call per frame, maximizing the efficiency of the WebGPU pipeline.

A Sovereign Economy

OVGrid isn't just a technical showcase; it's a foundation for a decentralized economy. We have successfully integrated:

Polygon Blockchain: Live connectivity to the Amoy testnet for OVG Tokens and ERC-1155 metaverse assets.
Digital Identity: Using GenosDB, we implement WebAuthn biometrics and BIP39 mnemonic recovery, giving users true ownership of their data.
Global Avatars: Full integration with Ready Player Me, allowing users to hot-swap their cross-game identities in real-time.

The Future of Web Graphics

The combination of WebGPU's raw power and modern JavaScript tools like Bun and GenosDB is opening doors that were previously closed to web developers. OVGrid is a testament to what is possible when you combine low-level optimization with a modular, scalable mindset.

The horizon is wider than ever.

Written by Esteban Fuster Pozzi (estebanrfp), creator of GenosDB and OVGrid.

DEV Community: Esteban Fuster Pozzi

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

What GitHub Runs Servers For

Two Layers, One Graph

The Editor Is the Block Editor, for Code

A Commit That Names Itself

A Branch Only Its Owner Moves

Pull Requests Nobody Marks as Merged

Offline Is a Commit Like Any Other

Private Repositories: The Engine Keeps the Key

The Constitution: Writing Is Free, Nothing Owned Is Touchable

What It Deliberately Does Not Do

Try It

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

Every Hacker News Clone Ends With a Server

The Whole Idea in Three Sentences

What a Shared Constitution Changes

Step 1 — One Subscription, Every Page

Step 2 — A Vote Is a Node You Own

Step 3 — The Constitution Is a File

Step 4 — Writing Is Free, Influence Is Earned

Step 5 — Karma You Can Recount

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

Run It

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

The Usual Way Puts a Server Between You and OBS

The Whole Idea in Three Sentences

Step 1 — One File, Two Modes

Step 2 — Three Pieces, Three Nodes

Step 3 — One Subscription Paints Every Screen

Step 4 — A Countdown Nobody Ticks

Step 5 — Alerts Are Moments, Not State

Step 6 — Put It in OBS

What It Does Not Do — and What It Would Take

Run It

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

What the "Clone" Guides Don't Tell You

The Whole Idea in Three Sentences

Step 1 — The Group Is the Link

Step 2 — People and Expenses Are Nodes

Step 3 — Two Live Queries Feed One View

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

Step 5 — Who Pays Whom

Step 6 — Open It in Two Windows

What It Does Not Do — and What It Would Take

Run It

GenosDB vs Yjs and Automerge: Real-Time Collaboration Without a CRDT Library

The Problem Everyone Solves the Same Way

What Yjs Actually Does

What Automerge Actually Does

The Dividing Line, Stated Plainly

The Other Path: One Node per Paragraph

Ordering, Precisely

Why the Path Is Shorter

What Comes in the Same Package

Offline Is Not a Feature You Add

What the Choice Actually Is

Try It

GenosDB + GenosRTC: A Scalable Browser-Native P2P Graph Database with Cellular Mesh WebRTC Architecture

Table of Contents

What is GenosDB?

The Full Stack at a Glance

Layer 1 — Production-Grade P2P Signaling (GenosRTC)

Layer 2 — The Real Innovation: Cellular Mesh

Layer 3 — The Database Engine: Delta Sync, HLC, Last-Write-Wins

Hybrid Delta Protocol

Hybrid Logical Clocks + LWW

Non-Blocking Persistence

Query Engine

Layer 4 — Zero-Trust Security: RBAC, ACLs, Governance

Market Comparison

Why the Combination Is the Moat

Getting Started in 30 Seconds

FAQ

Documentation Map

Author

A Live WebGPU Planet With No Backend — Powered by GenosDB

First, the planet: Floating Origin

The twist: a database is the backend

Reactive reads: the UI never polls

The report: every Socket alert on `gun@0.2020.1241`