This file provides code-level evidence and implementation details for the SNIF (Safer Native Implemented Functions) architecture.
Any crash in a NIF normally kills the entire BEAM VM… WebAssembly sandboxing provides genuine crash isolation.
- How this is implemented
-
We use
wasmexto load Zig-compiled WASM modules. Thedemo/folder contains tests that trigger null-pointer dereferences and overflows in the Zig guest; the host Elixir process receives a standard error tuple instead of a segmentation fault.
SNIF deliberately stops at NIF-parity + crash-isolation. The goal is to adapt and
perfect something that already exists — the BEAM NIF — for the people who already use
NIFs: a safer, like-for-like drop-in for native compute/buffer functions (see the README
Scope section), not a new interface paradigm. Capabilities that go beyond what a
NIF offers — graduated/tunable integration, capability negotiation, transaction-gating,
permissions that depend on an integration "mode" — are out of SNIF scope by design. If
an idea is good but takes us past the NIF goal, it belongs to the cleave and groove
layers below, and is considered there, not bolted onto SNIF.
Three distinct layers; SNIF is the most conservative of them:
-
SNIF — perfecting an existing interface. A SNIF realizes a residue-clean cleave instance at one boundary (BEAM host ↔ native guest): a guest trap becomes
{:error, reason}, the BEAM survives, and the error residue carries no recoverable guest value (theSnifVerdictdeniability proofs). It is an instance of a cleave, not "the cleave" — the earlier phrasing "SNIFs provide the Physical Cleave Surface" overstated this and is corrected here. -
Cleave — the new implementation of graduated integration. A transmutable surface you can dial from near-raw FFI-ABI, through the SNIF sandbox (the safe middle detent), to a tight Groove-defined internal-api; closeable to a standalone secure surface. SNIF sits at the middle; the rest of the dial (transaction-gating, mode-indexed permissions, the well-founded "staircase" teardown) is cleave scope, not SNIF scope.
-
Groove — something new, to move beyond current interface design. The protocol for how services talk: capability discovery + typed capability negotiation, soft (pub/sub) ↔ hard (in-process) integration modes. SNIF merely consumes Groove as a communication counterpart, and only at the v0.2 roadmap level — snifs ships no Groove code today.
The safer-NIF pattern is realizable across guest languages — Zig today, Rust→wasm32 wired, Ada/SPARK and estate wasm-native languages (typed-wasm/ephapax/affinescript) prospective. This is breadth of guest language within the NIF goal, not an expansion of SNIF’s purpose. SNIF is not a "universal interface hub"; that "beyond current interface design" ambition lives in groove/cleave, not here.
| Path | Proves |
|---|---|
|
Implementation of trapped failure modes (8 exports, ABI-modelled). |
|
Integration tests verifying BEAM survival across every crash mode. |
|
SEC-1 operational crash-isolation, proven-modulo-explicit-TCB. |
|
Residue-clean (deniability) + non-forgery at the boundary. |
|
Model↔binary ABI drift gate (interface-level). |
| Technology / Pattern | Used here | Also used in |
|---|---|---|
Idris2 ABI / capability proofs |
|
bag-of-actions (capability |
Zig → wasm32-freestanding ( |
The SNIF kernel ( |
bag-of-actions ( |
|
SEC-1 crash-isolation is mechanised in |
echo-types (loss-with-residue, constructive Agda) |
|
Caution
|
SEC-1 is proven modulo an explicit TCB. The crash-isolation theorem holds
relative to the |
|
Caution
|
ABI conformance gates 15 of ~20 Zig export sites. |
|
Caution
|
The Rust→wasm32 guest path is wired but dual-sourced. |