Mikobase as a Filesystem (brainstorm) GitHub issue

vibecode
{"vibecode": {
    "doc": "mikobase-as-filesystem",
    "role": "brainstorm about exposing a mikobase as a directory-tree filesystem so storage-agnostic consumers (Sammy static, Jasmine stores, directory jails) can use mikobase transparently; explores the two superpowers POSIX cannot offer",
    "key_concepts": ["mikobase_backed_filesystem", "storage_agnostic_consumers",
        "transactions_over_files", "history_over_files"],
    "status": "brainstorm"
}}

Status: brainstorm. Vibing on the idea. Not committed; not specced; just thinking out loud.

The seed: mikobase is a structured data store. Filesystems are also structured data stores, of a particular shape. What if mikobase could be a filesystem — exposing a directory-tree interface backed by mikobase data?

Why it's interesting GitHub issue

The two superpowers GitHub issue

The dir/file/permissions surface is trivial — most filesystems have it. What makes a mikobase-backed filesystem genuinely different is two properties POSIX can't offer.

Transactions GitHub issue

POSIX filesystems can't do multi-file atomic operations. You can't atomically rename a directory while updating its children. Tools work around it (staging dirs, rename-into-place tricks) but the primitive isn't there. With mikobase, anything multi-step that needs all-or-nothing semantics is free:

Time-travel reads GitHub issue

"What was /etc/config.json on 2026-03-15 at 14:22?" is a question almost no filesystem can answer. ZFS/Btrfs snapshots are coarse, point-in-time, opt-in. With mikobase, every read can carry a timestamp parameter:

The combination is more than the sum GitHub issue

"Atomic deploys with instant rollback" is a real product feature. So is "log entries that are reproducible because the world they describe is still queryable." Filesystem-backed systems spend enormous engineering effort getting crude approximations of either; mikobase-as-filesystem inherits both.

POSIX access via SSH and SSHFS GitHub issue

A clean way to handle POSIX-tool compatibility: expose the mikobase as an SSH endpoint. No kernel module to build, no filesystem driver to maintain — we get most of the compatibility-with-the-existing-world story by leaning on SSH.

What this approach still doesn't handle perfectly:

For the vast majority of POSIX use, SSH + SSHFS is plenty.

In-memory mode GitHub issue

A mikobase doesn't have to be disk-backed. An in-memory mikobase that lives in the process's own memory can present the same filesystem interface as a persistent one, just with process-bound lifetime: when the process exits or crashes, the mikobase is gone with it.

This is interesting for a few specific cases where the working set is small:

The in-memory mikobase keeps the mikobase superpowers locally — transactions and time-travel work within the session — so scratch space can still have rollback semantics within a single request or operation.

Not for large-file workloads. A common reason to want a temp directory is to hold a huge file while you work on it (uploaded videos, generated archives, multi-gigabyte intermediates). That's exactly where in-memory storage falls down — RAM is precious and not what you want to use for that. %utils.tempdir therefore stays disk-backed, not mikobase-in-memory backed. The in-memory option is for cases where the data is small enough that RAM is the right place for it.

Linux already has tmpfs, the kernel-level in-RAM filesystem (/tmp, /run, /dev/shm are typically tmpfs). The difference: tmpfs is kernel-managed and persists across process crashes until unmount/reboot. An in-memory mikobase is process-owned and dies with the process. Different scope; better-targeted for the cases above.

FSO and the path forward GitHub issue

By the time the broader FSO (file system objects) abstraction is finished — directory objects, file objects, directory jails, the interface that Sammy's $server.static consumes — a rudimentary mikobase-backed filesystem implementation should be a small additional step. Not committed yet; flagged as a likely outcome of the work that's already happening for other reasons.

Other concerns GitHub issue

As a versioning tool GitHub issue

Time-travel + a labeling layer makes mikobase-as-filesystem a linear-history version control system. Auto-recorded changes, named pointers (alpha, beta, production) to historical states, no explicit commits, no branching. Effectively a simplified RCS — RCS-era linear versioning with modern auto-recording.

Where it shines: content management, configuration repos, data sets, build artifacts, anything where branching is overkill and "linear timeline + named pointers" is what the user actually wants. Git stays the right tool for source code with parallel feature branches.

One real concern: auto-recording every save means lots of intermediate "still typing" noise in the history. Mitigations:

The killer combo: mikobase-as-filesystem + Sammy + Jasmine → "every config change is recorded, every deploy is a tagged state, every request log is reproducible against the exact filesystem state that served it."

Storage shape: chunks vs deltas GitHub issue

The current mikobase plan stores files in chunks. Great for static collections (e.g., a Shakespeare-image archive — flagged for the Unotate conversation) but disastrous for incrementally edited files. A 10 MB file edited 100 times with small changes each save becomes ~1 GB of storage; that's a non-starter for versioning.

The fix is well-trodden territory: delta-based revision storage with periodic full checkpoints.

Prior art is rich (Git pack files, RCS itself, Mercurial revlogs, Fossil, Subversion). Trade-offs to design:

The storage layer becomes content-aware rather than uniform.

Open questions / things to vibe on GitHub issue

(To be filled in.)

Out of scope for now GitHub issue

Brainstorm only. No commitments. The point is to capture the idea and let it ripen.
© 2026 Puck.uno