Video/stream bandwidth math, torrent downloads, session-hash anchoring · content/relay-capacity-and-anchoring.md

Relay Capacity, Torrent Downloads, and Session Anchoring — the engineering details

Date: 2026-09-15 · Answers the founder's three technical questions directly

1. How much would a relay use for a video feed or constant data stream?

The raw math (sending the video DATA through the relay):

A single continuous stream fills 108 GB of relay storage in 48 hours. This is absolutely NOT what relays are for. The relay is a mailbox, not a video server.

The pointer pattern (sending only the HASH through the relay):

Instead of:  video chunk → relay → viewer  (625 KB/s through relay)
Do this:     video chunk → storage node (IPFS/S3/data centre)
             chunk pointer (hash + location + decryption key) → relay → viewer

The relay stores ~700 bytes per chunk pointer. Whether 1 person or 1000 people watch, the relay holds the SAME pointers. The actual video data flows through the storage node (which is designed for bulk). This is already how our paid-unlock system works.

Constant sensor/IoT data stream (the practical use case):

Small, intermittent payloads are what relays are BUILT for. This is the IoT sensor backhaul use case.

2. Could this be used for downloads similar to torrents?

Yes — and it's actually BETTER than BitTorrent in specific ways.

How torrent-like downloads work on QALS:

UPLOADER (seeder):
  1. Split file into 256 KiB chunks
  2. Encrypt each chunk independently (AES-256-GCM)
  3. Send chunks to MULTIPLE relays (redundancy)
  4. Create a manifest: chunk_hashes + relay_locations + decryption_keys
  5. Anchor the manifest hash on-chain (one tx, ~5 seconds)

DOWNLOADER (leecher):
  1. Get the manifest (from relay, QR code, or chain)
  2. Fetch chunks from MULTIPLE relays in PARALLEL
  3. Verify each chunk against its hash
  4. Decrypt + assemble
  5. Verify the whole-file hash against the chain anchor

Comparison with BitTorrent:

What makes QALS chunks BETTER than torrents:

1. Encrypted by default — BitTorrent is plaintext; anyone on the wire sees what you're downloading
2. Payment built in — you can charge for downloads (pay-to-unlock, pay-per-chunk, subscription)
3. Provable delivery — every chunk has a receipt; the uploader can PROVE they seeded
4. Works offline — chunks can ferry via USB between air-gapped machines
5. Identity-aware — who uploaded, who downloaded, all verifiable

What makes torrents BETTER:

1. Mature ecosystem — 20 years of clients, trackers, optimisations
2. Native P2P — direct peer-to-peer transfer (no relay bottleneck)
3. Web seeding — HTTP fallback built into the protocol
4. DHT — fully decentralised tracker-less discovery
5. Massive scale — millions of peers, terabytes shared

The honest verdict:

For private, verified, paid, or receipt-needed file distribution: QALS chunks are better. For public, massive-scale, free file sharing: BitTorrent is better.

They're not competitors. They solve different problems. But the QALS chunk model can do everything a private tracker does, with encryption and receipts built in.

3. How "anchor the session hash" works

The problem: you can't anchor every frame of a live stream on-chain (each anchor takes ~5 seconds). But you want cryptographic proof of what was streamed.

The solution: periodic Merkle-tree anchoring. Here's exactly how it works:

For a live video stream:

DURING THE STREAM (every 30 seconds):
  1. Collect all video data from the last 30 seconds → call it a SEGMENT
  2. Compute: segment_hash = SHA-256(segment_data)
  3. Add segment_hash to a running list

EVERY 5 MINUTES (10 segments collected):
  4. Build a Merkle tree from the 10 segment hashes:

     segment1_hash ──┐
     segment2_hash ──┤── hash(1,2) ──┐
     segment3_hash ──┤               ├── merkle_root ──► ANCHOR ON CHAIN
     segment4_hash ──┘── hash(3,4) ──┘
     ... (etc for all 10 segments)

  5. One transaction: "the Merkle root of minutes 0-5 of this stream = 0x7f3a..."
  6. The chain now has a tamper-proof fingerprint of exactly 5 minutes of video

AFTER THE STREAM:
  7. Anyone can verify: "was this video modified after the stream?"
     → Recompute segment hashes → rebuild Merkle tree → compare root to chain
     → If they match: the video is provably unmodified
     → If they differ: someone tampered with it

For a file backup verification:

MONTHLY VERIFICATION:
  1. Download your backup from S3/NAS/wherever
  2. Compute SHA-256 of the backup file
  3. Compare against the hash anchored on QALS

  → If they match: your backup is intact
  → If they differ: something changed (corruption, tampering, ransomware)
  → The chain proves WHEN the original hash was recorded

For an AI-agent conversation:

DURING THE CONVERSATION (every message):
  1. Each message gets a hash: h_i = SHA-256(h_{i-1} || message_ciphertext)
  2. This forms a CHAIN (each hash includes the previous)
  3. Every N messages (or every hour), anchor the latest hash on-chain

  → The chain proves: what was said, in what order, and that nothing was
    deleted or reordered (because each hash includes the previous one)

The concrete numbers:

Every anchor is exactly 32 bytes on-chain regardless of how much data it represents. You could anchor a 4-hour movie (a few GB) with a single 32-byte hash. The chain is a fingerprint machine, not a storage system.

The three-layer security model:

Layer 1: ENCRYPTION (protects content)
  → Only the intended recipient can read the data

Layer 2: HASHING (protects integrity)
  → Any change to the data changes the hash

Layer 3: ANCHORING (protects history)
  → The hash is on the chain; nobody can change what was recorded or when

All three together: the content is private, the integrity is verifiable, and the history is permanent.