What Is GenosDB?

GenosDB (GDB) is a modular, peer-to-peer graph database designed to embed zero-trust security directly in the data layer.

Instead of bolting on identity or permissions through a central server, every peer independently enforces trust with cryptography.

The Solution

Most “decentralized” apps cheat: they use P2P storage, but rely on centralized servers for identity and access control. That single point of trust undermines decentralization.

GenosDB flips this:

• Every operation is signed and verified.
• Roles and permissions live inside the database.
• Peers enforce rules locally, not through a server.

Core Architecture

• Graph-based: data as nodes and edges.
• P2P sync: WebRTC or relay-based updates.
• Reactive queries: subscribe to graph changes in real time.
• Eventual consistency: async propagation, but cryptographically validated.

Security Manager

Security isn’t an add-on — it’s the core engine.

• Identity: every user = Ethereum address (private key secured via WebAuthn or mnemonic).
• Signed ops: all operations signed + verified.
• RBAC: roles (guest → superadmin) define permissions, stored in the graph.
• ACLs: per-node control for fine-grained access.
• Encrypted storage: data tied to user identity keys.

Zero-Trust Entry

New peers get one privilege: create their identity node as guest.
No shortcuts. No backdoors. Promotion requires a superadmin.

Distributed Trust Model

1. Cryptographic signatures — no impersonation.
2. Shared rules — uniform, verifiable.
3. Local enforcement — compromised peers can’t cheat the network.

Security is prioritized over availability: no operation is accepted without verifiable proof.

Why It Matters

GenosDB shows that:

• Identity and trust can live inside a database.
• P2P apps can be zero-trust without servers.
• Collaborative systems (docs, social, multiplayer) can run on a substrate where every action is verified cryptographically.

Resources

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).

📖 Documentation | Full reference guide and API overview

🗂 Repository | Explore production builds

📦 Install via npm | Quick setup instructions

🌐 Website | GitHub | LinkedIn

Invitation

GenosDB is in stable beta: the core engine runs, zero-trust flows are enforced, and P2P sync is live.

Looking for developers to:

• Experiment with it
• Stress test it
• Help shape the roadmap

If you care about security, decentralization, and real-time collaboration, I’d love your feedback.

— Esteban Fuster Pozzi (estebanrfp)

Explore More

• Why I Built GenosDB — the complete technical deep-dive
• GenosDB: Zero-Trust Security for Distributed Systems — how the security model works
• Technical Features of GenosDB — complete feature overview

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

The Decentralized Web

The Decentralized Web, or Web3, represents a new generation of the internet where data is not controlled by large corporations nor stored in centralized servers. Instead, it leverages blockchain technologies, P2P networks, and distributed systems to ensure users have greater control over their data and privacy. This model removes intermediaries, promotes transparency, and reduces the risk of censorship or manipulation.

Rather than depending on tech giants to host and manage our data, the Decentralized Web empowers each user to own their information and actively participate in the network.

Peer-to-Peer (P2P) Networks: The Backbone of Decentralization

P2P networks are fundamental to the Decentralized Web. Instead of relying on a central server, nodes (devices connected to the network) act as equals, sharing resources directly with each other. This not only improves efficiency but also increases resilience against failures or attacks.

A clear example is IPFS (InterPlanetary File System), a P2P network that enables distributed file storage and access. Each file has a unique content-based identifier, ensuring immutability and accessibility from multiple points across the network.

Nostr: A Minimalist Protocol for Decentralized Communication

One of the most exciting developments in the decentralized space is Nostr, a simple yet powerful protocol designed for secure, intermediary-free communication. Nostr enables the creation of social networks, instant messaging, and microblogging platforms that are fully decentralized.

What makes Nostr special is its simplicity: it doesn’t require blockchain or complex consensus mechanisms. Instead, it uses cryptographic keys to authenticate messages and P2P networks to distribute them. This makes it an ideal tool for building censorship-resistant and scalable applications.

GenosDB: Organizing Data in the Decentralized Era

As the volume of distributed data grows exponentially, the need to organize it efficiently becomes critical. This is where GenosDB comes in—a graph-based database technology that represents relationships between entities.

In a decentralized world, GenosDB can be a key player in connecting scattered fragments of data across different nodes. For example, in a decentralized social network, GenosDB could map relationships between users, posts, and comments, enabling fast and accurate queries without compromising privacy.

Graph databases are also particularly well-suited for applications requiring complex relationship analysis, such as personalized recommendations, scientific research, and social network analysis.

The Future: A Decentralized and Resilient Web

The future of the web is clearly leaning toward decentralization. As more people become aware of the risks tied to centralized models—loss of privacy, censorship, single points of failure—solutions like the Decentralized Web, P2P networks, Nostr, and GenosDB gain traction.

Imagine an internet where:

• Your data belongs to you: No one can access it without your consent.
• There are no intermediaries: Interactions happen directly between users, eliminating unnecessary costs.
• Everything is resilient: Even if parts of the network fail, the system keeps running thanks to its distributed nature.
• Innovation is open: Anyone can contribute to building new applications without restrictions imposed by corporations.

This future is not as far as it seems. Projects and communities are already working hard to make it real. Still, challenges remain in terms of mass adoption, usability, and education.

{% youtube Lkw4hQpgt50 %}

Conclusion

For more technical details, check out the 📖 GenosDB Documentation.

Conclusion

The convergence of technologies like the Decentralized Web, P2P networks, Nostr, and GenosDB is paving the way for a fairer, more transparent, and resilient web. Distributed data storage not only safeguards our information but also gives us back control over how we share and use it.

The future of the web will not be just a technical evolution, but a cultural shift toward a more democratic and human internet. Are you ready to be part of this revolution?

Explore More

