And this should lead us to: A ZFS file system on macOS that feels like APFS does — no kext, no FUSE, no System Extension approval dance. Apple's own FSKit framework mounts it, because ZFS lives entirely in userland. Concretely, what shipping looks like: 1. zfsd (Swift daemon, root) owns the ZFS stack — libzpool in a process, not a kernel. It listens on /var/run/zfs-fskit.sock, serves real ioctls through upstream's own dispatch table, authorizes every request as the requesting user's credential (the Phase B work), and owns pools across mounts, suspend/resume (Phase C), events, and orderly shutdown. 2. The FSKit extension (the signed app bundle) is the thin VFS face — Apple's fskitd calls into it; it talks to zfsd for everything stateful and does ZPL work (lookups, reads, writes, xattrs, ACLs, ZIL) against a mounted dataset. Finder mounts it, Terminal lses it, Time Machine sees a volume. 3. The CLI surface — stock OpenZFS zpool/zfs/zstream binaries, unchanged, because they already speak zfs_cmd_t ioctls; the socket transport in libzfs_core (lzc_sock.c) is the only seam. zpool import on macOS works like on Linux, but the pool is imported by the daemon, not by a kernel module. 4. Correctness bar — the same upstream semantics: per-user secpolicy, delegation, ENOMEM-retry nvlist protocol, interruptible long ioctls, history logging, scrubs and resilvers running in the daemon with real progress reporting. The ceiling this unlocks (why it's worth it): - No kext = no Apple breaking your build every OS release; no FUSE = Apple-sanctioned mount path, Spotlight, and QuickLook work normally. - ZFS features the Apple stack will never ship (checksums self-heal, snapshots, clones, send/recv, native encryption, RAID-Z) become everyday macOS tools. - The same userspace host becomes the substrate for iSCSI/NFS-on-ZFS, encrypted backup volumes, or a Mac-native ZFS NAS appliance — and the daemon model (every request carries a real uid/gid/groups) is exactly what a multi-user or cloud-attached deployment needs. The verification story that proves it: green C suites → Swift suite → signing and activating the extension on a real Mac → zfs create + mount from a plain user account → fsmock/Finder I/O → reboot persistence → sudo sysctl zfs.kext_version absent and nobody notices. Where it stands today against that: architecture settled and committed, Phase B (socket RPC + upstream dispatch + credentials) at 40/42 with two fixable bugs, then Phase C (suspend/resume) and the signed end-to-end. The distance is real but the path is a straight line — no open research questions left, only engineering.

WOW!? IT WORKED. A real, unmodified OpenSSH client just completed a full SSH-2 key exchange against amigassh — 68k Amiga code, cryptography backed by your Linux box. The signature verified, the client accepted the host key and added it to known_hosts, and sent its own NEWKEYS ready to move into an encrypted session. Connection then reset cleanly — exactly as expected, since v1 deliberately stops right there (no session layer yet). The bug was real and specific: RFC 8731's prose about "reinterpreting" the X25519 output as big-endian is misleading — checked against actual OpenSSH source, it does no byte reversal at all. My Rust crypto backend had an unnecessary reversal step that silently produced a wrong (but plausible-looking) shared secret. One-line fix, rebuilt in 4 seconds, and the handshake went through clean on the first retry.