notes:

notes: [TIMING: 60s | PRIME: Ingroup+Prestige+Emotional] Ko Taranaki te maunga. Ko Patea te awa. Ko Joel Wirāmu Pauling tōku ingoa. Nō Pōneke ahau. He tangata hangarau ahau. Kia ora koutou katoa. So — I'm Joel, I'm a geek based in Wellington. Solution architect at Red Hat by day — networking, containers, Linux. And this is foxing — a filesystem replication tool written in Rust that accidentally grew an AI indexing layer. Built on evenings and weekends. I came to this from telco — Open vSwitch, OpenStack, eBPF for packet inspection. foxing started when I pointed those same eBPF probes at filesystem events instead of network packets. My other life is psychology — Masters at Te Herenga Waka. My thesis was on how people construct common-sense frameworks around intellectual and creative work in a networked world, at a time when the copyright and patent grounding was already straining. Generative AI has shattered the tenuous thread that barely survived the last two decades. I'm exploring a PhD on that question now. I want to show you what foxing does and why the approach matters for research data in Aotearoa.

notes: [TIMING: 15s | PRIME: Emotional] Mandatory dog and cat tax. This is the real infrastructure — the dog sits under the desk, the cat sits on the keyboard.

notes: [TIMING: 60s | PRIME: Moral+Ingroup] Here's the tension. DICOM scans at Otago, NetCDF climate models at NIWA, FASTQ sequences at Genomics Aotearoa, acoustic telemetry VRL files tracking tuna and piharau — none of these carry meaningful metadata at the filesystem level. The metadata lives in spreadsheets, lab notebooks, or filename conventions. You could solve this with a cloud AI service — Azure Cognitive Search, AWS Kendra — beautiful semantic search. But now your research data is in someone else's data centre. For institutions operating under Te Mana Raraunga, that's not an option. Koto Qalo's talk earlier grounded this in Pacific digital sovereignty. In te ao Māori, this tension has a name — kaitiakitanga. The guardian doesn't own the taonga; they hold it for those who come after. That's the design principle foxing is built on.

notes: [TIMING: 55s | PRIME: Prestige+Emotional] This is the core design decision. RAID1 gives you mirroring but chains you to matched disks and the speed of the slowest member. RAID5/6 add erasure coding overhead to every I/O. Hardware controllers are opaque black boxes with their own failure domains. foxing decouples the source from all targets. Source writes at full NVMe speed. eBPF captures the event. Each target has its own worker pool — NVMe in 2ms, NFS in 50ms, S3 in 200ms. If NFS goes down, NVMe keeps replicating. The NFS workers pause, events drain to a journal, and when the mount comes back, a targeted recovery scan replays exactly the missed files. Your fast storage is never held hostage by your slow storage. That's the name — the Quick Fox jumps over the Lazy Dog.

notes: [TIMING: 45s | PRIME: Prestige] Two components. fxcp is the standalone tool — drop-in for cp or rsync, no root needed, runs on any Linux box. foxingd is the daemon — eBPF probes capture every filesystem write at the kernel level. No inotify watch limits, no polling, no scanning. The copy engine auto-selects the right method per target — reflink for same-device XFS, compound NFS RPCs for network targets, io_uring for cross-device large files. You don't configure this. It probes capabilities at startup. For NFS targets, fxcp is 3× faster than cp because it packs OPEN+WRITE+CLOSE into a single compound RPC instead of four separate round-trips.

notes: [TIMING: 55s | PRIME: Prestige+Emotional] I first encountered CAKE working with Dave Täht on the Bufferbloat project — building OpenWrt builds for cheap WiFi access points. Dave's insight was that you could classify traffic into tins by priority — voice packets never get dropped, bulk downloads get dropped freely. That idea stuck with me. When I started building foxing from my Open vSwitch and eBPF background, the realisation hit: filesystem events ARE a flow. Renames are control-plane. Writes are bulk data. A dropped write is caught by the next fsync. A dropped rename leaves a ghost file. These are not equivalent risks — exactly the asymmetry CAKE handles in network QoS. The BBR half is the same intuition. TCP BBR probes bandwidth by increasing send rate and measuring RTT. foxing does the same for storage — probes queue depth, measures completion latency, adapts per target. NVMe at QD=64, HDD at QD=4, NFS using AIMD on compound RPC batch size. TCP congestion control, applied to NFS WRITE RPCs.

