Architecture

Every OS gets its own thin frontend, and they all reach the engine the same way: by naming an intent and letting the machine decide what that costs.

Two words carry this, so they are worth stating plainly. An intent is what a call is meant to achieve, independent of the name an operating system gives it — which is why flush, fsync and release are one intent and not three. The substrate is what carries its steps out: the deciding thread, the database readers and writer, and the network and file pools.

The alphabet is what the engine does, not what one kernel interface calls it: flush, fsync and release are one intent because they are one operation, and unlink and rmdir likewise. A frontend maps its platform’s callbacks onto these and formats the replies; it carries no engine logic of its own.

That matters for more than tidiness. wusel-fsm depends on nothing — not on the engine, not on a database, not on an HTTP client, not on a FUSE binding — so "the deciding thread performs no I/O" is enforced by the compiler rather than by review, and a second frontend is a port rather than a rewrite. The reasoning is in Portability; the scripts themselves are in the operation scripts.

wusel-core keeps what was never per-request: the WebDAV client, the SQLite state, pins, the background syncer, and the conflict and reconcile logic the substrate calls. The macOS and Windows frontends remain separate, additive projects with their own OS glue (Swift + a C ABI on macOS; windows-rs on Windows) — neither changes the engine, which is the whole point of the split.

FUSE callbacks are synchronous/blocking, network I/O is async (tokio). The fuser session loop processes one request at a time on a single thread, so any call that blocks it — a PROPFIND, a content fetch — stalls every other operation queued behind it (tab-completion, stat). Two rules keep that from happening:

Only the first listing of a directory is synchronous, because there is nothing cached to serve yet.

Simple users should not have to babysit a terminal. The daemon runs as a systemd user service — not system-wide: it lives in the user’s session, reads credentials from ~/.config, needs no root, and its FUSE mount is naturally bound to login. Logs go to the journal (journalctl --user -u wusel); tracing writes to stderr, which systemd captures. The daemon owns the mountpoint (creates it if missing) and unmounts cleanly on SIGTERM, so the unit stays minimal.

Multiple accounts. Many users have more than one Nextcloud — personal plus work, or one per client. Accounts are optional named profiles: the implicit default account uses the base dirs directly (a single-account user sees no profile machinery at all), while each named account is opt-in and fully isolated under an accounts/<name>/ subdirectory:

The CLI carries an optional --account <name> (default default, so the single-account case is unchanged); wusel accounts lists them and wusel account remove <name> deletes a named profile (credentials, state, cache — the server is untouched). Named accounts map directly onto a templated systemd unit so N instances run side by side:

The absent sandboxing is deliberate. The unit carries none of the systemd hardening directives one would normally reach for — ProtectSystem, LockPersonality, RestrictRealtime, ProtectKernelModules and friends — because every one of them implies NoNewPrivileges=yes, and an unprivileged FUSE mount goes through the setuid fusermount3 helper. Under NoNewPrivileges the setuid bit is ignored and the mount dies with fusermount3: Operation not permitted. So the hardening is not missing by oversight; it is incompatible with the one thing the service exists to do. What limits the blast radius instead is that this is a user service holding a revocable app password, not a root daemon. Both shipped unit files carry this rationale as a comment, so nobody "fixes" it later.

Two accounts must never share or nest a mountpoint (Linux would over-mount and hide the first), so mount refuses to start where its target equals, contains, or sits inside another active mount (wusel_core::mount::find_conflict against /proc/self/mountinfo). Mounting the same server + user under two accounts is allowed but warned: two read-write mounts of one account edit the same server files through two independent caches and write buffers, so they can conflict with each other exactly as two different machines would.

Flow for a plain user: install the package (pulls fuse3), wusel login --account work <url> (confirm in the browser), then wusel --account work service enable — a convenience subcommand that writes/enables the unit so no one touches systemctl. The account then mounts at every login. The service is enabled only after a successful login, so it never crash-loops without credentials. (The template unit also serves the single default account, as wusel@default.)