Spacewave, a workspace that runs in the tab and replaces ten dependencies with forks

The whole app runs in the tab, and there is no server to install

The pitch is that there is nothing to deploy. Open it in a browser and you get a private, encrypted workspace running on your own machine, with no account, no setup, and no server to run, and it syncs peer to peer between your devices and works offline. From source that is two install steps:

bun install
uv sync --frozen --all-groups

Two package managers, because the repository is a polyglot monorepo: Bun for the TypeScript and React side, uv for the Python resource package. Three ways then start it. The desktop build runs as native processes:

bun run start:desktop

The two web builds are the interesting pair, because they differ in how Go reaches the browser, and that is covered next.

`start:web` and `start:web:wasm` are two different Go compilers

The same application, two toolchains:

bun run start:web

runs the web app with GoScript browser Go plugins, and:

bun run start:web:wasm

runs it with standard Go compiled to WebAssembly. GoScript is the project's own component for compiling Go to TypeScript modules that stay readable, so a Go package becomes a TypeScript module rather than an opaque WebAssembly blob, and the intent is to share algorithms, data structures, and runtime code without writing a second implementation. It also powers Bldr's Go compiler mode for Spacewave's own web plugins. Choosing between the two is a choice about whether you want inspectable TypeScript output or the standard compiler and its ecosystem. The desktop path is the third option and the only one where Go runs as a native process rather than inside a worker, which is what the architecture section says happens: app logic runs in WebWorkers and SharedWorkers in the browser and as native processes on the desktop, which is the mechanism that brings the Go ecosystem into the browser at all.

Hydra swaps Redis, BadgerDB, S3, and IndexedDB without touching your code

The storage claim is stated as one sentence and it is the strongest thing in the architecture section: an app can allocate a SQL database and store it in Redis, BadgerDB, or IndexedDB without changing a single line of code when switching backends. That is Hydra, the component described as storing data anywhere with peer-to-peer sync. It covers several data structures rather than one, including SQL, key-value, and a graph database, and its backends include BadgerDB, Redis, and S3 on a server and IndexedDB in the browser. The reason the project exists at all is stated in the same breath: traditional web apps put data on servers, the frontend only displays a response, and server-side rendering has increased that dependence. The comparison offered is a video game rendered entirely server-side.

Bifrost picks the transport, and the plugin list includes terminal access

Networking is a separate component, Bifrost, described as network over any transport: cross-platform peer-to-peer communication, encrypted transport protocols with stream multiplexing, and WebRTC plus WebSocket in the browser. At the product level that surfaces as connecting over WebRTC, WebSocket, LAN, or relay, whichever your devices can reach. The plugin ecosystem is where the scope gets broader than a document editor, covering files, databases, notes, and document collaboration, chat and messaging, and terminal access with remote control of your devices, plus SkiffOS for building and managing Linux devices. Encryption is stated as applying to storage, sync, and collaboration, and the paid tier, at eight dollars a month for 100 GB, adds managed cloud storage and relay while the app is described as working without it. The two remaining components are worth naming because they show the scope is not limited to documents. Forge is continuous integration and automation: a distributed job scheduler, pipeline automation, and workflow orchestration. Auth holds password and PEM-based authentication primitives with shared building blocks for provider and session flows, and Identity holds identity records and domain-backed configuration for account and provider workflows.

Ten upstream dependencies resolve to Aperture Robotics forks

The module file is where an evaluator should start, because it changes what you are actually running. `go.mod` declares Go 1.27.0 and then replaces ten upstream projects with versions from an organisational fork: Cloudflare's circl, BadgerDB v4, ristretto v2, go-mysql-server, jsonpath, vitess, go-git v6, Pion's ice and webrtc v4, and logrus. Every replacement is a pseudo-version rather than a tag, and several carry comments naming the branch. So the build is not tracking released BadgerDB or released Pion; it is tracking a fork at a particular commit, several of them on a moving branch. That can be a deliberate response to upstream churn, and it is also the thing to check first when a dependency behaves differently than its documentation says.

Protobuf with six generator manifests, and one script to regenerate

Message encoding is Protobuf, and the tree shows how much machinery that costs here: six separate generator manifest files at the top level, one for the main target and one each for a C++ web plugin, a Python resource, a Python session journey, a Python web plugin, and a Rust web plugin. Changing any `.proto` file means regenerating, and there is one command for it. The Python side carries the cost more visibly. `pyproject.toml` sets mypy to strict, then exempts eighteen generated `*_pb2` modules from a single error code, because the generated stubs annotate map fields as a bare Mapping. Type stub packages are pinned exactly rather than by range, which tells you the generated surface moves fast enough that a range would break type checking on an unrelated day.

Python is pinned to the 3.11 line and starpc to a commit SHA

The resource package, named `spacewave-resource`, requires Python 3.11 and nothing else, written as a range that excludes 3.12. Its single dependency, starpc, is not a version at all but a git URL pinned to a specific commit, and the development group pins the same repository again with a subdirectory fragment for the Python plugin. A comment explains where the formatter comes from: the StarPC generator supplies Ruff for formatting and linting, which is why no Ruff entry appears in the dependency list. The packaging configuration collects six separate package roots under one find rule, each with its own `py.typed` marker, so the type information ships rather than being inferred. If you are on 3.12 or 3.13, this is the constraint that stops you before anything else does.

Three releases in one day, and the JavaScript package is still 0.0.0-dev

The version numbers tell two different stories. The Go releases are v0.57.20, v0.57.21, and v0.57.22, all published on 2026-10-02, which is a patch-number scheme that lets you ship several times a day. The `package.json` says version 0.0.0-dev and is marked private, because the JavaScript side is a monorepo package rather than the released artefact, and the version that matters comes from the Go tags. The branch was last pushed on 2026-10-01 and the default branch is master. The licence is Apache-2.0, and the documentation is split across several files rather than the README alone: a product document, a design document, a changelog with an unusual extension, an agents file, and a Starlark build file alongside the Go sources.

Editorial conclusion

Spacewave suits someone who wants an encrypted shared workspace that keeps working when the network does not, and who is willing to run a Go toolchain to build it. The storage abstraction is the part with real value: the same app code runs against Redis, BadgerDB, S3, or IndexedDB. It is a poor fit if you want an unmodified upstream dependency tree, because ten modules resolve to organizational forks rather than released versions, or if you need Python outside the 3.11 line that the resource package pins. Before you build, read the replace block in go.mod and the branch tags, since both tell you what happens when an upstream project moves.

Frequently asked questions

Official sources

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