Video summary

The Anywhere Network is Here

Main summary

Key takeaways

Technology

Technological concepts & system overview

  • Goal: Enable two-way messaging from places with no normal phone cell service using an open-source mesh networking stack (Reticulum) bridged to Iridium satellite coverage.
  • Core product concept: A “Reticulum Iridium relay bridge” that connects:
    1. A Raspberry Pi Zero (running a local network + routing logic)
    2. Ground Control’s RockBLOCK 9704 satellite modem
    3. Iridium’s global constellation (via low Earth orbit satellites)
    4. Iridium CloudLoop (Iridium cloud hub)
    5. A cloud bridge (GCP server) to move messages between CloudLoop ↔ Reticulum
    6. Reticulum client app on Android: Columba

Motivation / positioning

Instead of relying on closed satellite messaging services, the bridge lets anyone build/open infrastructure that uses Reticulum’s encrypted, censorship-resistant, decentralized “network of networks” model.

Key hardware features called out

RockBLOCK 9704

  • Uses an L-band frequency range (~616 to 1626.5 MHz)
  • Has an SMA antenna connector
  • Uses a helical RHCP antenna to reduce problems from antenna orientation/nulls (useful while moving)

Power system innovation

  • Supercapacitors on the modem board:
    • Store energy and release quickly to power short burst transmissions to Iridium

Programming / control hardware

  • Raspberry Pi OS on Raspberry Pi Zero
  • Ground Control provides example Python scripts that send/receive via modem AT commands
  • Mentions use of CodeX to generate scripts on demand (aid for development/iteration)

Backend visibility tools

  • Iridium CloudLoop used to confirm message logs (MO/MT directions: modem originated vs modem terminated)

Reticulum + bridging architecture (how messages move)

Reticulum basics

  • Uses cryptography to form autonomous, multi-hop networks
  • Messages route over whatever mediums exist (radio / Wi‑Fi / internet / satellite link)
  • Only the recipient with the private key can decrypt, so intermediate nodes don’t need to be trusted
  • Supports very large node discovery (Columba discovering 10,000+ nodes mentioned)

Custom integration components

  • Uses a fork of MeshChat (named Crosstalk) to create a Reticulum-compatible Iridium interface
  • Uses a GCP cloud bridge to forward messages between CloudLoop and the Reticulum network

CloudLoop forwarding approach

  • A CloudLoop webhook forwards each message to a private server
  • That server injects messages into Reticulum so other nodes reachable over TCP can deliver them

Two-way path handling

  • Forward direction (Pi → RockBLOCK → Iridium → CloudLoop → Reticulum → Columba) was tested first.
  • Return direction was added via logic on GCP that queues outgoing RockBLOCK messages using CloudLoop’s API.

Delay tolerance & asynchronous networking concept

The video emphasizes Reticulum’s asynchronous “store-and-forward” / delay-tolerant design:

  • Unlike phone calls/texts that require both ends and a path to exist at the same time, Reticulum can store encrypted messages on propagation nodes until a route becomes available.
  • This is framed as ideal for satellites that pass overhead only during brief windows.

Cost / limitations & rate-control strategy

Paid satellite transport (important constraint)

  • Ground Control monthly fee: $15 for keeping the modem active
  • Per-message cost: ~10 cents one way for short messages
  • Risk: if funds reach zero, satellite message delivery stops

Mitigation: allow list on the GCP bridge

  • Only forwards messages addressed to a specific LXMF hash (the bridge’s intended Iridium device)
  • Drops other traffic before it can consume paid satellite bandwidth

Tutorial / build steps implied by the workflow

While not presented as a formal tutorial list, the narrative implies a repeatable build/test pipeline:

  1. Get RockBLOCK working with example scripts (AT command-based send/receive)
  2. Verify message delivery using Iridium CloudLoop logs
  3. Add a Reticulum-side interface by using Crosstalk (MeshChat fork)
  4. Build the CloudLoop ↔ GCP ↔ Reticulum bridge (webhook + injection into Reticulum)
  5. Implement reverse direction via GCP queueing through CloudLoop API
  6. Test end-to-end round trip, first in partial legs (then later at home)
  7. Use delay-tolerant behavior rather than real-time handshake assumptions

Field test (Colorado trail run) — results and analysis

Real-world test scenario

  • ~14-mile trail run in the Colorado Rockies
  • Climbing to ~13,000 ft
  • Attempting to send a message to a phone left at home (Android burner running Columba)

Pre-test expectation

  • Normal two-way messaging (“full conversation”) with mom, despite no cell service

Observed connectivity pattern

  • Modem signal availability was limited to ~7-minute windows as satellites crossed line-of-sight
  • Inside the condo:
    • signal graded 0–5
    • usable windows increased as satellites became visible

Race-day outcome

  • On the mountain, messages sent during the window produced zero acknowledgements over several attempts
  • He concluded the conversation failed and powered down the bridge to focus on the race
  • Later inspection:
    • four messages did reach the server (satellite uplink worked)
    • but the return/round-trip conversation path failed somewhere

Identified likely failure suspects

  1. Sky / line-of-sight limitations: trees/obstructions may prevent holding a stable return link long enough
  2. Software / bridge issues: rushed GCP bridge logic might mishandle the reverse path/ack timing

Comparison mention

  • The video contrasts the mobile backpack bridge with race organizers’ fixed field comms (Starlink mini + other radio gear), highlighting different operational assumptions.

Successful home retest — key “round-trip” proof

Retest setup

  • After the race, re-tested in a controlled environment:
    • Same RockBLOCK + Raspberry Pi + GCP bridge
    • Used Amelia’s Android burner instead of his mom

Result

A complete, natural two-way chat worked:

  • Crosstalk felt like a normal messaging app
  • Multiple message exchanges traversed Wi‑Fi (Pi ↔ phone) → Reticulum → RockBLOCK → Iridium → GCP → Columba, then back in reverse

Main takeaway

The system can do an end-to-end encrypted conversation; the Aspen failure was environmental/timing/round-trip scheduling dependent.

Main speakers / sources (as referenced)

Primary speaker / creator

  • “Parallel” (narrator and builder; references “Parallel Primer” and “Build with Parallel” domains)

Named contributors / subjects

  • Mark (author referenced: “The Zen of Reticulum”)
  • Kyriakos (Mesh Sat founder; discussed earlier satellite modem usage)
  • Harvard paper source: “Your Brain on Nature” (authors not named in subtitles)

Race organizers mentioned

  • Aravaipa (trail run event)

Mentions of people in the test

  • Mom (left a burner Android phone running Columba)
  • Amelia (running with narrator; later used as the live reply target during home retest)

Original video