Ryyn (massive multi-device virtual FS)

Apps
116

On a high level this is really something like a Massive Multi-Device Virtual FS. Or multi-device could be exchanged for distributed (but that’s not quite the same still).

Below is an overview of what’s under that.

Ryyn conceptual model (lower level)

Short description:

A workspace holds vaults. Each vault can be mounted anywhere; mounts append to their own stream and merge all streams, so state converges deterministically—with no central log.

  • A workspace is owned by one key.
  • A vault is a shareable, network-resident, dataset created from a local folder.
  • A mount exposes a vault at any path on any device; all mounts of a vault stay in sync.
  • Optional per-path sharing grants read/write access to parts of a vault.
  • The vault is the network source of truth, a mount-partitioned event DAG, and mounts are authoritative I/O projections into it.
  • A workspace can contain any number of vaults. Each vault can be mounted on any* number of devices.

*well, not any, ANY, but a yet unspecified fairly large amount :slight_smile:

In summary: Mountable Vaults are a workspace-scoped, key-owned model where each vault is a network-resident, mount-partitioned event DAG that can be mounted in many places across devices; all mounts converge deterministically by merging the vault’s streams.

Glossary

  • Workspace (forest) — A forest of network-native vault trees, owned by one key, each vault mountable anywhere across devices, all mounts kept in sync.
  • Vault (tree) — Network-native dataset structured as a mount-partitioned event DAG forming an index over the dataset history.
  • Mount (binding/peer) — Writable attachment of a vault tree 1:1 to a local path; maintains a partition of the vault event DAG. Edits flow both ways (mount ↔ vault ↔ mount); all mounts of a vault reflect the same dataset and stay synchronized via the network. Multiple mounts of a vault are peers.
  • Vault DAG — The union of all mount streams for a vault; a logical source of truth reflecting dataset changes.
  • Mount (event) stream — A partition of the logical vault DAG stored in the network. Written to only by its mount.
  • Reconciling — Deterministic merge on a mount that consumes the vault DAG and produces the local filesystem view.
  • Subpath grant — Capability granting R/W to (sub)paths of a vault.
  • Key hierarchy — Workspace key → derivations for vaults/mounts/data/etc.
  • Sync (replicate & reconcile) — Each mount appends to its own stream, fetches all other mounts’ streams, and merges the union locally via deterministic reconciliation, then applies ops reflected by the events, fetching and applying data when needed, keeping the filesystem synced with the other mounts.
  • Worktree (alias) — Developer-friendly synonym for mount.
  • Repo/dataset (aliases) — Developer-friendly synonym for vault.
  • Profile (per-device) — User-composed set of mount points per device.
  • P2P side-channel — Ephemeral signals (presence, hints, metrics). Not part of the event DAG.
  • Hash-identified chunk — The file version manifests use the chunk’s hash as its identifier (integrity), not as the storage locator.
  • Key-addressed chunk containers — Network location is under a public key address derived from the workspace key hierarchy.
  • Deterministic per-chunk key — Encryption key K_chunk = KDF(workspace_scope_key, chunk_hash); symmetric and unique per chunk.
  • Capability grant (per-chunk) — Sharing = passing K_chunk (directly or wrapped) + its location in network (or the chunk); grants just that chunk.
  • Capability grant (per-file-version) — Sharing = passing file link, consisting of the chunk locations, assembly index, and their K_chunk.
  • File link — Used for sharing a file outside workspace. A self-contained descriptor used to fetch, decrypt, and assemble exactly one file version without access to anything else in the vault. (Sharing entire vaults uses a different mechanism.)
                ┌────────────────────────────────────────┐
                │              WORKSPACE KEY             │
                └────────────────────────────────────────┘
                                   │ derives
                          ┌────────┴────────┐
                          │                 │
                    ┌─────▼─────┐      ┌────▼─────┐
                    │  VAULT A  │      │  VAULT B │
                    └─────┬─────┘      └────┬─────┘
                          │                 │
     (logical) VAULT DAG = union of mount streams per vault
                          │                 │
──────────────────────────┼─────────────────┼───────────────────  (network, as a 2D line)
		   (chunks)       │        (mount streams of VAULT B)           
                          │
        ┌─────────────────┴─┬────────────┬───────────────┐
        │                   │            │               │
   STREAM A1            STREAM A2     STREAM A3       STREAM A4
 (written by Mnt A1)   (by Mnt A2)   (by Mnt A3)     (by Mnt A4)

Devices (each mount writes its own stream; all mounts read all streams in the vault):
┌──────────────────────────────┐       ┌──────────────────────────────┐
│ MOUNT A1 @ /work/proj        │       │ MOUNT A3 @ D:\proj           │
│ writes → STREAM A1           │       │ writes → STREAM A3           │
│ reads  ← A1,A2,A3,A4 → merge │       │ reads  ← A1,A2,A3,A4 → merge │
│ reconciles ⇒ local FS view   │       │ reconciles ⇒ local FS view   │
└────▲─────────────────────────┘       └────────────────────────▲─────┘
     └───── (P2P: presence/hints/metrics only; not in DAG) ─────┘
15 Likes