Architecture

Yogfile is a thin drive service over Nauka, an open storage engine using BLAKE3 content addressing and Reed-Solomon 4+2 erasure coding.

Control plane and data plane

The Yogfile API is the control plane. It owns accounts, drives, folders, version tokens, lifecycle policy, Trash, sharing metadata, and realtime cursors.

Nauka is the data plane. It receives file bytes directly from clients after the API signs a scoped upload grant. Downloads use short-lived signed links with an expiry and concurrency policy.

person / agent / application
        |
        | JSON metadata and signed grants
        v
   Yogfile API
        |
        | short-lived capability
        v
client <--------------------------> nearest Nauka storage node
                file bytes

Why bytes bypass the API

Keeping the API out of the byte path removes a redundant network hop, avoids turning metadata servers into bandwidth bottlenecks, and lets a client talk to the most appropriate storage node.

Filesystem model

The product namespace lives in Yogfile, not in one Nauka space per drive. Stable item IDs, content versions, optimistic concurrency, opaque cursors, and idempotency keys make native clients safe to retry after a crash or network interruption.

Realtime is a wakeup, not the source of truth

Long-held event requests tell a client what changed. The client then reads ordered filesystem deltas or refreshes the relevant directory. A sync: true response means the cursor is no longer sufficient and the current view must be reconciled from the API.