32°N Platform Apps

Platform · Apps

Like a mobile OS, ported to marine.

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

Three categories, one trust model.

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.

Ships with the OS

Native

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.

  • Chartplotter
  • Weather routing
  • Anchor watch
  • Logbook
  • Marine Security
  • Cockpit
  • Passage planner
Registered permissions

Third-party

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.

  • Community-built tide tools
  • Custom instrument dashboards
  • Voyage tracking integrations
AI + platform access

Agents

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.

  • Navigator passage agent
  • Watchman anomaly agent
  • Custom alert agents

The app lifecycle

From package to running on the boat.

Five steps, with a scanner sitting between submission and installation. No third-party code runs on the platform without passing through all five.

01

Package

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.

02

Sign

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.

03

Submit

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.

04

Install

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.

05

Update

Updates go through the same pipeline as installs. A capability change in an update resurfaces the approval prompt. No silent capability expansion.

Capability model

What apps can ask for, and how much friction each creates.

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

Undeclared access is impossible, not just discouraged.

Enforcement at the cap-token layer.

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.

Updates get the same treatment.

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

Capability analysis on every submission.

The scanner runs two analyses on every submitted app: static vulnerability scanning and capability analysis. Both must pass before the app is listed.

Static vulnerability analysis

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.

Capability analysis

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.

Continuous re-scanning

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 mss audit CLI

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

Apps sit on top of the OS, talking to the bus.

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.

See the apps, or read about security.

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.