DEV Community: Esteban Fuster Pozzi

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, CRDTs
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 and lazy-loaded optional modules (geo, natural-language queries, audit)

Your Web App
    │
    │ await gdb("my-db", { rtc: true })
    ▼
GenosDB
│
├─► Query Engine      (20+ operators, $edge)
│
├─► Security Manager  (RBAC · ACLs · WebAuthn)
│
├─► Optional Modules  (geo · nlq · audit)
│
└─► 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 + LWW CRDT	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
Adaptive cell sizing — with cellSize: 'auto', cell size recalculates dynamically toward a configurable targetCells, clamped between min and max bounds
Deterministic bridge election — inter-cell bridges are chosen by a per-edge hash of the shared roster, with no coordinator and no negotiation, so every peer independently elects the same bridges
Per-peer health metrics (monitoring) — a composite healthScore is tracked for diagnostics and exposed via the mesh API, independent of bridge election:

healthScore  (monitoring / diagnostics)
│
├─► 0.25 · RTT             (ping window)
│
├─► 0.25 · uptime          (time in mesh)
│
├─► 0.30 · stability       (reconnections)
│
└─► 0.20 · responsiveness  (recent pings)

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
2-second heartbeat with stale-peer cleanup — peers silent for 30s are evicted and bridges are re-elected automatically

The result is a structured, self-organizing overlay network running entirely on pure browser WebRTC. Live visualizations are available in the repository: D3 mesh monitor, Canvas lite, 3D particles.

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, CRDTs

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.

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)
Async content moderation of the oplog via the Audit module

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.

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
Modules	Geo · NLQ · Audit
Project	README · Whitepaper · Examples · Resources · Wiki · DeepWiki · npm

Keywords: GenosDB, GenosRTC, P2P database, WebRTC mesh, decentralized database, browser database, Nostr signaling, CRDT, 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. Since v0.14.0, 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 the user who wrote it.

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 & CRDT 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.

OVGrid is an Open Virtual Grid Metaverse

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

The first true metaverse experience built in a decentralized and open virtual grid.

Explore the decentralized, infinitely scalable, browser-based metaverse built on WebXR and a peer-to-peer architecture.

"Metaverse" is the reigning buzzword in tech. It promises an immersive digital future, but much of the conversation is dominated by closed, centralized ecosystems that replicate the limitations of today's internet. They demand expensive hardware, impose unilateral rules, and are ultimately owned by a single entity.

But what if the future of the metaverse wasn't a walled garden, but an open, limitless universe?

Introducing OVGrid, the Open Virtual Grid — a project that reimagines the metaverse from the ground up. It's not just another platform; it's a decentralized ecosystem designed to be truly open, scalable, and accessible to everyone.

What is OVGrid and Why is it Different?

OVGrid is a distributed metaverse where users can create and share real-time experiences. The key difference lies in its fundamental architecture, which moves away from the traditional client-server model to fully embrace decentralization.

This isn't just a technical choice; it's a philosophy. We believe that users should be the true owners of their digital assets and their experiences.

The Technological Engine of OVGrid

To achieve this vision, OVGrid is built on a stack of disruptive technologies that set it apart from anything else on the market:

True Decentralization with GenosDB

At the heart of OVGrid lies GenosDB, an innovative graph database that enables true peer-to-peer (P2P) communication. Instead of connecting to a central server, each user (or node) connects directly with others within a parcel, forming a dynamic and resilient Cellular Mesh network. This means lower latency, greater privacy, and no central entity with the power to pull the plug on the world.

Infinite Scalability: Incremental Coordinates

Most virtual worlds have a finite map, creating artificial scarcity and limiting growth. OVGrid solves this with a revolutionary concept: incremental coordinates. This allows for a universe with infinite lands. The grid can expand organically without limits, offering boundless potential for creation, exploration, and the digital economy.

Universal Accessibility through WebXR

The biggest barrier to entry for the metaverse? Hardware and downloads. OVGrid eliminates this obstacle by being built on WebXR, the web standard for immersive experiences.

This means you can access OVGrid:

