0DATA Lab · Paper 016 · July 2026

Sovereign Capsule

Total Offline Resilience — Zero Internet Dependency

Hadda TIKIJJA
0DATA Lab, France

Abstract

Every connected infrastructure depends on an Internet link. That link is a single point of failure: fiber cut, carrier outage, saturation, censorship, DDoS attack. The Sovereign Capsule is a complete resilience architecture in which the 0DATA organism continues to operate — voice, visualization, sealing, storage, communication — with no external connectivity whatsoever. We describe the five layers of this architecture: an offline PWA with Service Worker and IndexedDB, a local NOVA Appliance in a 4U rack with GPU and FreeSWITCH, an offline Holoscope for 3D visualization, SPINA v2 with local HMAC-SHA256 sealing, and an off-grid mesh network over 5 km powered by solar panels. Automatic resynchronization when the network returns is provided by SPINA eIDAS RFC 3161. A concrete case documents an Internet outage at 14:32, the automatic failover to the local NOVA at 14:33, and complete synchronization at 16:10. The Sovereign Capsule demonstrates that digital sovereignty is not a legal abstraction: it is an architectural property, verifiable, obtained by removing dependence on the external network as a condition of operation.

In One Sentence

This paper documents the construction of an autonomous capsule in which all of 0DATA's vital functions — voice, visual, sealing, supervision, communication — are maintained without Internet, verified by a real outage on July 23, 2026.

1. The Problem — Internet Dependency as a Single Point of Failure

Contemporary digital architecture rests on an implicit assumption: the Internet is always available. That assumption is false.

In metropolitan France, ARCEP records several thousand fiber-optic cuts every year — construction accidents, storms, equipment failures. An average outage lasts between 4 and 48 hours. In rural areas, this delay can extend to several days. On a global scale, deliberate disconnections (state censorship, armed conflicts, sanctions) add a layer of systemic risk.

For critical infrastructure — a hospital, an industrial site, a data center, a connected farm — an Internet outage is not an inconvenience. It is a cardiac arrest. Supervision systems go dark. Alerts stop going out. Data is no longer timestamped. Voice is no longer routed. 3D visualization no longer loads. The entire organism enters multi-organ failure.

The root cause is architectural: services are designed to operate with the Internet, never without it. The dependency is not accidental — it is structural. Every DNS request, every API call, every certificate check, every Google Fonts load is a thread that, once severed, paralyzes the whole.

Principle of the Capsule. A sovereign organism is an organism that maintains all of its vital functions in the total absence of external connectivity. Connectivity is an enrichment, not a condition.

This paper documents the construction of such a capsule — architecture, components, protocols, and empirical verification.

2. Offline Architecture — The Autonomous Cell

The Sovereign Capsule rests on a five-layer architecture, organized according to the biological principle of cellular autonomy: each layer can operate in isolation, and the whole forms a coherent organism with no external dependency.

ARCHITECTURE OF THE SOVEREIGN CAPSULE ┌─────────────────────────────────────────────────┐ │ LAYER 5 : OFF-GRID MESH │ │ Local mesh network, 5 km range, solar │ ├─────────────────────────────────────────────────┤ │ LAYER 4 : OFFLINE SPINA │ │ Local HMAC-SHA256 sealing, TPM │ ├─────────────────────────────────────────────────┤ │ LAYER 3 : HOLOSCOPE │ │ Local 3D visualization, offline WebGL │ ├─────────────────────────────────────────────────┤ │ LAYER 2 : KENZA + FREESWITCH │ │ Voice, telephone switchboard, TTS/STT │ ├─────────────────────────────────────────────────┤ │ LAYER 1 : OFFLINE PWA │ │ Service Worker, cache, IndexedDB, local WebRTC│ └─────────────────────────────────────────────────┘
Figure 1: The five layers of the Sovereign Capsule. Each layer operates without the Internet. The stack forms a complete autonomous organism.

2.1 The Local NOVA Appliance

The hardware heart of the capsule is a 4U rack housing:

  • Compute. Intel Core i5-12600H processor (12 cores, 16 threads), 32 GB DDR5.
  • Local inference. Intel Arc A380 GPU (6 GB VRAM) — running language, voice, and analysis models locally.
  • Telephony. FreeSWITCH — a complete telephone switchboard (SIP, call routing, voicemail).
  • Storage. 2 TB NVMe — knowledge base, logs, recordings, telemetry data.
  • Security. TPM 2.0 — hardware cryptographic sealing.

The appliance requires no Internet connection to operate. The local GPU runs the voice transcription (Whisper) and synthesis (FishSpeech) models. FreeSWITCH routes calls locally. The TPM seals data without any external authority. Total power consumption is 85 W in nominal operation — powerable by a 200 W solar panel.

2.2 The Hibernation Principle

Nature offers a model of extreme resilience: hibernation. An organism in hibernation reduces its metabolism to the vital minimum while maintaining the integrity of its tissues. On waking, all functions resume without damage.

The Sovereign Capsule applies this principle to the digital world:

  • Nominal mode. Connected to the Internet. Continuous synchronization, updates, external communication. The organism operates at full capacity.
  • Capsule mode. Internet cut. The organism automatically fails over to its local resources. All vital functions are maintained. Non-essential functions (updates, external synchronization, outbound calls to the outside) are put to sleep.
  • Wake-up mode. Internet restored. The organism automatically resynchronizes the data accumulated during the outage. Retroactive timestamping via SPINA eIDAS. No data is lost.

The failover time between nominal mode and capsule mode is under one second. The transition is painless for the user: Kenza keeps answering, the Holoscope keeps displaying, data keeps being sealed.

3. Offline PWA — The Application Without a Network

The first layer of sovereignty is the user interface. A classic web application stops working as soon as the network drops: the browser shows an error page, data stops loading, the screen goes blank.

The 0DATA PWA (Progressive Web Application) inverts this logic: it is designed to work first offline, and to synchronize afterwards when the network is available.

3.1 Service Worker — The Predictive Cache

The Service Worker is a JavaScript script executed by the browser in the background, independently of the web page. It intercepts all network requests and can answer them from a local cache.

0DATA Service Worker lifecycle: INSTALLATION └─ Pre-cache of all static assets (HTML, CSS, JS, fonts, icons, 3D models) → ~4 MB of local data ACTIVATION └─ Cleanup of obsolete caches → Cache-first strategy for assets INTERCEPTION (fetch) ├─ Request in cache? → Instant response (< 5 ms) ├─ Network available? → Network-first, cache update └─ Network unavailable? → Cache fallback + notification
Figure 2: The 0DATA Service Worker lifecycle. The cache-first strategy guarantees operation with no network latency.

The Service Worker pre-caches all the assets required for the interface to operate: the entire application fits in under 4 MB, downloaded once, run indefinitely with no further request.

3.2 IndexedDB — The Local Database

Dynamic data (organ state, logs, metrics, alerts) is stored in IndexedDB, a relational database built into the browser. Unlike localStorage (limited to 5 MB, synchronous, key-value), IndexedDB offers:

  • Large storage. Up to several gigabytes depending on the browser.
  • Complex queries. Indexes, cursors, transactions.
  • Asynchronous mode. No blocking of the user interface.
  • Persistence. Data survives browser restarts.

Every user action is written to IndexedDB before being sent to the server (local-first strategy). If the network is absent, data stays in a local queue. When the network returns, it is synchronized automatically.

3.3 Local WebRTC — Peer-to-Peer Communication

The WebRTC protocol enables direct browser-to-browser communication without an intermediate server. In the Sovereign Capsule, WebRTC is used for:

  • Audio/video transmission between local stations (internal videoconferencing).
  • Data sharing between devices on the same mesh network.
  • Streaming of the Holoscope from one station to another.

No external TURN/STUN server is required: the local mesh network (Section 5) provides the discovery and routing layer.

4. Offline SPINA — Sealing Without a Network

SPINA (Signature Protocol for Immutable Non-repudiable Artifacts) is 0DATA's cryptographic sealing protocol. Version 1 relied on RFC 3161 timestamping — an external trusted authority (TSA server) had to countersign every fingerprint.

Version 2 introduces offline sealing: no external authority is required any longer to produce a verifiable seal.

4.1 Local HMAC-SHA256

The central mechanism is an HMAC-SHA256 computed locally with a key stored in the appliance's TPM:

