RSS Amplifier

OrbitDB’s Substack · Aug 13, 2025

OrbitDB Roadmap

0
Sign in to vote or save

OrbitDB · OrbitDB’s Substack

With the release of our feature-complete version 3, OrbitDB’s main focus is now 3rd party developer support. OrbitDB’s goal is to become the defacto data storage layer for all decentralized applications and websites.

With the growing concern around privacy, censorship and data ownership, a revolution is currently underway, with a move to local-first, peer-to-peer-driven solutions. Client/server architecture, along with all its inherent problems, is primed for disruption, and a peer-to-peer successor solves many of the former’s shortfalls. Massive data breaches, verification, cumbersome signup/signin procedures, surveillance, censorship; these problems disappear with a local-first, peer-to-peer, decentralized approach.

In order to move users en masse to this architectural alternative, OrbitDB needs to be easy to implement and use. It also needs to be widely available on a number of platforms and in a variety of programming languages. Therefore, we have identified and documented a number of features and functionality we would like to build, which will, in turn, improve and expand OrbitDB’s ecosystem. We have distilled these into a “road map” which is presented below.

Finally, it is important to re-iterate that OrbitDB is an open source project which relies completely on funding from our community. While our core contributors are committed to the project, it is impossible for us to expect free knowledge, work and skills indefinitely. Therefore, we encourage everyone to visit our funding page and help out financially when possible.

OrbitDB is improving support for React Native-based mobile development through the use of pre-tested code and example applications. OrbitDB will also be addressing developer concerns.

Fork https://github.com/ipfs-shipyard/js-libp2p-react-native/ and integrate Helia and, by extension, OrbitDB.

Address any issues within OrbitDB which may be blocking React Native compilation (polyfills, shimming, etc).

Additional references:

https://github.com/orbitdb/orbitdb/issues/1217

https://github.com/TarrenHassman/orbitDB-react-native

This project’s success will be detemined by the successful completion of the project “React Native support for mobile developers”.

Create a simple OrbitDB-based mobile application with the following features:

  • Start/stop an OrbitDB peer

  • Create db

  • Delete db

  • List dbs

  • Add a record

  • Edit a record

  • Delete a record

  • Replicate a db

  • List records

Create a simple web cpanel for managing databases in a browser-only environment. The dashboard provides a simple introduction to OrbitDB for everyday users and developers new to to the concept of peer-to-peer databases and who want to “see OrbitDB in action”.

This is a precursor to “Mission Control”.

Features include

  • Start/stop an OrbitDB peer

  • Create db

  • Delete db

  • List dbs

  • Add a record

  • Edit a record

  • Delete a record

  • Replicate a db

  • List records

Run a OrbitDB peer and managing it through both a cmd line utitlity and web-style UI-based cpanel.

Similar in concept to projects like MySQL Workbench and IPFS Kubo.

Uses the same approach as OrbitDB Voyager.

This project will require both daemon and client to be developed in parallel.

  • A core OrbitDB instance for storing databases on a native file system

  • RPC interface exposing the following endpoints:

    • Start/stop an OrbitDB peer

    • Create db

    • Delete db

    • List dbs stored in browser

    • Add a record

    • Edit a record

    • Delete a record

    • Replicate a db

    • List records

  • A command line client interface for interacting with the daemon.

Extend the web user interface to connect to the daemon.

This project is currently under development at https://github.com/orbitdb/go-orbitdb/.

  • Complete outstanding development

  • Package and deploy

  • Documentation

  • Example implementation

Develop smart contracts for validating access to a database on-chain.

Use cases may include on-chain validation of data replication (canAppend), tokenized validation through the use of native currency or tokens, etc.

Explore on-chain access control for wider application (E.g. @orbitdb/voyager).

Smart contracts WILL NOT BE AUDITED for this project.

Provide a simple smart contract design pattern for 3rd party developer implementations

Sign a record using a wallet and validate its authenticity using an on-chain signature.

Documentation

Demonstrable code/example implementation

Possible scope for an Open Zeppelin-style of smart contract library for 3rd party developers

Create out-of-the-box configurations for OrbitDB Libp2p/Helia implementations:

  • “localhost” connections,

  • “localdomain” connections,

  • Public network connections

Liaise with js-libp2p/helia developers for best connection options for most use cases.

Integrate settings for out-of-the-box connections in the @orbitdb/liftoff package.

Provide an example application using out-of-the-box settings.

Deploy example applications for connecting two peers.

For simplicity, we will exclude mobile developers and address concerns with browser-based and nodejs-based connections.

Identify and iterate on various optimizations to improve OrbitDB’s performance.

Heads sync is not fully scalable. Investigate and implement new heads sync protocol and implementation to improve scalability.

Fix the refs field in the log.

OrbitDB currently takes the last n previous entries as the refs which is similar to "batching" them.

To improve the performance, OrbitDB will instead take every power of 2 entries; so the previous, then 2nd entry backwards, 4th entry, 8th, 16th, etc. This will make the replication (specifically bitswap) (kind of) "pre-fetch" entries further in the history somewhat parallel.

see Out-of-the-box Libp2p/Helia configuration for easier development/deployment

Voyager is OrbitDB’s replication daemon. Voyager provides a way for application developers to ensure OrbitDB databases are accessible 24x7, especially for applications which share local data between users.

Our aim is to release a production ready Voyager which can be deployed by decentralized platform projects which require “always-up” databases instances.

As part of the production release, Voyager should be able to replicate databases that are encrypted using the replication password, that is, it receives encrypted bytes and can decrypt the entries to then replicate the full database, while at the same time the payload is encrypted. This would be the "final missing piece" of "private databases that can be made always available".

Given that each database may have a different password, Voyager would have to add a new CLI command and the respective (CLI) RPC endpoint so that the user can add a password for each db, eg. voyager password add <address> <password> or make it part of the existing commands eg. voyager add <address> <password [optional]>.

No posts

Read the original on orbitdb.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.