From any modern browser on your PC or Mac.
On standalone VR headsets (like Meta Quest) without needing a PC.
With no heavy downloads or installations. Just click a link, and you're in.

This accessibility makes it inherently social and shareable.

Resilience and Flexibility: Offline First and PWA

OVGrid is designed for the real world. Thanks to its "Offline First" architecture, you can continue to interact and create even if you lose your internet connection. Changes sync automatically when you're back online. Furthermore, it operates as a Progressive Web App (PWA), allowing you to "install" it to your desktop or mobile device for instant access, just like a native app.

What Can You Do in the Open Virtual Grid?

OVGrid's architecture unlocks a universe of possibilities:

True Digital Ownership: Buy, sell, and lease land and assets as NFTs, secured by a distributed system.
Immersive Events and Meetings: Host conferences, concerts, team meetings, or social hangouts in custom virtual spaces.
Training and Education: Create simulations and interactive learning environments that transcend physical barriers.
Digital Art and Galleries: Exhibit and trade digital art in immersive galleries where creators have full control.
Brand Engagement: Brands can build unique, interactive experiences to connect with their audiences in a completely new way.

The Future is an Open Grid

OVGrid is currently in the Pre-Alpha stage, laying the foundation for this ambitious project. We are not building another game or a closed social network. We are building the infrastructure for a truly open metaverse — a digital canvas for a global community of creators, developers, and dreamers to build the future of the internet.

The metaverse shouldn't be a product you consume, but a universe you co-create. And that universe begins with an Open Virtual Grid.

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

Summary of Progress in 2021 Working at OVGrid

Esteban Fuster Pozzi — Tue, 17 Feb 2026 16:36:53 +0000

Testing Multiuser Land Channel

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

In 2021, OVGrid made remarkable progress in developing its metaverse, enhancing the user experience and expanding available functionalities. New virtual reality features were implemented, improving interactivity and immersion. In addition, the platform's performance was optimized, and the capabilities for creating and customizing virtual environments were expanded. These achievements reflect OVGrid's commitment to innovation and leadership in the metaverse space.

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

OVGrid (Open Virtual Grid)

Esteban Fuster Pozzi — Tue, 17 Feb 2026 16:36:52 +0000

An Open, Decentralized Metaverse with Infinite Lands.

In recent years, metaverses have stopped being just a futuristic vision to become a key part of the digital ecosystem. Big names like Decentraland and other virtual worlds have dominated the space, but now comes OVGrid (Open Virtual Grid), a project that not only aims to compete, but to revolutionize the virtual experience.

OVGrid is more than a metaverse. It is an open and distributed space, created with pure JavaScript, offering infinite lands, true decentralization, and an experience optimized for WebXR directly in the browser. Below, we explore why OVGrid is a unique proposal that redefines the rules of the game.

The Heart of OVGrid: A Truly Unlimited Experience

Unlike many other metaverses that limit the extension of their digital lands, OVGrid introduces the concept of infinite lands. What does this mean? That there are no barriers or restrictions for creation, exploration, and expansion within the virtual world.

In OVGrid, any user can own, build, and inhabit a space without worrying about the limitations imposed by a finite land model or speculative markets. This democratizes access and allows creativity to flow without restrictions.

Decentralized Technology: The P2P Metaverse

While other projects depend on centralized servers to function, OVGrid adopts a completely decentralized approach, based on a peer-to-peer (P2P) model. This means that:

No central servers: The virtual world is not controlled by a centralized entity, but distributed among users.
Guaranteed resilience: Decentralization protects the metaverse from interruptions and problems associated with centralized servers.
Total freedom: Users have true control over their spaces and data within the virtual world.

OVGrid not only adopts decentralization as a philosophy, but makes it the core of its functioning.

WebXR Optimization: The Metaverse in Your Browser

One of the biggest challenges of current metaverses is accessibility. Many require complex installations, specialized equipment, or dedicated applications to function. OVGrid breaks with these limitations by being designed specifically for the browser, offering an optimized experience with WebXR.

Key benefits of WebXR in OVGrid:

Total accessibility: You do not need downloads or expensive hardware. A modern browser is all you need to explore OVGrid.
Exceptional performance: Thanks to pure JavaScript optimization, OVGrid offers impressive graphics and minimal loading times, even on mid-range devices.
Universal compatibility: It works perfectly on a wide variety of devices, from desktop computers to mobile phones and virtual reality headsets.

With OVGrid, the metaverse is literally one click away.

Shareable Coordinates: Connect Instantly

Each location within OVGrid has a unique coordinate that can be easily shared as a link. By clicking, anyone can instantly join the exact position in the metaverse, without complications or complex processes.

Imagine organizing a virtual meeting or showing your latest creation in OVGrid and simply sending a link for others to join. It is that easy and powerful.

Competing with Giants: Why OVGrid?

In a landscape where names like Decentraland lead, OVGrid stands out for its unique and disruptive approach:

Land model: Infinite lands vs. limited lands.
Decentralization: 100% P2P vs. partial.
Accessibility: Browser-based (WebXR) vs. requires installation.
Optimization: Smooth on modest devices vs. higher demands.
Sharing: Direct links to coordinates vs. limited.

OVGrid not only offers an alternative, but a better experience in terms of accessibility, freedom, and creative potential.

The Future of the Metaverse is OVGrid

In OVGrid, we believe that the metaverse should be a free, accessible, and infinite place. Our commitment to decentralization, technological optimization, and unlimited creativity allows us to offer a unique experience that empowers users.

Whether you want to build your own world, explore new frontiers, or simply connect with others, OVGrid has a space for you.

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

Building a P2P Collaborative Whiteboard with GenosDB in a Single HTML File

Esteban Fuster Pozzi — Tue, 17 Feb 2026 14:15:27 +0000

Build complex real-time apps without a backend. This collaborative whiteboard runs entirely peer-to-peer, powered by the simplicity of GenosDB.

GenosBoard is a feature-rich, real-time collaborative whiteboard designed to showcase the power and simplicity of GenosDB. It's a complete demonstration of how to build sophisticated, decentralized applications without writing a single line of backend code. All communication, data synchronization, and state persistence happens directly between browsers in a peer-to-peer network.

This isn't just a simple demo; it's a blueprint for the next generation of collaborative tools. The magic lies in GenosDB's hybrid communication model, which this application leverages perfectly:

Persistent State (db.put, db.map): Shapes created, moved, or deleted are saved to the graph database. This state is automatically synchronized across all peers and persists through page reloads, providing a reliable, shared source of truth.
Ephemeral Events (db.room.channel): High-frequency data like live cursor positions and in-progress drag movements are sent through a separate, lightweight messaging channel. This data is never written to the database, ensuring peak performance and preventing unnecessary storage writes.

Core Code

The entire P2P whiteboard works with just a few lines of GenosDB:

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

const db = await gdb("collab-board", { rtc: true });

// Persistent state — shapes sync across all peers and survive reloads
db.put({ type: "shape/circle", x: 200, y: 150, color: "#646cff", radius: 35 });

// Reactive rendering — UI updates automatically when any peer changes data
const { unsubscribe } = await db.map({ query: { type: { $regex: "^shape" } } }, ({ id, value, action }) => {
  if (action === "added" || action === "updated") shapes.set(id, value);
  if (action === "removed") shapes.delete(id);
  render();
});

// Ephemeral channels — high-frequency data without touching the database
const cursorChannel = db.room.channel("cursor-pos");
cursorChannel.on("message", (pos, peerId) => drawRemoteCursor(peerId, pos));

const dragChannel = db.room.channel("shape-drag");
dragChannel.on("message", (data) => updateShapePosition(data));

This hybrid model — persistent graph data combined with ephemeral real-time channels — is what makes GenosDB uniquely suited for collaborative applications. No WebSocket server, no Firebase, no backend at all.

Key Features

Real-Time Collaboration: Draw, drag, and delete shapes, and see changes from other users instantly.
Live Cursors: See where other connected users are pointing on the canvas.
Persistent State: Your drawings are automatically saved in the browser and will be there when you return.
Serverless P2P Architecture: No central server, no websockets to manage, no database hosting fees.
Modern & Responsive UI: A clean, beautiful interface that's a pleasure to use.
Zero Dependencies, Single File: The entire application runs from a single HTML file, demonstrating extreme portability and simplicity.

