Platform · Apps
Native apps ship with the platform and have full access. Third-party apps register permission sets; the owner grants or denies. Every submission runs through a capability analyser before it's allowed on the boat.
What apps are
Every piece of software on the platform — whether I wrote it or someone else did — is an app. The category determines how much trust it gets without asking.
Written by me, shipped with the platform. Full bus read and write, full cross-app access, no permission prompts. The built-in apps — chartplotter, anchor watch, logbook, and so on — are native.
Built by anyone using the public SDK. Registers a set of permissions on install. The owner grants or denies each one. The sandbox enforces every read, write, and cross-app call — a permission you didn't declare is a permission you don't get.
AI agents are a special category of app. They run continuously, subscribe to bus events, call tools, and act on behalf of the owner. Like third-party apps, they declare their capabilities. Unlike UI apps, they execute autonomously.
The app lifecycle
Five steps, with a scanner sitting between submission and installation. No third-party code runs on the platform without passing through all five.
Developer bundles the app — code, assets, manifest. The manifest declares name, version, platform target, and every capability the app requests. Nothing undeclared can be requested at runtime.
The build is signed with the developer's registered key. A tampered package fails the signature check on the hub before it's ever opened. Unsigned packages do not install.
The signed package goes to the scanner. Static vulnerability analysis and capability analysis run against the binary. Does the code call APIs it didn't declare? Open ports? Access cross-app resources without a grant? Mismatch means rejection with a full report.
Owner sees the permission set and approves or denies each capability. High-friction capabilities require explicit per-action approval at runtime as well. The sandbox enforces everything from first launch.
Updates go through the same pipeline as installs. A capability change in an update resurfaces the approval prompt. No silent capability expansion.
Capability model
Every capability an app uses must be declared in its manifest and approved by the owner on install. High-friction capabilities — anything that can affect safety or physical hardware — require per-action approval at runtime as well.
| Capability | Friction | What it means |
|---|---|---|
| bus.read.navigation | Low | Read GPS, speed, heading from the bus. |
| bus.read.electrical | Low | Read battery state, solar input, load. |
| bus.write.routes | Med | Write route waypoints to the chartplotter. |
| bus.write.automation | Med | Trigger automation scenes. |
| bus.write.matter.locks | High | Control physical locks. Per-action approval. |
| cross-app.logbook.write | Med | Write entries to the ship's log. |
| cross-app.docs.read | High | Read vessel documents. Explicit grant only. |
| network.egress.example.com | Med | Call a named external host. Host is declared. |
The sandbox
Every app runs inside a sandbox that enforces its declared capabilities at the
bus, network, and cross-app call layer. An app that tries to read GPS data without
declaring bus.read.navigation doesn't get a permission error — it gets
nothing. The capability-token layer makes undeclared access structurally impossible.
The audit log records everything. Every bus read, every cross-app call, every network request, and every blocked attempt is logged. The log is structured, queryable, and tamper-evident. If something is happening that shouldn't be, the audit log shows it.
An update that adds a new capability is not a silent change. The install flow re-surfaces the new permission and requires owner approval before the updated app runs. No capability creep without explicit owner consent.
The scanner
The scanner runs two analyses on every submitted app: static vulnerability scanning and capability analysis. Both must pass before the app is listed.
The scanner runs the same static analysis tooling used in the 32°N platform itself against third-party submissions. Known CVEs in bundled dependencies, known-dangerous code patterns, supply-chain indicators. An app with a critical unpatched vulnerability doesn't get listed until it's fixed.
The scanner compares what the app's manifest declares against what the compiled binary actually does. Does it call network hosts it didn't declare? Read from app namespaces it has no grant for? Open ports? Make system calls outside the declared capability set? Mismatch is a rejection, not a warning.
Apps already in the registry are re-scanned against new signature packs when they ship. A vulnerability discovered after listing generates a finding against every app that contains the affected component. The app is flagged until an update is submitted.
The scanner also ships as a standalone command-line tool. Security-minded crew, integrators, or owners who want to audit a third-party app before installing it can run the same analysis locally — from a laptop, against the signed package, without installing anything on the hub first.
How it fits
The layered architecture is what makes the trust model work. Apps depend on the platform, not on each other. The platform controls what each app can see.
The apps catalogue covers all 14 apps in the suite with what each one does. The platform security page goes deeper into the identity model, mTLS, the key store, and the audit log.