OrbitDB

OrbitDB uses IPFS PubSub and CRDTs (Conflict-Free Replicated Data Types) to enable real-time data synchronization across a network of peers. Each peer replicates the database locally, and changes are broadcast and merged automatically, ensuring eventual consistency without a central coordinator.

Instead of a one-size-fits-all store, OrbitDB provides specialized database types for different data models:

• Log: Immutable, append-only log (e.g., chat messages, feed).
• Feed: Mutable log where entries can be added and removed.
• Key-Value: Simple dictionary store.
• Docs: JSON document store queryable by a specified property.
• Counter: Distributed counter for numerical values.

Database permissions are managed cryptographically via access controllers. The creator defines a write access list, which can be:

• A single public key.
• A list of keys.
• An OrbitDB Identity for more complex logic. This ensures only authorized peers can write to the database, while reads can be open or restricted.

OrbitDB uses IPFS (InterPlanetary File System) as its underlying storage and transport layer. All database operations (puts, gets) and the database manifest are stored as IPFS objects (CIDs). This makes the database content-addressable, immutable, and permanently available as long as one peer hosts the data.

To handle concurrent writes in a distributed system, OrbitDB employs CRDTs. These data structures (like G-Sets, LWW-Registers) are mathematically proven to converge to the same state on all peers, regardless of the order of operations. This eliminates conflicts and is ideal for offline-first applications.

Every write operation in an OrbitDB database is cryptographically signed by the peer's OrbitDB Identity. This provides verifiable authorship and integrity for all data entries. Identities can be linked to external providers (e.g., Ethereum wallets via 3ID Connect) for decentralized authentication.

OrbitDB uses CRDTs (Conflict-Free Replicated Data Types) to enable eventual consistency across peers without a central coordinator. Data is replicated directly between peers via libp2p pubsub and stored locally on each node's IPFS instance. This eliminates a central server as a single point of failure or control.

Database write access is managed cryptographically. The creator of a database defines an access controller, typically a list of public keys. Only peers whose keys are in this list can write to the database. This is enforced locally by each peer, not by a central authority.

All data entries are stored on IPFS as immutable Content-Addressed (CID) blocks. The database log itself is a cryptographically linked chain of these CIDs. This ensures data cannot be altered retroactively, as any change would invalidate the hashes for all subsequent entries.

• No Global Consensus: OrbitDB provides eventual consistency, not Byzantine fault tolerance.
• Data Availability: Data is only available while peers hosting it are online, unless pinned to a persistent IPFS node (e.g., Pinata, Infura).
• Sybil Resistance: Access control lists prevent unauthorized writes but do not inherently prevent spam from authorized writers.

Each user runs a local instance of the database. Users have full control over their own data and choose what to replicate from peers. This aligns with the local-first software paradigm, where the user's device is the primary source of truth, enhancing privacy and autonomy.

• vs. Centralized DB (Firebase): No central operator; data lives on user devices.
• vs. Blockchain (Ethereum): Data is not globally replicated by all nodes; only interested peers sync specific databases. This is more efficient but lacks the global state guarantee of a blockchain.

The data structures that enable OrbitDB's eventual consistency and decentralized synchronization. CRDTs are mathematical models that guarantee data convergence across peers without a central coordinator. OrbitDB implements specific CRDTs for different database types, such as:

• G-Set (Grow-only Set) for append-only logs.
• OR-Set (Observed-Remove Set) for key-value stores.
• PN-Counter (Positive-Negative Counter) for counters.

OrbitDB provides specialized database stores, each built on a specific CRDT to model different data patterns. Key types include:

• Key-Value Store (orbitdb-kvstore): A mutable key-value map.
• Event Log (orbitdb-eventlog): An immutable, append-only log.
• Document Store (orbitdb-docstore): For queryable JSON documents.
• Feed (orbitdb-feed): A mutable, ordered log with entry removal.
• Counter (orbitdb-counter): A distributed integer counter.

The subsystem that manages write and read permissions for an OrbitDB database. It defines who can modify the data. Controllers can be simple (write-access for creator only) or complex, integrating with external Decentralized Identifiers (DIDs) or custom logic to create multi-writer, permissioned databases on a P2P network.

A publish-subscribe messaging system built into IPFS. OrbitDB uses pubsub for real-time database replication. When a peer makes a write, it publishes the new operation to a topic specific to that database. Other peers subscribed to the topic receive the update immediately, enabling live sync without manual polling.