What relays are, how they scale, the every-wallet-is-a-relay path · content/relay-architecture.md

The Relay Architecture — what relays are, how they scale, and the path to every-wallet-is-a-relay

Date: 2026-09-15 · Answers: "What are relays? Could they run on data centres? Could every wallet be a relay?"

What IS a relay?

A relay is the dumbest possible thing: a mailbox that can't read your mail.

You ────[encrypted envelope]──► RELAY ────[encrypted envelope]──► Recipient
         (POST /envelopes)     stores       (GET /envelopes/{handle})
         ~700 bytes            briefly      pulls when online

It's a single Python file (~500 lines). No database, no blockchain, no crypto keys. It: 1. Accepts an encrypted envelope (HTTP POST) 2. Stores it (in memory + a JSON file) 3. Serves it to the recipient when they ask (HTTP GET) 4. Cannot read anything — it stores ciphertext, byte-proven in tests

That's it. A $5/month VPS can run one and handle ~10,000 messages/day. The relay is deliberately, structurally stupid — that's the security feature.

Why we don't need Tailscale

Tailscale is just our current transport — a VPN mesh. The relay is an HTTP server; it works over ANY network:

Proof without Tailscale: the relay binds to 0.0.0.0 (all interfaces). Any device that can reach the relay's IP can use it. The offline ferry test proved the system works with NO network at all — envelopes exported to a file, carried to another machine, imported, decrypted. The relay is a convenience, not a dependency.

The 48-hour TTL storage concern (and the fix)

The honest math:

Messages are negligible. Files are the concern. Three solutions (in order of preference):

Solution 1: Files go to storage providers, relays carry only the pointer

Sender ──[file → IPFS/S3/data centre]──► storage node returns: content_hash
Sender ──[content_hash + decryption_key]──► relay (~700 B, same as a message)
Recipient ──pulls pointer from relay──► [fetches file from storage] ──[decrypts]

The relay stores a ~700-byte pointer instead of a 10 MB file. The file lives on a storage node (which CAN be a compute provider — see below). This is already how our paid-unlock system works.

Solution 2: Configurable TTLs per content type

• Messages: 48h (they're tiny)
• File pointers: 48h (tiny)
• File chunks: 4h or "until downloaded" (auto-purge on receipt confirmation)
• This is a config change, not a code change

Solution 3: Relay tiers

• Tier 1: free relays (48h TTL, small file limit — the current model)
• Tier 2: paid relays (longer TTL, larger files — run by data centres)
• Tier 3: self-hosted (you run your own relay, unlimited TTL)

YES — compute providers can be relays (the elegant convergence)

This is the best idea in this document. Compute providers already have: - Machines with spare RAM and disk (between GPU jobs) - Network connectivity (they serve compute results) - An economic relationship with the network (they earn QALS)

A relay costs nothing to run alongside compute:

# provider.py already runs a job server on :8850
# Add relay mode — same process, zero extra dependencies:
python3 provider.py run --relay-mode   # now also serves envelopes on :8851

The provider earns: - Compute revenue (the main business) - Optional relay fees (relay operators can charge for longer TTL / larger files) - Or offer free relay as a value-add ("use my compute, get free messaging")

This creates the relay mesh automatically: wherever there's compute, there's a relay. Data centres become relay hubs. The village Starlink operator becomes a relay. The office compute hub becomes a relay. No separate infrastructure needed.

YES — wallets can be relays (the ultimate distribution)

Every wallet holder becomes a relay node. This is the BitTorrent/DHT pattern applied to our envelope model:

Wallet A (laptop)     Wallet B (phone)     Wallet C (data centre)
    │                     │                     │
    ├── relay :8831       ├── relay :8832       ├── relay :8833
    │                     │                     │
    └── When A sends to B, the message routes through
        the NEAREST relay (which could be B itself, or C, or A)

How it works: 1. The wallet app has a "relay mode" toggle (off by default, opt-in) 2. When on, it listens on a port and stores/forwards envelopes 3. The sender's client discovers nearby relays (via the chain, DHT, or local network) 4. Messages route through the closest/least-loaded relay 5. Relay reputation is tracked on-chain (did it deliver? did it lose envelopes?)

What this gives you: - Massive redundancy: thousands of relays = no single point of failure - Zero infrastructure cost: the users ARE the infrastructure - Latency: your relay is your own device (0ms for local messages) - Censorship resistance: no relay to shut down - Offline resilience: local relay works when the internet doesn't

What it costs: - Battery (mobile wallets might not want to relay — desktop wallets are better) - Storage (envelopes are tiny; the TTL limit caps it) - Complexity (relay discovery + routing is a real engineering problem)

The relay evolution path

Phase 0 (NOW):     One relay on our server (superlocal)
Phase 1 (weeks):   Fleet relays (cachyos-x8664 already live; bb-mini ready)
Phase 2 (months):  Compute providers add relay mode (provider.py --relay)
Phase 3 (year):    Every wallet is a relay (the BitTorrent model)

At every phase, the existing relays keep working. The system gets MORE resilient, not different. A Phase-0 client can send through a Phase-3 relay mesh without knowing the difference.

The full relay picture (summary table)

All of these speak the same protocol. All store the same encrypted envelopes. All are interchangeable.