MoobFS

Plan · Inputs, processing, outputs

Where we are going, one milestone at a time.

An agent writes memories as ordinary files with typed attributes; a native kernel layer validates and indexes them over a mature filesystem; any program reads them back and queries them by attribute. Pick a milestone to see which parts exist at that point.

Green boxes are implemented and tested in an isolated Linux VM (one kernel series; ext4, btrfs and XFS): the frozen M1 experiment, the M2 layer (phases 2a–2e) and the POSIX authorization of QUERY (M3 phase 3b), as recorded in the roadmap. White boxes are proposals from ADR-0005, ADR-0007 and the M3 specification; nothing is measured yet (M4) and nothing has been released.

Input

Processing · moobfs layer

Output

Implemented and tested in a VM Proposed, not implemented

Select a box to read what it does and which reference it follows.

The path of one memory, as implemented today

Left: writing a memory. Right: finding and reading it back. Both meet in the in-memory index of the layer, which is fed by the real extended attributes stored in the lower filesystem; each query result is authorized with the caller's credentials before it is returned. Source citations for every step: architecture overview.

Data flow through the MoobFS layerWrite path: client writes a temporary file and typed attributes, syncs and renames; the Linux VFS hands the operations to the moobfs layer, which validates attributes, updates its in-memory index and delegates I/O to the lower filesystem on disk. Query path: the client issues a QUERY ioctl on the mount root, the index answers with inode and path, the client opens and reads the file through the same delegated path, and the application assembles the context. Write a memory Client: git, sqlite, scriptwrite tmp, setxattr, fsync, rename, fsync dir Linux VFS moobfs layervalidates user.moob.* (type, name)updates the in-memory indexdelegates I/O through backing-file Lower filesystemext4, btrfs or XFSjournal, reflink, real xattrs Disk Nothing is trapped: unmounted, the lower treestill holds the files and their attributes. Find and read memories Client issues QUERY on the rootkind = decision AND score ≥ 40 In-memory index of the layerrbtree per attribute, list per inodebuilt at mount from the xattrs Result: inode + relative pathonly what the caller may read; equal to the oracle open + read by pathdelegated to the lower filesystem Context assembled by the applicationsemantic selection stays outside the kernel Outside the kernel by decision: embeddings,ranking, synthesis. That is the client's or M4's job.

How to read the plan

Free software already covers several steps: dm-log-writes and xfstests for crash testing, virtme-ng for instrumented kernels, Haiku's bfs_shell as a behavioral oracle for queries. See the ecosystem survey.