.mod Capsule Format Specification

NØN-OS does not run “apps” in the legacy sense. Every executable is a capsule — a cryptographically verifiable, zkProof-bound package that can be executed, measured, and proven in the mesh without centralized hosting.

A .mod file is a self-contained binary package with a strict internal structure:

---

Capsule Structure (Binary Layout)

┌────────────────────────────────────────────────────┐
│ Capsule Header                                      │
├────────────────────────────────────────────────────┤
│ Manifest (YAML/TOML/JSON — UTF-8)                   │
├────────────────────────────────────────────────────┤
│ Payload (Binary executable or WASM bytecode)        │
├────────────────────────────────────────────────────┤
│ Proof Section (zk-SNARK/zk-STARK proof blob)        │
├────────────────────────────────────────────────────┤
│ Dependency Map (hash list of required modules)      │
├────────────────────────────────────────────────────┤
│ Runtime Policy (sandbox permissions & limits)       │
└────────────────────────────────────────────────────┘

Field	Type	Description
magic	u32	0x4E4F4E4F (NONO) signature
version	u8	Capsule format version
manifest_len	u32	Bytes in manifest section
payload_len	u64	Bytes in payload section
proof_len	u32	Bytes in proof section
depmap_len	u32	Bytes in dependency map
policy_len	u32	Bytes in runtime policy
capsule_hash	[u8; 32]	SHA3-256 hash of the full capsule for mesh verification

---

Manifest

The manifest describes what the capsule is, who signed it, and how it should run.

Example:

/name = "nonos-ssh-agent"
version = "1.2.0"
author = "[email protected]"
entry = "main.wasm"
license = "AGPL-3.0"
description = "Zero-trust SSH agent over NØN mesh with zk-auth"
build_commit = "a94c3f2"
proof_type = "groth16"

---

Proof Section

Stores a succinct zkProof that binds:

Capsule hash

Author’s public key

Declared runtime policy

Optional PoI attestation if capsule depends on infra-level guarantees (storage, compute quotas)

Proof verified locally with beacon/verify.rs before execution.

Prevents:

• Payload substitution attacks

• Manifest forgery

• Runtime policy tampering

---

Dependency Map

A flat list of SHA3-256 hashes representing required .mod files.

Guarantees that a capsule cannot run without all its verified dependencies being locally available and trusted.

Enables mesh pre-fetching via gossip.

---

Runtime Policy

Example (in YAML):

limits:
  cpu: 500ms
  memory: 32MB
  storage: 5MB
network:
  allow_mesh: true
  allow_clearnet: false
filesystem:
  read_only: ["/usr/share/"]
  write_allowed: ["/tmp/"]

Enforced by the NØN-OS capsule executor.

The violations are logged and optionally broadcast as trust score decrements to peers.

---

Lifecycle

Fetch — Capsule discovered via gossip and pulled over onion mesh.

Verify — Hash check → Manifest parse → zkProof verification → Dependency check.

Prepare — Apply runtime policy, mount sandbox.

Execute — Run payload in isolated environment.

Hash State — Commit post-run state to Beacon ledger.

Broadcast — Send execution receipt + optional PoI proof to mesh.

Reward — If .mod incurs micro-fees, log operator revenue.

---

Security Properties

Self-contained: No runtime fetch of external libraries unless declared in depmap.

Cryptographically bound: Manifest, payload, and policy tied in zkProof.

Mesh-resilient: Capsules can be sideloaded via physical media if mesh is partitioned.

Non-upgradeable by stealth: Every version change = new .mod hash and proof.