Spacedrive: content identity, script adapters, and a 2.0 line that is still alpha

The manifest says FSL-1.1-ALv2 and the README says open source

Those two statements are not the same, and the gap is the first thing to resolve before you build on this. The workspace manifest sets license = "FSL-1.1-ALv2", the repository's license field is reported as NOASSERTION, and the README describes Spacedrive as an open source cross-platform file explorer and a community of contributors. FSL-1.1-ALv2 is a source available license with a commercial use condition attached, so the permissive reading implied by the word open source is not what the manifest declares.

The release line adds a second uncertainty. The tags are v2.0.0-alpha.2 dated 2026-02-07, v2.0.0-alpha.1 dated 2025-12-26, and 0.4.3 dated 2025-03-24, so the newest tag without an alpha suffix is from March 2025 while two 2.0 alphas sit above it. The repository is not archived and was last pushed on 2026-07-29, so work continues, but a reader who installs a stable looking tag gets code from a different generation than a reader who builds the default branch.

npm and yarn are turned away at preinstall

The JavaScript side of this project is a bun workspace, and it enforces that at install time. The preinstall script is npx only-allow bun, the packageManager field pins [email protected], and the engines block requires bun ">=1.3.0" alongside a node range of ">=18.18 <19 || >=20.1". The workspace globs are packages/*, apps/*, scripts, and .github/actions/*.

The consequence is that npm, yarn, and pnpm installs do not degrade gracefully, they stop at preinstall with an error, and there is no documented switch to allow them. The node range is just as narrow in a quieter way: Node 19 is excluded outright, so a machine on 19 satisfies nothing. For the JavaScript dependencies this means one package manager, one lockfile in bun.lockb, and a turbo based script runner, and any CI image that provisions Node by convention will need to be rewritten around bun before the first install succeeds.

`cargo build` skips the desktop app on purpose

The Rust workspace separates its member list from its default member list, and the difference is commented in the manifest. The full member list includes apps/server, apps/cli, apps/tauri/sd-tauri-core, apps/tauri/src-tauri, core, core/benchmarks, crates/*, xtask, and the mobile core. The default member list drops both Tauri entries, next to a comment explaining that Tauri is excluded from default builds because it requires the frontend to be built first, and pointing at the command to use instead:

cd apps/tauri && bun run tauri:dev

The consequence is that a plain cargo build in a fresh clone produces the daemon, the server, the CLI, and the core crates, and not a desktop application. A contributor who only has a Rust toolchain cannot build the desktop target at all, because the frontend has to be built first and the frontend needs bun. The ordering dependency is stated once, in a comment, and the failure a newcomer meets is a missing artifact rather than a message explaining the sequence.

The dev loop is a daemon plus a separate desktop process

The justfile names the default workflow directly: the daemon and the desktop app, run together. Setup is two commands:

bun install
cargo xtask setup

The daemon is compiled with feature flags that pull in media handling and started as its own binary:

cargo run --features ffmpeg,heif --bin sd-daemon

The desktop app is a different process, launched from its own directory with bun run tauri:dev. There is a headless alternative that skips the desktop app entirely:

cargo run --bin sd-server

The consequence is that the desktop app is a client of the daemon, not a self contained program, and every UI problem has a second suspect on the other side of the process boundary. The feature flags are part of the documented dev command rather than a separate build, so ffmpeg and heif are compiled into the daemon you develop against and are not something you can add at runtime. Mobile has its own four recipes, including dedicated iOS and Android targets, each of which changes directory and calls a different bun script.

The UI primitives are a sibling clone, not a workspace member

The spaceui-link recipe is the clearest statement of how the front end is assembled. It first checks for a directory at ../spaceui and, if it is missing, prints an error and stops:

git clone https://github.com/spacedriveapp/spaceui ../spaceui

If the directory exists, it moves into it, runs bun install, then builds and links five packages one at a time, filtered as '@spacedrive/primitives', '@spacedrive/ai', '@spacedrive/forms', '@spacedrive/explorer', and '@spacedrive/tokens', before linking the @spa alias back.

The consequence is that a clone of this repository is not the whole user interface, and that the layout is a hardcoded sibling path rather than a configurable one. A CI system or a monorepo that keeps checkouts elsewhere has to arrange for spaceui to sit exactly one level above spacedrive, and the failure mode is the script's own message rather than a dependency error. Five separate build and link passes is also what the script asks for, so a partial link leaves you with a mixture of local and published packages.

Content identity and SdPath are what make a file portable

The virtual distributed filesystem makes files and folders first class objects with rich metadata that is independent of where they physically sit, and every file gets a universal address called an SdPath that works across devices. Identity is content based: every file gets a BLAKE3 content hash, so the same file on two devices produces the same hash, and large files are handled with adaptive hashing using strategic sampling rather than a full read. That identity is what enables deduplication, redundancy tracking, and content based operations.

The sync story follows from that. Devices connect directly over Iroh and QUIC, with no servers and no cloud in the middle, and metadata syncs while the files stay where they are. Devices that are disconnected keep their entries in the index and appear as offline rather than disappearing. Cloud storage is indexed as first class volumes alongside local disks, covering S3, Google Drive, Dropbox, OneDrive, Azure, and GCS.

The consequence for your code is that offline is a state you have to handle, and that identity is not a path. Renaming or moving a file does not change its identity, but a partial copy of a large file matches only as well as the sampling allows.

Adapters are a manifest and any script that reads stdin

The archival side is unusually open for a file manager. Spacedrive indexes external sources through script based adapters, so Gmail, Apple Notes, Chrome bookmarks, Obsidian, Slack, GitHub, calendar events, and contacts become searchable repositories sitting alongside your files. The contract is deliberately small: an adapter is a folder containing an adapter.toml manifest plus a sync script in any language, and if that script reads stdin and prints lines, it works.

The shipped set is Gmail, Apple Notes, Chrome Bookmarks, Chrome History, Safari History, Obsidian, OpenCode, Slack, macOS Contacts, macOS Calendar, and GitHub. Two of them read browser and OS data that belongs to another application, which is the point of the design and also its sharpest edge.

The consequence is that adding a source is a scripting job rather than a plugin API, which makes the surface easy to extend and hard to sandbox, because nothing in that contract constrains what the script may do with the data it reads. A user who points an adapter at an inbox is importing untrusted content into the same index as their own notes, which is the case the trust tier system is built for.

Screening only happens when you turn it on

The safety pipeline is described with an explicit condition: when enabled, every record passes through screening before it becomes searchable. Four pieces make that up. Prompt Guard 2 is a local classifier that detects prompt injection in emails, messages, and documents before they enter the index. Trust tiers give authored content such as your notes balanced screening and external content such as an email inbox strict screening. A quarantine system keeps flagged records out of AI agent queries and makes them reviewable in the desktop app. Content fencing attaches trust metadata to search results so an agent can tell authored material from untrusted material.

The consequence is that the claim that no other local data tool screens indexed content before exposing it to AI is scoped to the enabled state, and the default is not the enabled state. An installation that indexes an inbox and leaves screening off hands injected text to Spacebot as ordinary content, with nothing in the search results marking it untrusted. Since the adapters pull in mail, browser history, and Slack, the untrusted category is the normal case for most libraries rather than an edge case, and the quarantine review queue lives in the desktop app rather than the API.

Editorial conclusion

Spacedrive fits someone whose files are already scattered across several clouds and local disks, and who wants one index over them, or someone building an agent workflow that needs a permission layer instead of raw shell access. It does not fit a team that needs a permissively licensed dependency, because the workspace declares FSL-1.1-ALv2 while the README says open source, and it does not fit a team that cannot install bun, since npm and yarn are blocked at preinstall. Before you commit, read FSL-1.1-ALv2 yourself, confirm whether the safety screening is enabled in your deployment, and check that the SpaceUI sibling repository is reachable, because the desktop app cannot be built from this clone alone.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes