QALS Wiki · the qalarc network⌂ qalarc.com/projects/qals
generated 2026-09-16 · qalcode autonomous research

The village Starlink share — one payer, many users, operator-set prices, escrowed prepay, mesh messaging always free · content/metered-wifi.md

Metered WiFi — the village gateway

Date: 2026-09-13 · Service: qalhotspot/ (:8844, paper v0) · Companions: Mesh & Unconventional Pipelines · Qal Chat design · Fees

The founder's line that started it: "people on a network can on-sell WiFi connection, or have metered WiFi, if one person in a village is supplying Starlink. It would also enable communications."

Three sentences, three products: resale (on-sell WiFi), metering (pay per use), communications (the mesh that keeps talking when the quota doesn't). qalhotspot is all three on one gateway.

Honest v0 label: the current gateway does no traffic shaping. Metering is accounting-only — a client script reports bytes and the gateway does the money math (escrow, settle, refund, anchor). Production hooks nftables per-station counters behind the identical API. Everything about money below is real and tested today; everything about bytes is simulated today.


1. The village model: one payer, many users, self-funding backhaul

The expensive part of rural connectivity is the backhaul — one Starlink dish, one LTE router, one long-range point-to-point link. The qalhotspot model puts that link under an operator (anyone with the dish and a QALS identity) and lets everyone else prepay small credit from their own loopd agents:

The circular economy, drawn:

      AU$ (Starlink bill)                QALS (prepaid credit)
           ▲                                     │
           │ payer buys                          │ guests prepay
           │ backhaul                            ▼
   ┌─────────────────┐      sells bytes      ┌─────────────────┐
   │  OPERATOR       │◄──────────────────────│   GUESTS        │
   │ "village        │   their own price     │ own loopd agents│
   │  Starlink"      │──────────────────────►│ escrowed holds  │
   └────────┬────────┘  metered internet    └────────┬────────┘
            │ earns QALS                             │ welcome/warning/receipt DMs
            ▼                                        ▼
   ┌─────────────────────────────────────────────────────────┐
   │      qalchat MESH — ALWAYS FREE (zero-rated)            │
   │  encrypted envelopes via the local relay                │
   └────────┬────────────────────────────────────────────────┘
            │ conversation Merkle roots + wifi receipts
            ▼
       qalpipe anchor → the chain remembers

The network pays for its own backhaul: guest demand funds the operator, the operator keeps the dish alive, the dish feeds the mesh the village runs on.

2. Pricing freedom — the operator sets the rate; the network takes zero

Ground truth F16 says chain fees are zero — the network never charges its users. A hotspot applies the same doctrine at the access layer. The operator picks price_cents_per_mb at registration (default 2c/MB = AU$20/GB): AU$5/GB in a competitive street, AU$1/MB at a festival with one satellite phone. It's their uplink, their risk, their price. The settlement path is guest-escrow → operator-agent, peer to peer: no platform cut, no treasury skim, nothing to capture. This is the same spread = model honesty as everywhere else in QALS — pricing is a market fact between two parties, not a tax event.

3. The zero-rated principle: messaging is a right, not a metered good

The split that makes the model humane:

class what price
internet general traffic across the paid backhaul operator's rate
mesh qalchat envelopes to/from the local relay always free — allowlisted

A village that has burnt its quota can still message: the doctor, the family member in the city (queued for when anyone reconnects — the ferry model), the local buy/sell group. The gateway's own notices — welcome, 80% warning, anchored receipt — ride that free class, because the gateway is a qalchat client (it sends encrypted DMs through the hub relay; the relay sees ciphertext like any other carrier). GET /mesh-status states the contract in one line: "messaging": "always on" — messaging never consumes paid backhaul, even at 0 balance.

4. What is real today vs simulated (v0 scorecard)

piece status
escrow hold on guest agent, 115% real (loopd, debited at placement)
integer-cent metering math, auto-cut at 0 real (tested exact)
settle-to-beneficiary + exact refund real (to_agent_id, itemised receipt)
chain-anchored receipts (qalpipe verify PASS) real
welcome / warning / receipt DMs real (encrypted, via relay)
byte reports simulated (client script; nftables in v1)
captive portal / traffic shaping not built (portal = the DM itself in spirit)

5. Production path

  1. nftables metering — per-station counters replace client-reported bytes; the /meter API is unchanged.
  2. Captive portal — TLS gateway; the welcome DM is the onboarding (a guest needs only qalchat); a plain web page for first bootstrap.
  3. Voucher codes — the kiosk sells scratch cards; a code redeems into a session prepay without any smartphone at all.
  4. Hold keepalive — re-auth before the 5-minute hold TTL for long sessions; true per-user daily caps across sessions.
  5. Roaming — operators cross-accept guests and settle operator-to-operator; zero network fees makes bilateral rates a one-line agreement.

6. Where it goes next: carriers

HTTP relay is carrier #0 (proven here end-to-end with money). The carrier plugin sketchput(envelope)/poll(handle) — drops the same gateway into a LoRa ring: a 32-byte conversation anchor crosses a mesh in a single LoRa frame, so proofs and receipts travel even when the Starlink dish is down. Village = one paid backhaul + one free mesh + deferred anchoring. That's the deployment this folder is the first brick of.


Local refs: qalhotspot/README.md (runbook + systemd unit pattern) · qalhotspot/test_qalhotspot.sh (the proof suite) · content/ground_truth.md F16 (zero chain fees) · content/mesh-pipelines.md (carrier sketch).