Edge, IoT and existing infrastructure

Two questions come up immediately for anyone with an existing deployment: can this run at the edge, and can it coexist with the architecture I already have. This page answers both, including where the answer is no.

Where sovm sits on the edge spectrum

“IoT” spans six orders of magnitude of capability, so the useful thing to state is the floor.

A sovm node must run OpenMLS, encrypt and decrypt Parquet, hash with BLAKE3, hold durable group state across restarts, and protect key material at rest. That places it firmly at Linux-class hardware and up — gateways, industrial PCs, single-board computers, phones, NAS boxes, servers.

It is not a microcontroller protocol. A sensor node with tens of kilobytes of RAM will not participate directly, and pretending otherwise would be dishonest. The realistic topology is the conventional one: constrained devices speak whatever protocol suits them to a local gateway, and the gateway is the sovm node. That is where data first becomes an encrypted object, and it is the first point at which the guarantees on this site apply. Anything upstream of the gateway is outside the trust boundary and must be treated as such.

One refinement now that the family is two layers: that floor is for the full family. A node participating only in SSP/1 — syncing configuration and small mutable state, with no object plane — needs Ed25519 signing, CBOR, and protected key storage, but no MLS and no Parquet. That admits noticeably smaller devices to the mutable-state mesh than the object plane can accept; the gateway pattern still applies below that.

Why the design suits intermittently connected nodes

These are properties of the specification rather than aspirations, and several were decided with edge constraints explicitly in mind.

Production does not require connectivity. An authorized node collects and forms objects while offline as normal operation, and publishes when it reconnects. There is no master node and no coordinator in the write path. Ordinary data writes require no agreement with any peer, ever — objects are added to a set, and addition is commutative and idempotent.

Publication survives long absences. Because each object carries its own key, kept under local protection until publication, a node that was offline across a key rotation does not re-encrypt anything. It obtains the current key generation and seals a small access record. A node cannot be stranded holding data encrypted to a key nobody uses any more.

Reaching a peer is the transport’s problem, not the deployment’s. sovm does not ask for a flat network, a VPN, or pre-arranged routes. Its preferred live substrate, iroh, addresses endpoints by cryptographic public key over QUIC: it tries the fastest direct path, hole-punches through NATs where it can, and falls back to an encrypted relay when no direct path exists. A gateway behind carrier-grade NAT on a mobile link is an ordinary participant rather than a special case, and the relay it may fall back to carries ciphertext it cannot read.

Transfer is built for bad links. Objects are content-addressed, and the identifier is the transfer layer’s own hash. Verified streaming, download resumption, and verified range transfer come directly from that, so an interrupted sync resumes rather than restarts, and a partial transfer is verifiable rather than suspect.

Object sizing is an edge decision. The specification’s target of 16-64 MiB per encrypted object is described as “edge-oriented” and deliberately leans smaller than generic warehouse guidance, balancing refetch cost over metered links, memory pressure, and range-resume behaviour against scan efficiency.

Placement is tiered independently of access. A node’s storage footprint is set by placement policy, not by what it is allowed to read. A constrained node can hold a recent hot window while an archive holds full history — and the archive can hold it blind.

Append-only is the native case. Sensor and telemetry data is the archetypal APPEND workload, which is the path the design optimizes hardest and the one that needs no conflict resolution at all.

That telemetry is also the substrate most private AI work depends on, and the combination is the point: data can stay on the site, device, or jurisdiction that produced it and still be trainable on. See AI and training data.

Near-real-time flows

The design is offline-first, but the complementary case — nodes that are online together and want data moving in seconds rather than on the next sync — is served by the same machinery, in tiers, without a separate streaming system.

Live mutable state moves in round-trip time. SSP/1 registers a realtime mode: over a held live connection, a node pushes change events as they are produced, using the same message body and the same delivery rules as batch sync, with the periodic batch cycle continuing underneath as the correctness backstop. Current values, device status, catalog metadata — the “what is true right now” tier — need nothing beyond this.

Append streams move at flush cadence. The object plane’s 16-64 MiB sizing is a starting policy, not a protocol invariant, so a hot table can flush small objects on a time trigger. A freshly published object’s manifest and access record are themselves group control messages that can travel over the same live connection, and content addressing makes the fetch a single verified round trip. Freshness for an append stream is therefore the flush interval plus one round trip — seconds, not sync cycles — and compaction later converts the accumulated small objects back into scan-efficient ones, the same trade log-structured storage and streaming lakehouse ingestion make.