Offline sealing function: SEAL(data, tpm_key): 1. timestamp ← system_clock() 2. nonce ← random(256 bits) 3. payload ← data ‖ timestamp ‖ nonce 4. seal ← HMAC-SHA256(tpm_key, payload) 5. return {payload, seal, key_id} VERIFY(payload, seal, key_id): 1. pub_key ← TPM.read_public_key(key_id) 2. seal′ ← HMAC-SHA256(pub_key, payload) 3. return (seal == seal′)
Figure 3: Offline sealing algorithm. The private key never leaves the TPM.

The TPM (Trusted Platform Module) is a hardware cryptographic coprocessor. The HMAC key is generated inside the TPM and never leaves it. Even root access to the operating system does not allow extracting this key. In the event of a physical intrusion attempt, the TPM detects the chassis opening and automatically erases its secrets.

4.2 Chain of Local Seals

Each new seal includes the fingerprint of the previous seal, forming an immutable chain:

Block₁ → [data₁, t₁, HMAC(key, data₁‖t₁‖0x00)] Block₂ → [data₂, t₂, HMAC(key, data₂‖t₂‖seal₁)] Block₃ → [data₃, t₃, HMAC(key, data₃‖t₃‖seal₂)] ...
Chain of seals: each block includes the fingerprint of the previous one.

This structure guarantees that:

  • No block can be inserted retroactively (it would break the chain).
  • No block can be modified (the HMAC would no longer match).
  • The order of the blocks is mathematically verifiable.

4.3 Trusted Clock

Offline sealing relies on the system clock. To guarantee the reliability of this clock in the absence of NTP (Network Time Protocol), the appliance uses:

  • Precision RTC. Real-time clock with a maximum drift of ±2 ppm (±1 second every 5.7 days).
  • Integrated GPS. GNSS module for synchronization on the GPS/Galileo constellations, entirely independent of the Internet.
  • Documented drift. The offset between the RTC clock and GPS time is continuously logged. When the network returns, RFC 3161 timestamping countersigns the chain and corrects any drift.
A seal produced offline is a valid seal. The RFC 3161 countersignature on the network's return is a confirmation, not a condition.

5. Off-Grid Mesh — The Network Without Infrastructure

The fifth layer of the capsule is the most radical: a communication network that depends on no infrastructure — no fiber, no copper, no relay antenna, no satellite.

5.1 Mesh Architecture

The 0DATA mesh network uses LoRa 868 MHz radio modules (European ISM band, license-free) mounted on autonomous nodes:

MESH NETWORK TOPOLOGY [Node A] ──── 3.2 km ──── [Node B] │ │ │ 1.8 km │ 4.1 km │ │ [Node C] ──── 2.5 km ──── [Node D] ──── 0.7 km ──── [Node E] │ │ 5.0 km (maximum range, line of sight) │ [Node F] (solar, autonomous)
Figure 4: Example of mesh topology. Each node relays packets. No central base station.

Each node is contained in an IP67 waterproof enclosure and includes:

  • SX1276 LoRa radio. 5 km range in line of sight, 1–2 km in dense urban areas.
  • 20 W solar panel + 50 Wh LiFePO4 battery. Unlimited autonomy outdoors.
  • ESP32 microcontroller. Management of the routing protocol and the message queue.
  • GPS. Time synchronization and node geolocation.

5.2 Disruption-Tolerant Routing Protocol

The communication protocol is a derivative of Delay-Tolerant Networking (DTN, RFC 4838), adapted to LoRa constraints:

  • Throughput. 0.3 to 37.5 kbps depending on distance and modulation (LoRa SF7–SF12).
  • Useful payload. 51 to 222 bytes per frame.
  • Store-and-forward. Each node stores messages in a queue and retransmits them as soon as a neighbor is within range.
  • Priority. Alert frames (critical anomaly) take priority over telemetry frames.
  • Deduplication. Each message has a unique identifier; nodes ignore duplicates.

Average latency is 200 to 800 ms per hop. For a 6-node network, an alert crosses the mesh in under 5 seconds — comparable to a satellite link.

5.3 Zero Infrastructure

The 0DATA mesh network requires:

  • No telecommunication tower.
  • No access provider.
  • No spectrum license (868 MHz ISM band).
  • No mains power.

Deployed on an isolated site — a farm, a mountain refuge, a rear base — the mesh network provides a fully autonomous communication layer, perpetually powered by the sun. Maintenance is limited to the annual cleaning of the solar panels.

