Building OurDrive: An Offline-First Synchronization Engine

Why Offline-First?

In a world of constant connectivity, assuming the network is always available is a critical failure point. OurDrive was built with the assumption that the network is hostile and intermittent.

The Problem with Cloud-First

Most modern apps use a "dumb client, smart server" model. When you press save, a spinner appears while a REST API is called. If you drop into a subway tunnel, the app breaks. For a storage drive app, this is unacceptable.

The Synchronization Engine

We use a variant of Conflict-Free Replicated Data Types (CRDTs) built on top of SQLite triggers.

Hybrid Logical Clocks (HLC)

To order events across devices without relying on a central NTP server, we implemented Hybrid Logical Clocks. Every row in the SQLite database has an hlc_timestamp.

CREATE TABLE files (
  id TEXT PRIMARY KEY,
  name TEXT NOT NULL,
  content_hash TEXT,
  hlc TEXT NOT NULL,
  tombstone INTEGER DEFAULT 0
);

Resolving Conflicts

When two devices modify the same file offline, a conflict occurs upon sync. Using CRDT principles, we can deterministically resolve these without user intervention.

1. LWW (Last-Writer-Wins): Using the HLC, we can accurately determine the true "last" edit, even across massive timezone or clock skews.
2. Tombstones: Deletions are soft. When a file is deleted, it is marked as a tombstone. This allows the deletion event to sync to other devices.

Peer-to-Peer WebRTC

Instead of routing files through a central server, OurDrive establishes WebRTC data channels directly between your laptop and phone.

• It uses a lightweight signaling server built in Rust.
• Files never touch a central hard drive.
• End-to-end encryption (XChaCha20-Poly1305) is applied before data hits the WebRTC channel.

This architectural bet means OurDrive scales infinitely without incurring massive AWS S3 costs.