GenosDB Concepts Showcased

P2P Initialization: Setting up a room with gdb("room-name", { rtc: true }).
Reactive State Syncing: Using db.map() to reactively render the UI from database changes.
Atomic Operations: Modifying the shared state with db.put() and db.remove().
Ephemeral Messaging: Using db.room.channel() for high-frequency, non-persistent data.
Hybrid Data Strategy: The core architectural pattern of combining persistent and ephemeral communication for maximum efficiency.
Modern JavaScript Best Practices: Leveraging top-level await, object destructuring, and efficient event handling.

Build More with GenosDB

If this whiteboard inspires you, explore other real-time applications built with GenosDB:

Dive into the code to see just how few lines it takes to build something this powerful. Start building your own decentralized, real-time application today with GenosDB.

🔗 Try the Live Demo →

🔗 View Source Code →

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

GunDB Explained: Features, SEA Crypto & a Modern P2P Alternative

Esteban Fuster Pozzi — Tue, 17 Feb 2026 01:32:45 +0000

What Is GunDB?

GunDB (also known as Gun.js) is an open-source, real-time, distributed graph database written in JavaScript. Designed with an Offline-First approach and a keep-it-simple philosophy, it enables developers to build encrypted, community-run, peer-to-peer applications directly in the browser.

GunDB is used in production by Internet Archive and HackerNoon, and decentralized alternatives to platforms like Reddit, YouTube, and Wikipedia push terabytes of daily P2P traffic through the GUN network.

Key Features

Real-time data synchronization
Decentralized and distributed architecture with cryptographically secure data replication
Scalability without relying on central servers or a continuous internet connection

Default servers act as backup and propagation checkpoints. Among available adapters, you can use Amazon S3, among others.

When a client-side app (browser) requests data, it merges responses with its local state using a CRDT, then caches the result.

This means:

Next time, the data loads instantly — even offline.
Data is replicated across all browsers that requested it.
If your server goes down, data can still be recovered from other peers.

Losing important information becomes nearly impossible, since all copies would have to disappear simultaneously.

Core Concepts

Real-Time synchronization across peers
Distributed peer-to-peer architecture
Decentralized — no single point of failure
Offline-First with local state merge
Graph Database with CRDT conflict resolution
Radix Storage Engine (RAD)
Standalone JavaScript — no external dependencies
Small bundle size

SEA: Security, Encryption, and Authorization

GunDB's cryptographic layer is called SEA (Security, Encryption, Authorization). It provides:

User authentication with public/private key pairs generated via the Web Crypto API
Data signing — every write operation can be cryptographically signed by its author
Data encryption — end-to-end encryption between users using ECDH key exchange
Proof of work — optional computational proof for rate limiting

SEA is the foundation for building trusted, authenticated applications on top of GunDB. It uses browser-native cryptographic primitives (ECDSA for signing, ECDH for shared secrets, AES-GCM for encryption) rather than external libraries.

Known Limitations

GunDB has been in development for many years — a remarkable achievement for an open-source P2P project. But with that longevity comes accumulated technical debt, which is natural in any long-lived codebase. Some areas where this is most visible:

localStorage as default storage — The default persistence layer uses localStorage, a synchronous API with a ~5MB cap that blocks the main thread. Modern alternatives like OPFS and IndexedDB offer significantly better performance. The RAD (Radix) adapter improves this but adds complexity.
HAM conflict resolution — GunDB uses a Hypothetical Amnesia Machine based on wall-clock timestamps. In distributed systems, clock drift between devices can lead to unpredictable conflict resolution. Newer approaches like Hybrid Logical Clocks (HLC) solve this without relying on synchronized clocks.
Sync after extended disconnections — Prolonged offline periods can result in difficult-to-debug synchronization states, as there is no operation log to replay missed mutations. Without an oplog, there is no way to send only the delta of what changed.
Relay infrastructure — While GunDB is decentralized, it relies on relay servers for peer discovery and data propagation. The default public relays can become bottlenecks under heavy load.
Codebase complexity — Years of incremental development have resulted in a codebase that can be challenging for new contributors to navigate. This is a common pattern in projects that have evolved organically over a long period.
Dependency surface — Gun's install-time dependency tree is large, and with upstream releases paused since 2020 it accumulates unpatched CVEs over time. We itemize the full report — and how a zero-dependency design answers it — in GunDB's supply chain in 2026.