6. Resynchronization — When the Internet Returns

The outage is temporary by nature. The critical moment is the network's return: all the data accumulated offline must be synchronized without loss, without duplication, and with complete traceability.

6.1 Wake-Up Protocol

When the Internet returns, the organism automatically executes the wake-up sequence:

WAKE-UP SEQUENCE (typical duration: 4–8 seconds) 1. DETECTION (immediate) └─ Ping to 1.1.1.1 (Cloudflare) or 8.8.8.8 → Response received → start of the sequence 2. DATA RESYNCHRONIZATION (2–5 seconds) └─ IndexedDB → central server └─ Local logs → PostgreSQL database └─ Metrics → time-series database └─ Strategy: last-write-wins with TPM timestamp 3. EIDAS SEALING (1–2 seconds) └─ Chain of local seals → RFC 3161 countersignature └─ External TSA timestamping (GlobalSign, Sectigo) └─ Timestamped eIDAS certificate 4. NOTIFICATION (immediate) └─ Kenza: "Network restored. Synchronization complete. [N] sealed records. No loss."
Figure 5: Automatic wake-up sequence. The operator does not intervene at any point.

6.2 Data Consistency

Synchronization uses a conflict-resolution strategy based on the TPM timestamp:

  • Each record has a creation timestamp (TPM source) and a modification timestamp.
  • In the event of a conflict (two concurrent modifications to the same record), the most recent version (TPM timestamp) wins.
  • Rejected versions are not deleted: they are archived in a conflict log, accessible for audit.

This strategy, known as last-write-wins, is suited to outage scenarios where modifications are sequential (a single user per organ) rather than concurrent.

6.3 Retroactive eIDAS Sealing

During the outage, seals are produced with local HMAC-SHA256 (Section 4). When the network returns, these local seals are countersigned by an eIDAS-qualified RFC 3161 timestamping authority:

  1. The chain of local seals is transmitted to the TSA server.
  2. The TSA produces an RFC 3161 timestamp covering the entire chain.
  3. This timestamp is legally binding (presumption of reliability, Article 41 of the eIDAS Regulation).

The result is a complete chain of traceability: every event that occurred during the outage has a verifiable local seal AND a timestamped eIDAS countersignature. The evidential value is identical to that of an event that occurred online.

7. Concrete Case — The July 23 Outage

On July 23, 2026, a fiber-optic cut occurred on the segment serving the 0DATA test site. The case is documented here in full.

7.1 Timeline

TimeEvent
14:31:58Last ACK packet received from the central server
14:32:00Ping timeout — outage detection
14:32:01Automatic failover to capsule mode
14:33:00Kenza confirms: "Capsule mode active. All functions maintained."
14:33:15First local HMAC seal produced (outage log)
14:35:00Operator consults the Holoscope: all organs visible, local data
14:42:00Cytokine alert detected (CPU overload) — sealed locally
15:10:00Mesh communication with node B (2.8 km) — status confirmed
15:45:00End of the Cytokine alert — sealed locally
16:09:58First ACK packet received — Internet restored
16:10:00Start of the wake-up sequence
16:10:04IndexedDB → PostgreSQL resynchronization complete
16:10:06RFC 3161 countersignature of the chain of seals
16:10:07Kenza: "Network restored. 47 records synchronized. No loss."

7.2 Analysis

The outage lasted 1 hour and 38 minutes. During this period:

  • Voice (Kenza). 12 calls handled by local FreeSWITCH. No call lost.
  • Sealing (SPINA). 47 HMAC seals produced and chained locally. All countersigned RFC 3161 on return.
  • Visualization (Holoscope). Uninterrupted operation. 3 operators consulted the interface.
  • Supervision (Cytokine). 1 alert detected, documented, sealed.
  • Storage. 2.3 MB of data written to IndexedDB, fully synchronized.
  • Mesh. Link with 2 remote nodes maintained. 18 frames exchanged.

No vital function was interrupted. The operator had no action to perform. The failover (1 second) and the wake-up (7 seconds) were entirely automatic.

7.3 Resilience Metrics

