Extensions
32°N is designed to be extended. The same platform contracts the built-in apps use — identity, the data bus, the AI gateway, the local store, sync — are available to any extension. No separate SDK, no partner tier, no different terms.
If you want to build a specialised app for your boat, contribute a new integration to the community, or build a commercial product on top of the platform, this page explains how the model works.
01 · What an extension is
An extension is a self-contained package — an app, an integration, a data adapter — that runs inside the hub OS. It consumes bus events, may publish its own, and ships through the app store.
Writing an extension means implementing the platform contracts, not inventing your own data pipeline. You subscribe to the bus for instrument readings, use the platform's identity layer for authentication, write to the shared data store through the platform data layer. The platform provides all of that.
The built-in apps — chartplotter, anchor watch, weather router, logbook — are all extensions in the same sense. There is no first-party versus third-party split in the architecture. The difference is authorship, not privileges.
Every extension runs in a sandbox. It declares its capabilities upfront — which bus topics it reads, which it writes, whether it needs cloud access, whether it needs storage. The owner approves those capabilities at install time. An extension cannot acquire permissions it did not declare.
Extensions are signed. The signing key is tied to the publisher identity in the registry. If an update arrives and the signature does not match the registered publisher, the hub will not install it.
Source for every AGPL-licensed extension is verifiable. The registry publishes the source hash alongside the binary.
02 · Installing an extension
The hub runs an on-boat app store. Extensions are discovered, installed, updated, and removed through that interface — or through the command line if you prefer. The owner is always in the loop.
The app store shows extensions from the 32°N registry — first-party and community-built. Each listing shows the publisher, the licence, the declared capabilities, the source hash, and the install count. Nothing in the registry is proprietary-licence only.
Before anything installs, you see the full capability list
the extension declared. Read access to battery state.
Write access to the route.waypoints bus topic.
Read-only access to shared storage. You approve the list,
or you don't install. There is no "approve all" shortcut
that silently grants everything.
The hub checks the signature against the registry, verifies the source hash for AGPL packages, and runs the extension inside its sandbox with the approved capabilities. No network calls outside the declared scope. No filesystem access outside the sandbox boundary.
When an update arrives, the capability diff is shown. If the update adds new capabilities, you approve them explicitly before the update installs. An extension cannot silently expand its permissions through an update.
03 · Capabilities model
Capabilities are declared in the extension manifest and approved by the boat owner at install time. The sandbox enforces them. An extension that tries to access something outside its declared capabilities gets a permission error, not silent data.
Subscribe to specific typed bus topics — wind, battery state, GPS, AIS, depth, and so on. Declared per-topic.
Publish events to specific bus topics. Declared separately from read access. Write to a different topic than you read.
Read-only access to the shared data store — routes, logbook entries, vessel profile. No writes to shared state without the write capability.
Write access to specific shared data store collections. Scoped — an extension that writes waypoints cannot write logbook entries unless it declared that too.
Access to the platform AI gateway. Scoped to the extension's own calls — the extension sees its own AI usage, not the whole vessel's.
Query the cloud weather service for forecasts, GRIB data, and isochrones. Requires the cloud layer to be configured.
Outbound HTTPS requests to declared domains. No wildcard network access. Each domain must be listed in the manifest.
Isolated read/write access to the extension's own storage partition. Not accessible to any other extension or to the platform directly.
Send notifications to the cockpit display and the owner's connected devices. Scoped by urgency level — informational, alert, or critical.
04 · Where to start
The developer guide has everything you need: the SDK, schema documentation, the extension manifest format, local development tooling, and how to submit to the registry. Links go live as they are ready — the repo is the source of truth.
The developer guide covers the SDK, local dev setup, and how to get an extension into the registry. The platform overview puts extensions in context of the full five-layer stack.