notes: [TIMING: 35s | PRIME: Prestige] The numbers. Small file resync — 6.7× faster than cp. NFS — 3× faster via compound RPC bypass. Delta efficiency — 9.8× on large file resync because BLAKE3 Merkle skips unchanged chunks. Event latency — foxingd's 2ms MTTC is unique, no other open-source tool does event-driven file replication at that speed. Integrity — BLAKE3 checksums at zero overhead because the hash is already computed for delta detection.

notes: [TIMING: 35s | PRIME: Prestige] This table is why the RAID1 analogy matters. DRBD gives you 20ms but requires identical block devices and replicates ALL I/O — journals, temp files, everything. Ceph needs a 3-node minimum cluster. lsyncd hits inotify watch limits. foxingd achieves 2ms with zero infrastructure beyond an NFS export on the target. The source writes at full speed, the target catches up at its own pace.

notes: [TIMING: 30s | PRIME: Prestige] This is fxcp copying 21 GB — 17,441 files — in 3.5 seconds. 6.2 GB/s. The output shows copy method selection: 17,438 files via reflink, instant CoW, zero I/O. On resync, it checks directory hashes, skips unchanged subtrees — 38ms. Same principle as git, applied to filesystem sync.

notes: [TIMING: 35s | PRIME: Emotional+Prestige] This is the reveal moment. getfattr on vcop.zip — before enrichment: nothing. After: Dublin Core description, subject keywords, format, type, desktop search tags. user.dublincore.description says it's a first-person shooter with light gun mechanics and polygonal graphics. That was written by Granite 4.1 running locally on GPU — no cloud API, no data leaving the machine. This is the sovereignty argument made tangible.

notes: [TIMING: 35s | PRIME: Prestige+Moral] Now scale and accuracy. Three different ROMs, three unique descriptions. Virtua Cop — correctly identified as a first-person shooter with light gun mechanics. Sega Rally — a racing game with four tracks. Sonic Championship — a fighting game by Sega AM2. The LLM doesn't hallucinate. And here's the portability clincher: all of this survives cp -a. No foxing needed on the destination. Dublin Core is ISO 15836, xattrs are POSIX — international standards on a POSIX filesystem primitive. Your metadata isn't locked into any vendor's database.

notes: [TIMING: 45s | PRIME: Prestige+Moral] Six tiers, same file. None skips enrichment. Minimal and Quick are fully LLM-free, offline — Magika classification and filename-derived tags. Balanced brings in the LLM. At thorough and deep tiers, foxing re-embeds the file using the LLM's output — search quality improves 11–15%. The portability story is the strongest sovereignty argument. Dublin Core is ISO 15836. Extended attributes are POSIX. This isn't a proprietary metadata format — it's an international standard written to a POSIX filesystem primitive. The metadata travels with the file. No database to maintain, no vendor to depend on.

notes: [TIMING: 50s | PRIME: Prestige+Moral] This surprised me. I expected the LLM to be the value. It's not — the deterministic pipeline is. It's a semantic router for your filesystem. Before any file hits Magika or the LLM, the collision map — 3,029 ambiguous extensions generated from the taxonomy's 16,927 entries — gates the dispatch. A .vcf in a genomics directory routes to bioinformatics, not vCard. A Cargo.toml in a Rust project routes to TOML, not Lean 4. Magika is Google's open-source content detection model — trained on millions of files, but it still only reliably detects about 283 types. The real world has 16,927. So before anything reaches the embedding model, we need to gate it. The collision map — 3,029 ambiguous extensions — disambiguates first. For 60% of files, taxonomy confidence is high enough to skip Magika entirely. When Magika does run and its confidence is low on a collision-prone extension, the gate fires and falls back to taxonomy routing. By the time a file reaches the embedding model, all the deterministic content is already resolved — collision class, taxonomy domain, Dublin Core type, foxing group, enrichment hints, confidence gate status. The embedding model receives a fully contextualised input with the taxonomy's embed_string prepended, not a raw byte stream. You don't throw files at a vector model and hope — you route them there with everything the deterministic pipeline already knows. And the whole stack — taxonomy lookup, collision disambiguation, Magika classification, metadata extraction, embedding — adds about 100 milliseconds per file. That's the cost of making a file searchable, with no LLM in the loop. No LLM, no GPU, no network. The LLM adds natural language descriptions at tier 3+ and re-embedding improves search 11–15%. But the router alone produces useful, portable, standards-compliant metadata.