These are engineering trade-offs, not defects — every distributed system makes them. For projects that need different trade-offs (OPFS storage, hybrid delta sync, Cellular Mesh topology), next-generation alternatives like GenosDB were designed from scratch to address these specific challenges.

Plugins and Modules

Users (SEA) — Security, Encryption, Authorization
Storage adapters — file, LevelDB, RAD, and more
Integration — Vue.js, React, and community adapters

Gun Recommended Links

Beyond GunDB: The Next Generation

GenosDB is a next-generation P2P graph database, engineered from the ground up to solve exactly the trade-offs above. It's real-time, serverless and offline-first — like GunDB — but built on a fundamentally stronger foundation: a modular plugin architecture, a Zero-Trust security model with RBAC, Cellular Mesh networking that avoids the O(n²) full-mesh bottleneck, Hybrid Logical Clocks instead of wall-clock conflict resolution, an operation log for true delta sync, and OPFS-based persistent storage. If you're weighing your options, see how it compares across other P2P and distributed databases, or explore GenosDB directly.

My Relationship with GunDB

This guide comes from years spent inside the GunDB ecosystem. Esteban Fuster Pozzi (@estebanrfp) built the official GUN documentation platform — "made with love for the Gun community" — and contributed to the GUN codebase itself, including its vanilla-JS real-time P2P video examples. GunDB's founder, Mark Nadal, is a friend and collaborator.

Pushing GunDB to its limits in real projects is exactly what led to GenosDB. It's not a fork or a reskin — it's engineered from the ground up to keep what makes browser P2P great while solving the trade-offs described above. As the docs put it, "GunDB and GenosDB belong to the same research effort in distributed systems" — GenosDB is where that research goes next.

One of my earliest exchanges with GUN's creator, Mark Nadal, is a story I still like to tell. I'd built an interactive 3D world with Babylon.js, synced over GUN, and we tried to share a 9 MB screen recording of it — but Discord, Telegram and the anonymous file hosts all choked on it. So instead of hunting for another host, I coded a drag-and-drop uploader and a real-time "video sinker" on the spot, and we streamed the clip directly computer-to-computer over GUN — faster than it had taken us to fail with the centralized services. Mark recorded the whole session and posted it on his own channel:

⭐ 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

📚 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

DEV Community: Esteban Fuster Pozzi

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, CRDTs

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 pattern I'm proudest of: the read layer never changes

What "no server" actually means

It's open source — and it documents itself

Serverless P2P Multiplayer in Godot — No Backend, Just GenosDB

The challenge

What is GenosDB?

The key idea: a hybrid model

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

Connecting Godot to GenosDB

The API mirrors GenosDB

Try it / use it

Why this matters

Serverless P2P NFT Marketplace on Polygon — Powered by GenosDB

The problem with most blockchain front-ends

First, what GenosDB is

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

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

What GenosDB actually buys you here

Simplified, but real

Try it / read it

Why this matters

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

Context

What Socket.dev measures

The report: every Socket alert on gun@0.2020.1241

A. Known vulnerabilities (CVEs)

B. Supply-chain behavior

C. Maintenance

D. Quality

E. License

The pattern behind the numbers

The maintainer's own account

How GenosDB produces a different report

1. Zero dependencies

2. Clean vulnerability score

3. A minimal install-time footprint

4. Active maintenance

5. A single declared license

6. Bundle, license, and governance

7. The feature surface is demonstrated, not asserted

The data plane: cryptographic enforcement at runtime

Downloads, and the last word

The ask

Frequently asked questions

Author

Sources & verification

My personal take

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

Why We Left Babylon.js

Bundle Size and Dependencies

GPU Pipeline Control

The Abstraction Tax

Philosophy: Pure JavaScript, Zero Frameworks

The Migration

The Results

When Frameworks Make Sense

What's Next

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