Two honest floors. Per-object costs — a key, a signed manifest, an access record, padding — are fixed per object, so pushing flush cadence down multiplies overhead and compaction work; sub-second freshness for bulk data is not a goal the object plane serves. And publication cadence is timing metadata: padding hides sizes, not rhythm, so a node that publishes on every event tells a path observer when it is active. Where that matters, flush on a fixed cadence — the same trade realtime mode documents for the mutable tier.

Crossing infrastructure you do not control

This is the part that generalizes beyond edge deployments, and it rests on a single structural property: holding the bytes conveys no ability to read them.

Because storage membership and decryption membership are formally distinct sets, neither inferred from the other, infrastructure can carry sovm data without being brought inside the trust boundary. Concretely, that means the following can all sit in the path without being trusted:

• an existing object store or storage appliance;
• a cloud bucket, in a region or account you do not administer;
• an existing message bus, queue, or relay;
• a DMZ hop, jump host, or corporate proxy;
• a regional aggregator or edge cache;
• rented archival capacity.

Three properties make that safe rather than merely possible.

The relay cannot read plaintext. Store-and-forward infrastructure is required not to have access to it, and the outer transport wrapper carries only what routing needs — an opaque token and a message kind. Table names, schema names, and domain names are protected metadata. A message bus can carry sovm traffic while learning nothing about what the traffic is about.

Integrity does not depend on the path. An object’s identity is the hash of its encrypted bytes, so a recipient verifies what it received regardless of how many untrusted hops it took. You do not have to trust the pipeline to trust the payload, which is what makes an untrusted intermediary a routing detail rather than a security decision.

Compromise of the infrastructure is bounded. A hostile relay is in the threat model. It can withhold messages or attempt to misorder membership operations — both availability attacks, and the second is detectable, because sequenced operations are acknowledged with signed hash-chained receipts that clients retain and cross-check. What it cannot do is read data or forge membership.

The one place data leaves the encrypted domain

Integrating with an existing analytics stack eventually means handing it readable data, and this is where most encryption postures quietly fail — a convenience export becomes a permanent unencrypted copy nobody is tracking.

sovm handles it by making the boundary explicit and singular rather than emergent. The interoperability projection to a standard lakehouse format is derived and never the authoritative history, so the encrypted objects remain the source of truth. And if the projection target is not trusted user-controlled storage, producing it is an explicit export operation that must not happen as transparent background replication.

That is the whole posture in one sentence: data leaves the encrypted domain by a decision someone made and can audit, not by a default someone forgot. A pipeline built this way has exactly one place to review, and it is named.

Honest limits

Stated plainly, because an integration decision made on optimism is expensive to reverse.

Limit	What it means for you
Not for microcontrollers	Constrained devices need a gateway that is the actual sovm node; the trust boundary starts there, not at the sensor
Every node needs key custody	Each participant must protect key material at rest, ideally in hardware. Nodes that cannot are storage-only at best
Performance on edge silicon is unmeasured	Encrypted Parquet overhead and AES-GCM hardware acceleration on minimum-spec ARM are gated, not benchmarked
Group state is demanding	MLS state must survive process death, long offline periods and software upgrade — a gated property, not a demonstrated one
Joins need connectivity	Data writes need no coordination, but adding or removing a node is a sequenced operation and requires reaching the sequencer
Fleet scale is unproven	The design targets a fleet of machines, not thousands of nodes. See below

Scale is an open question, not a solved one

The specification is explicit that the number of cryptographic domains should stay small, and that membership latency is acceptable because membership changes are rare and security-sensitive. Both assumptions hold for a fleet of tens of machines.

Neither has been validated for a fleet of thousands of intermittently-connected nodes, where membership churn stops being rare and becomes the dominant workload. MLS groups have practical size limits, every membership change is serialized through one sequencer per group, and nothing in SOP/1 currently addresses sharding a mesh across many groups or amortizing high-churn enrollment.

If your deployment looks like that, treat large-fleet operation as unspecified work rather than a supported configuration. It is a plausible extension — the data plane genuinely does not care how many producers there are, since object addition needs no coordination — but the membership plane would need design work that has not been done.