notes: [TIMING: 55s | PRIME: Moral+Ingroup] As Koto Qalo said 35 minutes ago — a system can pass its health check and still violate the authority model of the community it serves. foxing's architecture is designed so the authority model is always the institution, never the vendor. Who controls the metadata? You — it's in POSIX xattrs on your filesystem. Where does the data travel? Nowhere — LLM inference runs via llama.cpp on your GPU, models are Apache-2.0. Who can search it? Whoever you give pgvector access to. There's a gold rush right now to add vector-enriched storage as a cloud value-add. Each ecosystem wants your data as a differentiator for its own embedding models. When you upload your research corpus, you're contributing training signal. foxing inverts this. Enrichment runs on your hardware, vectors stay in your pgvector. Your data improves your search quality, not theirs.

notes: [TIMING: 40s | PRIME: Ingroup+Prestige] Why ROMs? Because a ROM ZIP on a FAT filesystem is structurally identical to a DICOM scan on institutional NAS — nine characters and a file size, no description, no searchability. The demo corpus is 115,000 files across 16 collections. foxing's structural minority detection spots the one XML in 3,000 ZIPs — that must be metadata. Swap galaga.zip for a NetCDF climate model — same pipeline. The enrichment also syncs to pgvector, so any host on the network can query descriptions and embeddings without touching the filesystem. Enrich on one machine, query from anywhere.

notes: [TIMING: 45s | PRIME: Prestige+Moral] FXAR v2 is foxing's archive format — gear-hash variable chunking with BLAKE3 content-addressed storage. Content-defined boundaries survive insertions, so modifying 100 bytes in a 10 GB database only re-chunks the affected region. The format is both seekable and streamable — binary index on disk, footer fallback for piping over SSH. Look at the Writable row in this table. Every other format is read-only after creation. FXAR is updatable. And on Borg's encryption: Borg re-implements AES-CTR inside the archive format, which means your recovery depends on Borg tooling. FXAR delegates to LUKS. The encryption layer does encryption, the archive layer does archiving. Layer cake.

notes: [TIMING: 35s | PRIME: Prestige] The CAS store makes foxing filesystem-agnostic. It breaks files into content-addressed chunks stored in a directory tree sharded by BLAKE3 CID. Works on exFAT, vFAT, NTFS — no xattr support needed. The chunks are self-verifying — the filename IS the hash. The S3 backend uses the same model over HTTP. GearChunker CDC means modifying 100 bytes in a 10 GB file uploads one chunk, not the whole file. Same abstraction end to end — BPF events, CAKE dispatch, SmartCopier, CAS dedup, S3 sync. FXAR is the interchange format connecting all of it.

notes: [TIMING: 40s | PRIME: Ingroup+Prestige] Today at this conference I've heard multiple talks discussing the same problem — fish identification pipelines, beach survey processing, mitochondrial data extraction. There's always a moment where someone says "it would be nice if this ran automatically when new data arrives." Everyone solves it with cron jobs and polling scripts. What if the act of copying the file became the starting gun? foxingd emits a CloudEvents envelope with the BLAKE3 hash, content classification, Dublin Core metadata. Your downstream pipeline triggers the moment the file lands. One pipeline, many applications — replication, semantic search, compliance auditing, ransomware detection. One primitive, composed.

notes: [TIMING: 35s | PRIME: Ingroup+Prestige] foxing is complementary, not competing. REANNZ just told us their datagrid metadata sits in a spreadsheet that gets manually transformed to JSON. That's the gap. Globus delivers the bytes, WEKA provides the NVMe, Ceph-S3 stores the archive — but nobody automatically enriches what arrives or moves data between storage classes based on content. foxing does. It's been tested with hundreds of thousands of files on standard filesystems and S3-compatible object storage. WEKA and GPFS are theoretical — standard POSIX hooks should work, but untested on parallel FS. One binary, GPL, runs on any Linux box with an NFS export.