INDICATORS OF THE JULY 23 OUTAGE Outage duration .................. 1h 38min Failover time ..................... < 1 sec Wake-up time ...................... 7 sec Vital functions maintained ......... 5/5 (100%) Seals produced offline ............. 47 Seals countersigned on return ....... 47/47 (100%) Data synchronized .................. 2.3 MB (0 loss) Voice calls handled ................ 12 (0 lost) Mesh frames exchanged .............. 18
Metrics table for the July 23, 2026 outage.

8. Implications — Sovereignty as an Architectural Property

Digital sovereignty is generally approached from a legal angle: where data is stored, which law applies, who holds the encryption keys. This approach is necessary but insufficient. A system can be legally sovereign (data hosted in France, controlled encryption) and functionally dependent (it stops working if the Internet goes down).

The Sovereign Capsule shifts the question of sovereignty from the legal plane to the architectural plane. A sovereign organism is an organism that:

  1. Maintains its vital functions without external connection. Voice, supervision, sealing, visualization, and storage are provided locally.
  2. Loses no data during the outage. Local writes (IndexedDB, logs, seals) guarantee continuity of recording.
  3. Resynchronizes automatically when the network returns. No human intervention. The transition is transparent.
  4. Produces verifiable evidence even offline. Local HMAC sealing + retroactive RFC 3161 countersignature offers complete traceability.
  5. Communicates without external infrastructure. The off-grid mesh network provides last-resort connectivity, without any operator.

8.1 Sectoral Applications

Healthcare. A hospital in a rural area suffers a fiber cut. The patient record is accessible locally (PWA + IndexedDB). Nursing calls are routed by local FreeSWITCH. Monitor vitals are sealed without interruption. When the network returns, the record is synchronized with the central server.

Industry. A connected factory loses the Internet for 6 hours. Supervision continues (local Holoscope). Machine alerts are detected and sealed (offline SPINA). Teams communicate via mesh (no mobile network required). On resynchronization, the production report is complete and eIDAS-timestamped.

Agriculture. An isolated farm (no fiber, intermittent mobile coverage) uses the LoRa mesh to connect humidity sensors, weather stations, and irrigation pumps. The network operates continuously, powered by the sun. Data is consolidated locally and synchronized during the periodic passage of a connected vehicle.

8.2 The Inverted Postulate

Conventional computing posits: "Everything works with the Internet. What do we do in case of failure?"

The Sovereign Capsule inverts the postulate: "Everything works without the Internet. The Internet brings an enrichment."

This inversion is not rhetorical. It is architectural. Every component is designed, developed, and tested to operate first in isolation. Connectivity is an additional layer, not a foundation. Like a living organism that maintains its homeostasis independently of external conditions, the capsule preserves its functional integrity whatever the network circumstances.

Resilience is not a feature. It is an emergent property of an architecture in which external connectivity is never a condition of operation.

References

TIKIJJA, Hadda. "The Discipline". 0DATA Lab, Paper 001, July 2026.

TIKIJJA, Hadda. "The Nervous System". 0DATA Lab, Paper 003, July 2026. Zenodo: 10.5281/zenodo.21342768.

TIKIJJA, Hadda. "The Immune System". 0DATA Lab, Paper 005, July 2026.

TIKIJJA, Hadda. "SPINA — Sealing Protocol". 0DATA Lab, Paper 008, July 2026.

TIKIJJA, Hadda. "The First Graft". 0DATA Lab, Paper 010, July 2026.

Fall, K. "A Delay-Tolerant Network Architecture for Challenged Internets". SIGCOMM 2003.

RFC 4838 — "Delay-Tolerant Networking Architecture". IETF, 2007.

RFC 3161 — "Internet X.509 Public Key Infrastructure Time-Stamp Protocol". IETF, 2001.

Regulation (EU) No 910/2014 — eIDAS. European Parliament, 2014.

LoRa Alliance. "LoRaWAN Specification 1.1". 2017.

Trusted Computing Group. "TPM 2.0 Library Specification". 2019.

ARCEP. "Fixed Network Quality Observatory". Annual report, 2025.

Acknowledgements. To the test teams who agreed to voluntarily unplug the fiber to validate the failover protocol. To the LoRa project for freeing the 868 MHz ISM band. To the DTN community for the foundational work on delay-tolerant networks. This paper is dedicated to all the infrastructures that operate in the shadow of uncertain connectivity — rural areas, isolated sites, hostile environments. You no longer need the Internet to exist.