• Why I Built GenosDB — the full story behind the P2P database
• GenosDB and the Nostr Network — decentralized signaling for P2P apps
• Most Popular P2P Distributed Databases — comparing browser-native options

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 (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.

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

• Documentation
• Gun on GitHub
• Whitepaper
• Distributed Matters

Beyond GunDB: The Next Generation

Inspired by the GunDB ecosystem, GenosDB was created to push P2P databases further — with a modular plugin architecture, zero-trust security model with RBAC, Cellular Mesh networking for scalability, and OPFS-based persistent storage. If you're building decentralized applications and want a modern, actively maintained alternative, explore 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

In modern web development, we’ve reached an inflection point. Users demand experiences that are fast, collaborative, and work offline, but traditional architectures built on centralized servers have become a bottleneck. Synchronizing state between multiple users in real-time is complex, expensive, and fragile.What if we could remove the central server from the equation?GenosDB isn’t just another database; it’s a fundamental answer to this challenge. It’s a P2P, local-first, distributed graph database designed from the ground up to empower developers to build the next generation of web applications: systems that are inherently collaborative, secure, and resilient.In this article, we’ll explore how GenosDB’s unique architecture solves some of the most difficult problems in real-time development.

From Manual Syncing to an Automatic Dataflow

One of the biggest headaches in collaborative applications is state management. How do you ensure that when one user drags a card on a Kanban board, every other user sees the change instantly?GenosDB solves this natively:- Real-time P2P Synchronization: Using GenosRTC (a layer on top of WebRTC), any data change on one device is intelligently and automatically propagated to all other connected peers. You don’t need to set up WebSockets, manage reconnections, or write complex sync logic. It just works.- Cross-Tab Consistency: Thanks to BroadcastChannel, if a user has your application open in multiple tabs, the state remains perfectly synchronized between them with no extra effort.

Your Application, Always Available: Local-First Persistence

What happens if a user loses their internet connection? With a traditional architecture, the application stops working. With GenosDB’s local-first approach, the experience is seamless:- Browser Storage with OPFS: GenosDB utilizes the Origin Private File System (OPFS), a fast and persistent storage space directly in the browser. The application always reads and writes locally, which makes it incredibly fast.- Native Offline Support: Users can continue to work, create, and modify data while offline. As soon as the connection is restored, GenosDB automatically handles syncing the changes with the network.All of this is managed efficiently, using MessagePack for serialization and Pako compression to keep storage usage to a minimum.

Modeling the Real World: The Power of the Graph

Real-world applications aren’t just simple tables and rows; they are networks of interconnected data. A user belongs to a team, a task is assigned to a user, a document is linked to another.GenosDB embraces this reality with its graph data model. Instead of forcing your data into rigid structures, you can naturally model entities (nodes) and the relationships (links) between them. This is crucial for social applications, content management systems, and of course, virtual worlds like OVGrid.

Security in a Serverless World: The SM + RBAC Module

Decentralization introduces a critical question: if there’s no central server, who controls permissions? How do we prevent a malicious actor from deleting everyone’s data?This is where GenosDB’s Security Manager (SM) with Role-Based Access Control (RBAC) becomes a revolutionary feature:- Cryptographic Identity: Every user owns their identity, secured with modern cryptography through WebAuthn (passkeys, biometrics). No more passwords.- Signed Operations: Every write operation (put, link, remove) is digitally signed. The network doesn’t trust; it verifies.- Flexible Role Hierarchy: You can define roles like superadmin, admin, manager, or guest and assign granular permissions (read, write, delete). A guest cannot write data, and a manager cannot delete an admin’s work. These rules are enforced in a distributed manner by every peer on the network.This zero-trust system allows you to build complex and secure P2P applications where permissions and governance are woven into the very fabric of the database.

Conclusion: Start Building the Future, Today

GenosDB is more than a collection of features; it’s a cohesive platform designed for a new paradigm of web applications. Whether you’re building a collaborative tool, a decentralized social network, an app that needs to work offline, or simply want a simpler way to manage real-time state, GenosDB provides the foundation you need.

>

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

Distributed Graph Databases with AI and Geospatial Query Support Modules

In the fast-paced world of web development, the ability to manage data efficiently, in real time, and in a distributed manner is more crucial than ever. GenosDB emerges as an innovative solution — not only due to its robust foundation as a client-side P2P graph database — but also because of its inherently modular and extensible architecture. Today, we explore how this modularity unlocks a new paradigm of possibilities by integrating artificial intelligence directly into its core.

The Solid Foundations of GenosDB

Before diving into its modular extensions, let’s recall the core features that make GenosDB a powerful platform:- Real-Time P2P Synchronization: Using WebRTC (via GenosRTC internal module) and BroadcastChannel, GenosDB allows automatic data sync across multiple peers and browser tabs without a central server.- Conflict-Free Consistency: Powered by Hybrid Logical Clocks (HLC) and a Last-Write-Wins (LWW) conflict resolution strategy, ensuring data convergence even under concurrent operations.- Advanced Client-Side Persistence: Leverages Origin Private File System (OPFS) for efficient storage with fallback to IndexedDB, all managed asynchronously in Web Workers to avoid blocking the main thread.- Optimal Efficiency: Uses MessagePack for binary serialization and Pako (zlib) for compression, minimizing bandwidth and storage usage.

The Power of Modularity: A Growing Ecosystem

The true magic of GenosDB lies in its design, which allows clean and decoupled injection of new features and operators. This is especially evident in its dynamic query and data processing capabilities.

1. A Dynamic and Extensible Query System .map()

The core of data interaction in GenosDB is its .map() method. It’s not just for retrieving data; it’s a live interface supporting:- Rich and Familiar Operators: A built-in set of operators ($eq, $ne, $gt, $gte, $lt, $lte, $in, $between, $exists, $text, $like, $regex) enables precise filtering.- Complex Logical Queries: Use of $and, $or, and $not allows building advanced logical conditions, applied recursively via createFilter.- Access to Nested Fields: With getNestedValue, it’s possible to query and sort by deeply nested fields within node value objects (e.g., user.address.city).- Pagination & Sorting: Full control over results with $limit, $after, $before, and order (asc / desc) on any field.- Real-Time Updates: By providing a callback function, .map() becomes reactive — emitting initial, added, updated, and removed events, essential for dynamic UIs.

2. Smart Integration: AI-Powered Data

GenosDB enhances data handling with natural language queries that integrate seamlessly into the query flow.

NL-Enhanced Data Processing

How it works: The GenosDB instance is wrapped. When using .map(), a prompt option can be passed.The Process:- GenosDB filters nodes using standard operators.- The value of the resulting nodes, along with the user prompt.- The AI is instructed to modify fields within the value objects and return a JSON array with the same structure and transformed data.Use Cases: Data enrichment, translation, summarization, content generation, classification, etc. — all within the query stream.

NL-Guided Query Generation

How it works: Similar setup with natural language queries (via a dedicated module).- Instead of a structured query object, users can pass a natural language prompt to .map() (e.g., “find active users from Spain”).- This prompt is sent to the API with instructions to convert it into a structured GenosDB query object (with query, order, field).- The generated query is then executed as the original .map() call.Use Cases: Makes queries accessible to non-technical users, enables natural language search, and simplifies flexible query UI design.

3. Conquering Space: Geospatial Operators

For applications that handle location data, GenosDB provides a geospatial operators module.New Available Operators:- $near: Filters nodes whose coordinates (e.g., node.value.location.latitude, node.value.location.longitude) are within a specific radius (in kilometers) of a given center point.- $bbox: Filters nodes whose coordinates fall within a geographical bounding box defined by min/max latitudes and longitudes.Seamless Integration: These operators can be used in the .map() query object like any standard operator, allowing geographic filters to be combined with others.Distance Calculation: Includes an internal function for Haversine distance calculation between two geographic points.

What Makes GenosDB Unique?

The combination of these features and its modular design make GenosDB stand out:- Merging Worlds: One of the few (if not the only) client-side solutions to natively and modularly integrate graph databases, P2P sync, advanced persistence, and now, AI and geo-extensions.- True Decentralization with Local Intelligence: Doesn’t rely on a central server for business logic or sync, yet can extend local capabilities via controlled interaction with external APIs (like AI).- Extensibility at its Core: The ease of adding new operators and processing modules (as demonstrated with AI and Geo) means GenosDB can evolve with any application’s needs.- Enhanced Developer Experience: Using natural language for queries (via AIQuery.js) or enriching data on the fly (via AIModule.js) simplifies complex tasks and enables new data interaction patterns.- Client-Side Efficiency and Autonomy: Running mostly on the client with optimized storage and async processing, it reduces server load and delivers faster, more resilient UX.

The Future is Distributed, Intelligent, and Modular

GenosDB isn’t just a database — it’s a platform for building the next generation of decentralized and intelligent web applications. Its modular architecture invites the community to contribute new operators, processing systems, and extensions, shaping a future where client-side database capabilities are limited only by our imagination.If you’re seeking an innovative way to handle graph data, sync it in real time, and extend its power in previously unthinkable ways — GenosDB deserves your attention.

>

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

• remove(id): Deletes a node and all of its associated edges.- clear(): Wipes all data from the local database.- use(middleware): Registers a middleware function to validate or transform incoming P2P operations before they are applied, enabling custom security and business logic.

  Querying & Data Access

  The map(...args) method is the heart of data retrieval in GenosDB, offering both static and real-time querying capabilities.- Powerful Filtering: Supports MongoDB-style queries, sorting, and pagination ($limit, $after).- Real-Time Reactivity: By providing a callback function, map enters a reactive mode. The callback receives event objects for all matching nodes, keeping your UI perfectly in sync with the database state.- Event Object: The callback receives ({ id, value, action, edges, timestamp }).- Event Actions: 'initial' (for the starting dataset), 'added', 'updated', and 'removed'.- Recursive Graph Traversal (**$edge**): A standout feature is the $edge operator. It allows you to perform complex, multi-hop traversals in a single query. You define a query to find the starting nodes, and the $edge sub-query filters all their descendants, returning a flat list of matching nodes from anywhere in the hierarchy.

  Concurrency & Consistency

  GenosDB is designed for distributed environments where conflicts are inevitable.- Hybrid Logical Clocks (HLC): Every operation is timestamped with an HLC, which combines physical time with a logical counter. This ensures a causal ordering of events across all peers.- Last-Write-Wins (LWW): Conflicts are automatically resolved using an LWW strategy based on the newest HLC timestamp. The system includes safeguards to prevent abuse from clients with manipulated system clocks.- Clock Sync: The local HLC is intelligently updated upon receiving remote operations, ensuring the causal chain is maintained across the network.

  P2P Synchronization & Networking (GenosRTC)

  When initialized with rtc: true, GenosDB enables its powerful GenosRTC module via the db.room object for direct, real-time peer-to-peer communication.- Peer Lifecycle Events: Automatically detect when peers connect or disconnect.- db.room.on('peer:join', (peerId) => ...)- db.room.on('peer:leave', (peerId) => ...)- Data Channels: Send any serializable data (JSON, strings, binary) through named channels. This is perfect for chat messages, cursor positions, or game state updates.- const channel = db.room.channel('channel-name')- channel.send(data)- channel.on('message', (data, peerId) => ...)- Media Streams: Stream audio and video directly to other peers for applications like video conferencing or voice chat.- db.room.addStream(localStream)- db.room.on('stream:add', (stream, peerId) => ...)- Cross-Tab Sync: Uses a BroadcastChannel to ensure consistency between multiple tabs of the same application within a single browser. It automatically handles recovery from tab inactivity.

  Storage & Persistence

  GenosDB prioritizes performance and reliability for its local storage engine.- Primary Storage: It leverages the Origin Private File System (OPFS) for high-performance, file-based storage when available. It uses synchronous file handles (createSyncAccessHandle) for maximum efficiency, falling back to asynchronous APIs or IndexedDB where necessary.- Dedicated Web Worker: All storage I/O is offloaded to a dedicated Web Worker. This prevents the main thread from being blocked and ensures a smooth user experience, even under heavy write loads. File-level locking and a write queue prevent race conditions.

  Performance & Efficiency

• MessagePack: Data is serialized into the compact MessagePack binary format.- Pako (Deflate): Serialized data is compressed using Pako, significantly reducing storage footprint and network transfer sizes.

  Security & Configuration

• End-to-End Encryption: By providing a password during initialization, all persisted data and P2P data channel communications are end-to-end encrypted.- Custom Validation: Use the db.use(middleware) method to implement custom authorization logic (e.g., RBAC) by validating all incoming remote operations against your own rules.

  Feature Summary

  GenosDB is a comprehensive solution for building decentralized, real-time web applications. Its combination of a local-first architecture, a powerful graph query engine, and seamless WebRTC-based P2P synchronization makes it an ideal choice for collaborative tools, multiplayer games, and any application that demands reactive data and offline capabilities without server dependencies.

>

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

By the end of this guide, you’ll understand not only what makes a true browser-native P2P database possible, but why it matters.

For developers building the next generation of web applications, the promise of a truly peer-to-peer (P2P) architecture is the ultimate goal: real-time collaboration, offline-first functionality, and resilience without costly, centralized servers.

But the journey to find the right “P2P database” is a treacherous one. The landscape is a confusing maze of protocols, libraries, and databases, many of which carry a legacy from a server-first world.

This guide is a developer’s map through that maze. We will start with the broad universe of distributed data technologies, apply a strict filter to find what is truly viable for modern, browser-native applications, and ultimately discover the solution that meets today’s demands for performance and security.

Step 1: The Great Filter — Separating Protocols from Products

The first challenge is that many technologies listed as “P2P databases” are actually low-level protocols or libraries, not integrated database solutions. They provide the building blocks but leave the hardest parts — storage, querying, and conflict resolution — to the developer.

Let’s apply our first filter: Is it a complete database, or a state synchronization library?

• Libraries like Yjs, Automerge, and Trystero: These are brilliant CRDT and P2P communication libraries. They are exceptional at synchronizing the state of a JSON object or a text document in real-time. However, they are not databases. They don’t provide a persistent storage engine or a query API out of the box.
• You still need to build your database on top of them, often by pairing them with IndexedDB.

Our quest is for a complete, out-of-the-box database. So, while these libraries are a crucial part of the ecosystem, we’ll set them aside for now.

Step 2: The Browser-Native Filter — Node.js vs. The Web

The next, and most critical, filter is: Can it run entirely within the browser, without a required Node.js runtime or backend daemon?

This is where the majority of powerful distributed technologies are eliminated for our specific use case.

• Technologies like Hypercore Protocol (with Hyperbee), BigchainDB, and KappaDB: These are powerful, server-first P2P technologies. They are designed to run in environments with full filesystem and network access, like a Node.js server. While it’s sometimes possible to bridge them to a browser via WebSockets or WebRTC relays, this introduces a centralized component and complexity that violates our “truly P2P, browser-native” requirement.
• They are not designed to be initialized and run directly and solely from a user’s browser tab.

After applying these two strict filters, the vast landscape shrinks dramatically. We are left with a handful of contenders that have genuinely attempted to solve the browser-P2P database challenge. This is where the real comparison begins.

Step 3: The Old Guard — A Look at the Pioneers

Two names have dominated this space for years: GunDB and OrbitDB. They were groundbreaking and laid the foundation for what was possible. Let’s analyze them with a modern developer’s perspective.

GunDB: The Resilient Veteran

GunDB is a legend. It was one of the first to offer a truly serverless, P2P graph database that runs in the browser.

• Strengths:
  • Truly Decentralized: It achieves P2P communication without mandatory servers, a remarkable feat.
  • Resilient: Its CRDT-inspired approach to conflict resolution makes it robust.
• Modern-Day Challenges:
  • Mature Architecture: Built with earlier JavaScript conventions, the codebase may require some adaptation for developers accustomed to modern tooling and workflows.
  • Performance Considerations: In high-throughput scenarios, its resource usage may require careful tuning, especially for performance-sensitive applications such as VR or real-time gaming.

Verdict: A pioneering technology that proved the concept, but its architecture shows its age. For new projects demanding peak performance, it presents significant hurdles.

OrbitDB: The IPFS-Powered Log

OrbitDB takes a different approach, building on the ambitious IPFS (InterPlanetary File System).

• Strengths:
  • Immutable Data: Its event-log structure is excellent for applications requiring a full history of changes.
  • IPFS Integration: A natural fit if your application is already invested in the IPFS ecosystem.
• Modern-Day Challenges:
  • Heavy Dependency: js-ipfs, the browser implementation of IPFS, is notoriously resource-intensive, increasing bundle size and memory usage.
  • Browser Limitations: The browser version of IPFS often relies on gateway servers or has persistence issues, compromising the “truly P2P” ideal.

Verdict: An interesting choice for IPFS-native apps, but its heavy dependencies and browser performance issues make it a difficult recommendation for general-purpose web apps.

“These systems proved what was possible — but the web itself has evolved. Today’s browsers, APIs, and performance expectations call for a new foundation.”

Step 4: The Paradigm Shift — Introducing GenosDB

After exploring the strengths and limits of earlier solutions, it becomes clear that a new generation of P2P databases needs to approach the browser differently — one that blends performance, simplicity, and resilience by design.

GenosDB is a distributed, real-time graph database built for the modern web from the ground up. It doesn’t compete with the pioneers — it builds on their lessons.

How GenosDB Evolves the Model

Performance by Design: GenosDB employs debouncing as a first line of defense against transmission overload. Instead of relying on cascading ACK chains like in GUN’s mesh, it manages load proactively — coalescing writes, batching network operations, and balancing disk I/O. This prevents backpressure before it occurs, keeping both peers and the UI responsive under heavy load.

Modern Persistence: By using the Origin Private File System (OPFS) for high-throughput, non-blocking storage, GenosDB achieves the performance of native databases directly in the browser, with zero external dependencies.

Efficient Communication: The WebRTC-based sync layer was rewritten for predictable behavior and low overhead, avoiding redundant message floods through a debounced task pipeline.

Compact & Secure: Data is serialized with MessagePack and compressed with Pako, ensuring minimal footprint over the wire. A built-in Security Manager (SM) brings RBAC and WebAuthn support for a zero-trust environment — something older P2P databases never had to tackle directly.

Developer Experience: Its modular, asynchronous design makes it approachable yet powerful. The graph API supports advanced recursive traversals and reactive queries out of the box.

“Here’s a quick summary of how the leading P2P databases compare in focus and strengths.”

GunDB

• Vibe: The Resilient Pioneer.
• Best For: Simple, decentralized apps where resilience is key and performance is not critical.
• Watch Out For: Legacy architecture, potential performance issues, and unpredictable states in complex apps.

OrbitDB (with js-IPFS)

• Vibe: The IPFS-Native Log.
• Best For: Applications deeply integrated with the IPFS ecosystem that need an immutable history.
• Watch Out For: Heavy performance overhead, large bundle size, and browser-related complexities of IPFS.

GenosDB

• Vibe: The High-Performance Modern Successor.
• Best For: New, demanding web applications requiring real-time collaboration, high performance, modern security, and a superior developer experience.
• Key Features: OPFS storage, built-in RBAC + WebAuthn, lightweight P2P layer, advanced graph database built with a Zero-Trust Security Model

Choosing the Right P2P Database

GunDB remains one of the most important milestones in the journey toward a decentralized web. Its community, perseverance, and years of experimentation proved that a peer-to-peer database could truly run in the browser — long before most believed it was possible.

GenosDB was built from the ground up to redefine data synchronization on the web through its innovative GenosRTC protocol.

It takes a different approach — a modular, top-level-await factory design — where every layer, from the storage engine to the real-time network flow, is engineered to remove the bottlenecks and assumptions that have constrained peer-to-peer systems for years.

Driven by an obsession with speed, stability, and simplicity, GenosDB delivers a truly modern architecture — built for today’s web and ready for what comes next.

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

GenosDB is a name with meaning intrinsically linked to the nature of graphs, providing clear identity, conceptual relevance, and competitive advantage in describing the fundamentals of a distributed database.The term genos originates from the Greek word γένος, meaning: origin, lineage, class, type, or family. This makes it conceptually appropriate for a graph-based database, as it reflects hierarchical structures and relationships between nodes.Key reasons that led me to name my distributed database project “GenosDB”:- Represents hierarchical and inheritance relationships:- In graphs, connections often reflect structures such as lineages, types, or categories. Genos evokes these ideas, which are natural for modeling interrelated data.- Evokes structure and organization:- It reflects how nodes can be grouped into “families” or classes, which is useful for semantic or knowledge graphs.- Unique and memorable:- It is not saturated in search engines or the tech ecosystem, which facilitates identity and positioning.- Compatible with the GDB acronym:- It maintains coherence with the project’s initials without causing confusion with existing databases.

>

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

Introduction to NostrNostr, short for “Notes and Other Stuff Transmitted by Relays”, is an emerging technology that is revolutionizing how we think about online communication. Unlike traditional social media platforms, Nostr is built on principles of decentralization and privacy, offering users unprecedented control over their data and communications.

Core Technologies Behind Nostr

1. Decentralized ArchitectureNostr employs a decentralized architecture where relays act as intermediary nodes to transmit messages between users. This eliminates the need for a central server, reducing the risks of censorship and system failures.2. End-to-End EncryptionSecurity is a core priority in Nostr. All communications are end-to-end encrypted, ensuring that only intended recipients can read the messages. This protects user privacy and prevents unauthorized access to data.3. Cryptographic KeysNostr uses cryptographic key pairs (public and private) to authenticate users and sign messages. The public key serves as a unique identity, while the private key is used to sign messages, ensuring authenticity and integrity.4. RelaysRelays are servers that store and forward messages. Anyone can run a relay, contributing to the network’s decentralization. Users can choose which relays to connect to, giving them control over how their data is handled.5. Open ProtocolNostr is an open protocol, meaning any developer can build applications that are Nostr-compatible. This fosters innovation and diversity within the ecosystem, allowing new ideas and solutions to emerge.

Advantages of Nostr

1. Privacy and SecurityWith end-to-end encryption and cryptographic key usage, Nostr offers a high level of privacy and security. Users have full control over their data and communications.2. Censorship ResistanceNostr’s decentralized architecture makes it resistant to censorship. There’s no central point of control, making it difficult for any entity to block or manipulate content.3. InteroperabilityAs an open protocol, Nostr enables seamless interaction between different applications. Users can switch apps without losing their data or connections.4. User ControlUsers maintain complete control over their data and can choose which relays to connect to. This flexibility allows them to shape their network experience according to their preferences. %[https://www.youtube.com/watch?v=0YDj1QdL2Zs]

Related LinksFor more information about Nostr and its technology, you can visit the following links:- Official Nostr WebsiteNostr represents a significant step toward a more decentralized and private web. As more people and developers adopt this technology, we can expect a transformation in how we interact and share information online.

>

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

RBAC stands for Role-Based Access Control, a widely used security model for managing permissions and restrictions in software systems, applications, or databases. Instead of assigning permissions directly to individual users, RBAC organizes permissions into roles, which are then assigned to users.

How RBAC Works

RBAC is based on three core concepts:1. RolesA role is a collection of permissions that defines what a user can do within the system. Examples:- admin: Can perform all operations.- editor: Can create and modify content, but not delete it.- guest: Can only read content.2. PermissionsPermissions are specific actions a role can perform. Common examples include:- read: View data.- write: Create or modify data.- delete: Remove data.- publish: Publish content.3. Role AssignmentEach user in the system is assigned one or more roles, depending on their responsibilities. Examples:- User Alice has the admin role.- User Bob has the editor role.Optional: Role InheritanceIn some systems, roles can inherit permissions from other roles. For example:- The admin role inherits all permissions from editor and adds extra permissions like delete.

Practical Example

Imagine a web app with the following roles and permissions:

const roles = {  superadmin: { can: ["assignRole"], inherits: ["admin"] },  admin: { can: ["delete"], inherits: ["manager"] },  manager: { can: ["publish"], inherits: ["user"] },  user: { can: ["write"], inherits: ["guest"] },  guest: { can: ["read"] },};

Explanation:- superadmin: Can assign roles and inherits from admin.- admin: Can delete content and inherits from manager.- manager: Can publish content and inherits from user.- user: Can write content and inherits from guest.- guest: Can only read content.Example in Use:If a user with the user role tries to perform delete, access will be denied because user doesn’t have that permission.

Advantages of RBAC

1. Simplified Permission ManagementYou manage permissions at the role level instead of individually per user — ideal for systems with many users.2. ScalabilityAs your user base grows, you only need to assign roles — no need for manual permission handling per user.3. ConsistencyUsers with similar responsibilities receive the same permissions, reducing configuration errors.4. Enhanced SecurityRestricting actions to specific roles minimizes the risk of unauthorized access or accidental changes.5. FlexibilityYou can customize roles and permissions to match the specific needs of your application.

Common Use Cases

• Web Applications: Control who can access pages or perform specific actions (e.g., edit a post, delete a comment).- Databases: Restrict access to tables or records based on user roles.- Blockchain & Metamask: In your project, RBAC integrates with WebAuthn for authentication, assigning roles to blockchain addresses and checking permissions before critical operations.- Enterprises: Used to manage access to internal resources like file systems, collaboration tools, and enterprise apps.

  RBAC vs. Other Access Control Models

  Model**Description**RBAC (Role-Based)Permissions are assigned to roles; roles are assigned to users.ABAC (Attribute-Based)Permissions are granted based on user, resource, or environment attributes.DAC (Discretionary Access Control)Resource owners decide who can access their resources.MAC (Mandatory Access Control)The system enforces strict security policies based on classification levels.RBAC is the most common due to its simplicity and flexibility.

  Summary

  RBAC is an efficient and scalable way to manage permissions in complex systems. In your project, RBAC enables:- Defining role and permission hierarchies- Assigning roles to authenticated users (e.g., via Metamask)- Verifying permissions before executing critical operationsThis approach not only strengthens security but also simplifies user and access management within the system. 🚀

>

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

GenosDB integrates a robust Role-Based Access Control (RBAC) module designed to secure peer-to-peer distributed graph databases through cryptographically verifiable user identities and permissions.Key Concepts:• Identity Management:Users are identified by their Ethereum addresses. Authentication supports WebAuthn (biometric or hardware key protection) and mnemonic phrase recovery. Private keys are securely managed to sign database operations.• Role Hierarchy and Permissions:Roles such as guest, user, admin, and superadmin define granular permissions (e.g., read, write, assignRole). Roles and assignments are stored within GenosDB itself as part of the synchronized distributed state.• Superadmins:One or more Ethereum addresses can be configured as superadmins with elevated privileges, including exclusive rights to assign roles to other users.• Secure P2P Operations:Every outgoing database operation is cryptographically signed by the active user’s private key. Incoming operations from peers are verified for valid signatures and checked against the user’s assigned permissions before acceptance.• Encrypted Local Data Storage:Data tied to users is compressed and encrypted using keys derived from their Ethereum identities, ensuring privacy even in distributed environments.Operational Flow:1. Initialization:RBAC is activated on a GenosDB instance by initializing a security context and optionally defining superadmin addresses.2. Authentication:Users authenticate via WebAuthn or mnemonic phrases, activating local signing capabilities.3. Role Assignment:Superadmins assign roles to user Ethereum addresses within the distributed database, with optional expiration of assignments.4. Real-Time Enforcement:Signatures and roles are verified on all nodes for each operation, ensuring integrity before changes propagate across the network.5. Security State Monitoring:Callbacks allow applications to dynamically respond to changes in authentication or permission states.Benefits:• Decentralized and cryptographically secure permission management without a central server.• Natural integration of blockchain-based identities with real-time P2P synchronization.• Granular access control, ideal for complex distributed applications.- No requirement for traditional identity management protocols like SCIM, SAML, or SSO, simplifying architecture and user experience.

RBAC in GenosDB — Brief Overview

GenosDB features a secure Role-Based Access Control (RBAC) system built for peer-to-peer distributed databases using Ethereum-based identities.- Users authenticate with Ethereum addresses via WebAuthn or mnemonic phrases.- Roles (guest, user, admin, superadmin) control fine-grained permissions.- Superadmins hold exclusive rights to assign roles within the network.- All database operations are cryptographically signed and verified across peers.- Data is encrypted locally, ensuring privacy in a distributed environment.- No need for traditional identity protocols like SCIM, SAML, or SSO, reducing complexity.This enables decentralized, real-time permission enforcement ideal for scalable, trustless applications.

>

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

Imagine building a real-time application where users can register with biometrics, publish secure data, share editing rights, and visualize geolocation on a map — all without deploying a backend server.In this tutorial, we are going to build dProp, a decentralized real estate marketplace. We will use GenosDB, a P2P database that runs entirely in the browser, to handle authentication, data storage, and real-time synchronization.By the end of this guide, you will have a single-file HTML application with:- Real-time updates (Reactive UI).- Biometric Authentication (WebAuthn).- Granular Access Control (ACLs) for collaborative editing.- Dark Mode support.

The Stack

- Frontend: Vanilla JS + HTML5.- Styling: TailwindCSS (via CDN).- Maps: Leaflet.js.- DB: GenosDB (P2P, Client-side).

Step 1: The Setup

We start with a basic HTML5 structure. Because GenosDB is modular and efficient, we can build this entire app in a single file using ES modules.HTML

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

We add a simple Dark Mode toggle script that checks localStorage or system preferences to apply the .dark class to the HTML tag.

Step 2: Initializing the P2P Database

To make our app “Real-time” and “Secure,” we need to initialize GenosDB with specific modules enabled.JavaScript

const APP_ROLES = {    admin: { can: ["deleteAny"], inherits: ["user"] },    user: { can: ["write", "link"], inherits: ["guest"] },    guest: { can: ["read"] }};async function initApp() {    // Initialize GenosDB    db = await gdb("dprop-v2", {        rtc: true, // Enables WebRTC for P2P sync        sm: {            superAdmins: ["0x..."], // Required for boot            customRoles: APP_ROLES,            acls: true // Enables Node-Level Permissions        }    });    // Reactive Auth Listener    db.sm.setSecurityStateChangeCallback(updateAuthUI);}

What’s happening here?- rtc: true: Activates the P2P layer so browsers can exchange data directly.- sm** (Security Manager): Activates the cryptographic identity system. Users are identified by Ethereum addresses, not database IDs.- acls: true: This is crucial. It enables Access Control Lists*, allowing us to define exactly who* can edit a specific property.

Step 3: Biometric Authentication (No Passwords!)

Forget storing hashed passwords. We use GenosDB’s built-in Identity Management to generate a cryptographic wallet and protect it with WebAuthn (FaceID, TouchID).JavaScript

// 1. Generate a new Identity (Mnemonic based)window.generateIdentity = async () => {    const id = await db.sm.startNewUserRegistration();    // Display id.mnemonic to the user securely};// 2. Protect it with Biometricswindow.protectIdentity = async () => {    await db.sm.protectCurrentIdentityWithWebAuthn();    // The private key is now encrypted with the device's hardware security module};// 3. Loginwindow.loginWebAuthn = async () => {    await db.sm.loginCurrentUserWithWebAuthn();};

When a user logs in, db.sm signs every database operation they perform. This guarantees data authenticity without a server verifying sessions.

Step 4: Publishing Secure Data with ACLs

When a user publishes a house, we don’t just dump JSON into the DB. We use ACLs (Access Control Lists) to ensure only the owner can edit it later.JavaScript

const propertyData = {    type: 'Property',    title: 'Luxury Villa',    price: 500000,    owner: currentUserAddress, // Stored for UI logic    status: 'available'};// Save with ACL protectionawait db.sm.acls.set(propertyData);

By using db.sm.acls.set, the node is created, and the creator is automatically assigned Owner privileges (Read, Write, Delete). Any attempt by another peer to modify this node will be rejected by the P2P validation middleware.

Step 5: The “Magic” Real-Time Stream

This is the heart of dProp. We want the UI to update instantly when anyone changes a property status or adds a listing. We use db.map() in realtime mode.JavaScript

async function performSearch() {    // 1. Define Query    const query = { type: 'Property', status: { $ne: 'deleted' } };// 2. Subscribe to changes    const { unsubscribe } = await db.map({        query: query,        realtime: true, //  {        // This callback fires on 'initial', 'added', 'updated', or 'removed'        handleRealtimeUpdate(id, value, action);    });}

How it works:- realtime: true: Keeps the connection open.- action: Tells us if a node was added, updated, or removed.- Cursor Pagination: We can use $after to implement "Load More" functionality without re-fetching the whole list.

Step 6: Collaborative Editing (Sharing Access)

A unique feature of dProp is allowing owners to share write access with other users (e.g., a real estate agent).JavaScript

window.confirmShare = async () => {    const propertyId = document.getElementById('share-node-id').value;    const collaboratorAddress = document.getElementById('share-address').value;// Grant 'write' permission to the specific address    await db.sm.acls.grant(propertyId, collaboratorAddress, 'write');    // Update metadata so the UI knows this person is a collaborator    const { result: node } = await db.get(propertyId);    node.value.collaborators[collaboratorAddress] = 'write';    await db.sm.acls.set(node.value, propertyId);};

Now, the collaborator’s browser will validate that they have permission to edit the property, and the network will accept their signed updates.

Step 7: Atomic UI Updates

To ensure the app feels like a native 60fps experience, we don’t reload the page. We perform surgical DOM updates in our callback.JavaScript

function handleRealtimeUpdate(id, value, action) {    const existingCard = document.getElementById(`card-${id}`);    const newCard = createCardHTML({ id, ...value }); // Generate HTML string        if (action === 'removed') {        existingCard?.remove();    } else if (existingCard) {        // Atomic Replacement: Update status/price instantly        existingCard.replaceWith(newCard);     } else {        // Append new item        grid.appendChild(newCard);    }        // Update Map Marker concurrently    updateMapMarker({ id, ...value });}

This logic handles everything: initial load, price changes, status updates (Available -> Sold), and deletion.

What You Built

We just built a Full-Stack application using only frontend code.- Database? Local & P2P (GenosDB).- Auth? Cryptographic & Biometric (Security Manager).- API? None (Direct Peer Sync).This architecture drastically reduces infrastructure costs and increases data resilience. dProp isn’t just a demo; it’s a glimpse into the future of serverless, decentralized web applications.

Resources

- GenosDB Documentation- Live Demo- Full Source Code (GitHub)

>

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

With GenosDB, building a P2P to-do list is as simple as it gets. No server setup, no database configuration — just import and start coding.

Live Demo

Simple To-Do List — Try it live

The simplest path to a distributed, real-time application.

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

Key Features

• Add, complete, and delete tasks with instant P2P sync
• Reactive UI — db.map() streams changes in real-time
• OPFS persistence — data survives page reloads
• Fully serverless — no backend required

Live Demo

Advanced To-Do List — Try it live

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

What You Will Build

A fully functional Kanban board with columns (To Do, In Progress, Done) where tasks sync in real-time across all connected peers — no server required.

Key Features

• Real-time P2P sync — changes appear instantly for all peers
• Drag and drop between columns
• Persistent storage via OPFS
• Zero backend — runs entirely in the browser

Live Demo

Kanban Board — Try it live

GenosDB makes building collaborative tools trivially simple.

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

This example demonstrates the raw simplicity and power of GenosDB: a fully functional, peer-to-peer chat application built with nothing more than vanilla HTML and a few lines of JavaScript.

<!DOCTYPE html>
<ul id='list'></ul>
<form id='form'>
  <input id='who' placeholder='name'>
  <input id='what' placeholder='say'>
  <input type='submit' value='send'>
</form>
<script type=\"module\">
  import { gdb } from \"https://cdn.jsdelivr.net/npm/genosdb@latest/dist/index.min.js\";
  let db = await gdb('chat', { rtc: true });
  form.onsubmit = async e => {
    e.preventDefault();
    await db.put({ type: 'msg', who: who.value, what: what.value });
    what.value = '';
  };
  db.map({ query: { type: 'msg' } }, (id, data, action) => {
    list.innerHTML += `<li><b>${data.who}</b>: ${data.what}</li>`;
  });
</script>

How It Works

• GenosDB handles all P2P communication via WebRTC.
• db.put() writes a message to the distributed graph.
• db.map() reactively streams all messages from any peer.
• No server. No WebSocket setup. No Firebase. Just peers.

Why This Matters

This isn't a toy demo — it's a proof of concept showing that real-time, multi-user applications can be built with GenosDB in minutes, not days.

7 lines. Zero backend. Infinite possibilities.

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

Tech Stack

• GenosDB for decentralized, real-time communication.
• Modern JavaScript (ES modules, async/await).
• Minimal HTML + CSS.

Key Features

• Direct file transfer between peers via WebRTC data channels.
• Automatic peer discovery on join.
• Progress tracking for large files.
• Fully serverless — runs 100% in the browser.

Use Cases

• Decentralized file sharing platforms.
• Peer-to-peer collaborative tools with file exchange.
• Privacy-first file transfer apps (no cloud, no data retention).

Live Demo

Real-Time File Transfer — Join the room and start sharing files with other peers.

GenosDB makes building decentralized, live, browser-native file transfer tools not only possible — but elegant.

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

Tech Stack

• GenosDB for decentralized, real-time communication.
• Modern JavaScript (ES modules, async/await).
• HTML5 audio API + minimal CSS for layout.

Key Features

• Live microphone streaming between peers.
• Automatic peer discovery on join.
• Dynamic DOM updates with audio elements per peer.
• Fully serverless — runs 100% in the browser.

Use Cases

• Decentralized voice chat platforms.
• Peer-to-peer collaborative tools with live audio.
• Privacy-first audio apps (no cloud, no data retention).

Live Demo

Real-Time Audio Streaming — Join the room and start streaming your microphone to other peers.

GenosDB makes building decentralized, live, browser-native communication tools not only possible — but elegant.

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

Tech Stack

• GenosDB for decentralized, real-time communication.
• Modern JavaScript (ES modules, async/await).
• HTML5 video API + minimal CSS for layout.

Key Features

• Live webcam and microphone streaming between peers.
• Automatic peer discovery on join.
• Dynamic DOM updates with video elements per peer.
• Fully serverless — runs 100% in the browser.

Use Cases

• Decentralized video chat platforms.
• Peer-to-peer collaborative tools with live video.
• Privacy-first streaming apps (no cloud, no data retention).

Live Demo

Real-Time Video Streaming — Join the room and start streaming your webcam video to other peers.

GenosDB makes building decentralized, live, browser-native communication tools not only possible — but elegant.

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

GenosDB supports creating nodes and linking them via directed edges. Each node includes an edges array listing the IDs of its connected nodes.

However, GenosDB does not include built-in declarative graph traversal (like Cypher or Gremlin). Instead, traversal is left to the developer, offering full control using standard JavaScript logic (iterative or recursive).

This design is intentional and offers:

• Lightweight core for fast in-browser performance.
• Full flexibility to implement any traversal logic.
• Seamless integration with GenosDB's P2P sync and OPFS-based local storage.

Developers can build custom queries to navigate connected nodes, apply filters, and resolve complex relationships — all with fine-grained control.

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