notes: [TIMING: 25s | PRIME: Emotional+Ingroup] The repo is on Codeberg, packages in Fedora COPR. 1117 unit tests, 19 adversarial scenarios, 31 ADRs. Built by one person — now needs a community. If you work with research data, if you've dealt with the metadata problem, if you know Rust or eBPF or NFS — I'd genuinely welcome contributors. Ngā mihi nui. Questions?

notes: The TLS number is the sleeper — fxcp under TLS is actually faster than cleartext AUTH_SYS. That's because kernel kTLS offloads the encryption to hardware AES-GCM, and TLS eliminates the 3,952-byte krb5p AES block boundary that limits the compound bypass under Kerberos privacy. The 200× krb5p resync is real — fxcp checks the BLAKE3 hash locally, while cp re-reads and re-writes every file through the encryption layer.

notes: This is the money shot. vcop.zip — eight characters. Minimal tier: Magika classifies it as a ZIP. Quick tier: foxing peeks inside the archive and detects ROM files, routing to the gaming domain. Balanced tier: the LLM writes real Dublin Core — subject="Virtua Cop; first-person shooter; polygonal graphics; light gun; police officer; shooting; powerups", type=InteractiveResource. These are the actual xattrs from the overnight enrichment run on /vol/nfs_final/roms/model2/vcop.zip. Deep tier: full description generated and the file is re-embedded — search quality improves 11–15%. Taxonomy routing: gaming domain maps to dc:type=InteractiveResource. Zero hardcoded rules — all classification flows from the filetypes registry at runtime. Swap vcop.zip for a DICOM scan or NetCDF climate model — the pipeline is the same.

notes: This expanded table includes the tools discussed today at NZRS plus IBM Spectrum Scale, which is the elephant in the room for enterprise research storage. Spectrum Scale is GPFS — the parallel filesystem that runs at most national labs and large HPC centres. It's exabyte-proven, it has AFM for async replication between clusters, and IBM bolted Fusion CAS on top for AI search at 100-billion-vector scale. The problem: it requires three products (Scale, Fusion, Discovery), TiB-based licensing, and a dedicated GPU stack for the AI layer. foxing is one binary. Globus is the WAN transfer layer that Claire Rye and Anthony Shaw presented — GridFTP with parallel streams, checksum verification, third-party transfers between institutional endpoints. foxing doesn't do GridFTP. What foxing does is take custody once data lands at your local endpoint — within 2ms, it replicates, classifies, writes Dublin Core xattrs, and publishes a CloudEvents notification. WEKA is the distributed parallel NVMe filesystem that REANNZ provides for HPC workloads. foxing runs on a WekaFS mount as a standard POSIX source. BPF probes capture VFS writes, no WekaFS-specific code. CERN's CVMFS remains the real prior art for content-addressed distribution — SHA-1 Merkle since 2008. But it's read-only software distribution, not continuous file replication with AI enrichment. The key differentiator: foxing is the only tool that writes machine-readable Dublin Core metadata to the filesystem as a side effect of copying, and the only one that publishes real-time CloudEvents when files are replicated.

notes: This is the layer cake. When foxing starts, probe_capabilities walks the entire storage stack beneath each target path. It detects the filesystem type, checks for reflink support, probes O_DIRECT alignment, walks the device-mapper stack looking for LUKS encryption layers, VDO dedup, LVM thin provisioning, Stratis pools, and dm-integrity tags. Each layer changes the optimal I/O strategy. LUKS2 uses 4096-byte sectors — DIO alignment gets clamped. VDO dedup means you don't want to pre-allocate sparse files. Stratis gives you D-Bus pool monitoring and zero-cost reflink snapshots. dm-cache means your SSD is fronting a HDD — queue depth should target the SSD, not the HDD. The 9-variant StorageClassification feeds into the adaptive BBR tuner so each target gets optimal queue depth and batch sizing regardless of what's underneath. This is why the RAID1 analogy works — you can have an NVMe target on raw XFS and an HDD target on LUKS+LVM+VDO and foxing adapts to each independently.

notes: This is an opinionated slide and I'll own that. XFS is the default filesystem on RHEL and has been since RHEL 7 in 2014. It's the most tested, most scaled, and most conservatively engineered filesystem on Linux. The key design principle is that XFS is a filesystem and only a filesystem. It doesn't try to be a volume manager like btrfs, or a RAID controller like ZFS. Those are separate concerns with separate failure modes and separate recovery tools. When your btrfs RAID1 array has a metadata corruption, you're debugging a filesystem, a volume manager, and a RAID controller all fused into one codebase with one recovery tool. When your XFS-on-LVM-on-LUKS stack has a problem, you can isolate which layer failed and fix it independently. xfs_repair works. dm-crypt is transparent. LVM metadata is separate. That's the Unix philosophy applied to storage. foxing started on XFS — the original proof of concept was an eBPF watcher that mirrored XFS writes to a second mount. I was working on Open vSwitch and OpenStack at the time, messing around with eBPF for network packet inspection, and realised the same tracing infrastructure could capture filesystem events. The first version was about 200 lines of C that attached to xfs_file_write_iter and copied files to a target directory. Everything since then — the CAKE dispatcher, the Merkle trees, the AI pipeline — grew from that XFS mirror.

notes: Two ways to get foxing. For Fedora and RHEL, COPR packages are the easiest — dnf copr enable, dnf install, done. foxingd is the superset binary — it includes fxcp via symlink dispatch, so installing foxingd gives you both. Container images on quay.io come in two flavours: Fedora Hummingbird is distroless — the binary is literally the only thing in the image, 72 MB for foxingd. UBI 10 Minimal participates in the RHEL ecosystem with signed packages and CVE tracking. For Debian and Ubuntu, building from source is genuinely the best path — the RPM packaging and systemd integration are RHEL-focused and the .deb packages are provided as a courtesy but aren't a primary target. I want to acknowledge Red Hat here. Their policy on personal open source projects is why this exists at the quality level it does. The code is mine, written on my own time, but the testing infrastructure — the IPA domain, the Kerberos realm, the NFS exports, the Stratis pools — that's what turns a hobby project into something with 1117 unit tests and 19 adversarial scenarios. Not every employer lets you use enterprise infrastructure for personal projects. Red Hat does, and it matters.

notes: If someone asks "what was the hardest part" — it wasn't the architecture. The CQRS event model, the CAKE dispatcher, the BBR adaptive tuner — those have been solid since they were designed. The hard part was stabilising the data processing pipeline for edge cases. The 45× NFS slowdown was the most embarrassing — io_uring registered buffers were 4KB, generating 2,560 NFS WRITE RPCs per 10MB file while cp generated 10. One conditional fixed it. The 375 corrupted files were the most dangerous — the post-copy verification was comparing the source hash against itself, so corrupted targets passed verification silently. Self-confirming verification is a pattern that can hide in any replication system. The BPF write aggregator swallowing single-write files was the most subtle — it only manifested with cp and dd, not with Python's write+fsync pattern that the test suite used. Adding the __fput probe to flush on file handle close fixed it. Everything since stabilising those copy-path edge cases has been cream — the AI enrichment pipeline, the taxonomy system, NFS transport security, RDMA. The architecture carries them without strain. That's the validation: if the foundation is right, features compose.

notes: Last slide. The visual identity is a work in progress and I'm being deliberate about it. The name 'foxing' comes from archival science — it's the brownish spots on old mirrors where the silver has degraded. A mirror written in Rust. The concept art you see in the repo explores a yin-yang duality — raw data on one side, enriched metadata on the other. One fox is line art, the other is full colour with nature and technology elements. I've been in conversation with NZ artists about incorporating tukutuku and kōwhaiwhai design elements into the project identity. That requires proper cultural consultation — not downloading a pattern from the internet and slapping it on a logo. The Toi Iho pathway — the Māori arts authenticity mark — is something I'm exploring as a governance mechanism. If foxing uses cultural design elements, there should be an accountable relationship behind them, not just aesthetic borrowing. The retro pixel art sprites in this presentation are placeholder fun. The real visual identity is being developed with the same care as the code — one step at a time, with respect for the people and knowledge systems it draws from. If anyone here has connections to NZ designers working at the intersection of technology and indigenous design, I'd welcome an introduction.

notes: Reference list for anyone who wants to follow the threads. The Brady PRIME framework paper is the one that connects the AI trust question to the sovereignty framing. Sperber's epistemic vigilance is the evolutionary account of why people need to evaluate the source of claims, which is directly relevant to AI-generated metadata.