The complete tech stack + every 'could you use it for X?' answered · content/technical-feasibility.md
Technical Feasibility — the complete tech stack, edge cases, and what's actually possible
Date: 2026-09-15 · Answers: "Could it theoretically stream video or do backups? It would just have more latency? Explore all questions like this. Needs an explanation of the tech stack."
1. The tech stack, explained for humans
Layer 1: The Chain (Qalnet)
WHAT IT IS: A private blockchain that works like a fishing net (DAG), not a train (chain).
WHAT IT DOES: Keeps a tamper-proof record of WHO sent WHAT to WHOM — but never the content itself.
| Component | What it is | What it does |
|---|---|---|
| Qalnet | Fork of IOTA's node software (itself a Sui fork) | Runs the chain, validates transactions |
| Starfish consensus | DAG-based BFT (academic paper: IACR 2025/567) | Agrees on transaction order in < 1 second |
| Move VM | Smart contract engine (from Sui/Diem lineage) | Runs our contracts safely — resources can't be duplicated or destroyed accidentally |
| qal_data | Smart contract | Creates DataAnchor objects (hash + URI + timestamp) on-chain |
| qal_credit | Smart contract | CreditAccount + Hold — enforces spending caps and pre-authorised payments |
| qal_reserve | Smart contract | The mint gate — refuses to create QALS beyond the cap (bytecode-enforced) |
Key insight: the chain stores HASHES, not data. A 10 GB file becomes one 32-byte hash on-chain. The chain is the RECEIPT system, not the storage system.
Layer 2: The Services (the actual product)
Every service is a single Python file (~300-800 lines), zero external dependencies, runs on any machine. This is deliberate: audit-able, portable, fleet-deployable.
| Service | Port | What it does (one line) |
|---|---|---|
| loopd | 8823 | Money rails — holds, settles, caps, transfers |
| qalchat | 8830 | Encrypted messaging relay (stores ciphertext only) |
| qalpub | 8832 | Public channels, paid unlocks, workspaces |
| qalmarket | 8824 | Compute marketplace (escrow, disputes, slashing) |
| qalbazaar | 8834 | Agent-to-agent marketplace |
| qalkeys | 8841 | API-token resale + metering |
| qalredeem | 8835 | Service redemption + cash-out gate |
| qalclaim | 8836 | Points → credit claims |
| qalid | 8838 | Digital identity (DID, prove/verify) |
| qalpay | 8839 | Payment bridge (PSP webhooks → credit) |
| qalpipe | CLI | Anchors file hashes on-chain |
| qalsh | CLI | Guarded remote exec ("SSH for AI") |
| qalhotspot | 8844 | Metered WiFi (village Starlink share) |
| qalx | 8843 | Swap engine (AMM) |
Layer 3: The Clients
| Client | Platform | What it shows |
|---|---|---|
| Qal Wallet | Desktop (Tauri/Rust) | Money + chat + compute in one app |
| Phone bridge | Mobile web (any browser) | Chats, files, redemption, balance |
| MCP server | CLI/stdio | 24+ tools for AI agents |
| Web demos | Any browser | Interactive wallet/chat/compute simulations |
Layer 4: The Transport
CURRENT: Tailscale mesh (WireGuard VPN between our machines)
WORKS ALSO: Any HTTP network, LAN, LoRa radio, Bluetooth, offline ferry, satellite
DOESN'T NEED: Tailscale, public internet, DNS, or any specific infrastructure
The relay (qalchat) is a simple HTTP server that stores encrypted envelopes. It works over anything that can carry HTTP — or even nothing at all (the offline ferry exports/imports envelopes as files).
2. Could it stream video?
Short answer: technically yes, practically wrong tool for live streaming. Right tool for video messages.
The math:
| Scenario | Data rate | Envelope overhead | Latency | Verdict |
|---|---|---|---|---|
| Video MESSAGE (like WhatsApp video note, 30 sec, 5 MB) | 5 MB burst | ~7% (356 KB) | 2-5 seconds | ✅ Works well — send it like a file, recipient gets a receipt |
| Video CLIP delivery (on-demand, 100 MB) | 100 MB burst | ~7% (7 MB) | 10-30 seconds | ✅ Works — like downloading a file with a receipt |
| LIVE STREAMING (1080p, 5 Mbps continuous) | 625 KB/second | ~5% (31 KB/s) | 200-500ms per chunk | ⚠️ Marginal — the latency makes it unsuitable for real-time, but works for "near-live" (5-second delay) |
| LIVE GAME STREAMING (needs < 50ms) | same | same | same | ❌ Wrong tool — use WebRTC/RTP, anchor the session hash here |
Why the latency exists:
Every chunk goes through: encrypt → POST to relay → relay stores → recipient GETs → decrypt
That's two HTTP round trips (POST + GET) = minimum 200ms over the internet, plus chunk assembly time. For live video, you need WebRTC (direct peer-to-peer, < 50ms). But for video MESSAGES, 2-5 seconds is completely fine — that's how WhatsApp video notes work anyway.
The right pattern for video:
For video messages:
1. Encrypt video file (AES-256-GCM, chunked)
2. Send through relay (like any file)
3. Receipt anchored on-chain
→ Recipient gets video + proof it wasn't tampered with
For live video:
1. Stream via WebRTC (direct peer-to-peer, low latency)
2. Every 30 seconds, hash the video stream so far
3. Anchor that hash on QALS
→ You get a tamper-proof record of what was streamed, without the latency
3. Could it do backups?
Short answer: no for the data itself, yes for the verification.
Why not the data:
| Backup size | Chunks (256 KiB) | Overhead | Time to upload | Relay storage |
|---|---|---|---|---|
| 10 GB | 40,960 | 716 MB (7%) | ~15 min at 100 Mbps | 10.7 GB for 48h |
| 100 GB | 409,600 | 7.2 GB (7%) | ~2.5 hours | 107 GB |
| 1 TB | 4,096,000 | 72 GB (7%) | ~25 hours | 1.07 TB |
The relay isn't designed to be a backup target. It's a mailbox, not a warehouse. Storing 1 TB of encrypted chunks at a relay for 48 hours is: - Expensive (the relay operator pays for storage) - Wasteful (the relay is a simple Python server, not S3) - Missing the point (the relay is for TRANSFER, not STORAGE)
The right pattern for backups:
TRADITIONAL BACKUP (what you already do):
1. Back up to S3/Backblaze/your NAS
2. ??? how do you PROVE the backup wasn't corrupted? ???
QALS-VERIFIED BACKUP (the value add):
1. Back up to S3/Backblaze/your NAS (same as before)
2. Compute the hash of each backup file
3. Anchor those hashes on QALS (one tx per file, ~5 seconds)
4. Monthly: re-hash the backup, compare against the chain
→ You now have CRYPTOGRAPHIC PROOF that your backup hasn't been corrupted,
tampered with, or silently changed — verifiable by anyone, forever.
This is the "anchor the hash, not the data" pattern. The backup lives wherever you want (S3, IPFS, your NAS). QALS is the verification layer that proves it's intact.
4. Every feasibility question, answered
| "Could you use QALS to..." | Answer | Why |
|---|---|---|
| Stream live video | ❌ wrong tool | Latency (200ms+) unsuitable for real-time; use WebRTC, anchor session hash here |
| Send video messages | ✅ yes | Same as file transfer — encrypted, receipted, 2-5s delivery |
| Do full backups | ❌ wrong tool | Relay isn't a warehouse; 7% overhead + relay storage burden |
| Verify backups | ✅ killer use case | Anchor backup hashes → prove integrity forever |
| Transfer files | ✅ yes | 256 KiB chunks, ~7% overhead, ~1s per 10 MB on 100 Mbps |
| Send large datasets (10-100 GB) | ⚠️ marginal | Works but slow; better to use IPFS/direct and anchor the hash |
| IoT sensor data | ✅ excellent fit | Small payloads (~100 B), intermittent connectivity, receipts prove the data chain |
| AI agent-to-agent commerce | ✅ built for this | Capped wallets, escrow, receipts — the core design |
| Real-time chat | ✅ yes | < 100ms delivery on same network, < 500ms across internet |
| Voice/video calls | ❌ wrong tool | Need WebRTC; but QALS can carry the call SETUP and the session receipt |
| Payment rails | ✅ core function | Pre-authorised, instant, receipted — this is what it's built for |
| Identity/login | ✅ built for this | DID challenge-response, no passwords, 2s revocation |
| Smart contracts | ✅ via Move | Resource-safe, compiled, audited — same lineage as Sui |
| Token trading | ✅ via qalx | AMM running today, 64/64 tests green |
| File storage (like Dropbox) | ❌ wrong tool | Relay TTL is 48h; use IPFS/S3, anchor hashes here |
| DNS-like naming | ✅ possible | qoll-codes already do this for identity; extendable |
| Supply chain tracking | ✅ strong fit | Every transfer receipted, tamper-proof chain of custody |
| Voting/governance | ✅ possible | Identity-verified, receipt-anchored votes |
| Micro-payments (per-API-call) | ✅ built for this | qalkeys does exactly this, metered per request |
| Remote code execution | ✅ via qalsh | Whitelist-only, paid, anchored — "SSH for AI" |
5. The honest limitations summary
| Limitation | Severity | Workaround |
|---|---|---|
| Latency: 200ms+ per transfer (2 HTTP round trips) | Medium | For real-time: use direct P2P (WebRTC/RTP), anchor session hash here |
| 7% overhead on bulk data (chunking + envelopes) | Low | For large files: use IPFS/S3/direct, anchor hash here |
| 48h relay TTL (envelopes expire) | Medium | Pointer pattern: file goes to storage, pointer goes through relay |
| Single-relay bottleneck (each relay is one Python server) | Medium | Multi-relay mesh; compute providers add relay mode; every-wallet-is-a-relay |
| Not anonymous (relay sees who-to-who metadata) | Low-Medium | Content is encrypted; metadata is visible to relay operator only; multiple relays = no single observer |
| Chain anchoring is async (5-10 seconds) | Low | The transfer itself is instant; the receipt lands in seconds |
| No built-in compression | Low | Compress before sending (client-side); the relay stores what you give it |
| Move expertise needed for smart contracts | Medium | Our contracts are written and tested; new ones need a Move developer |
6. The fundamental insight
QALS is not a transport protocol. It's a verification protocol that rides on top of any transport.
TRANSPORT LAYER (pick any):
HTTP / WebRTC / LoRa / Bluetooth / offline ferry / satellite
↓
ENVELOPE LAYER (QALS relay):
encrypted store-and-forward + identity verification
↓
VERIFICATION LAYER (Qalnet chain):
tamper-proof receipts for every transfer
↓
APPLICATION LAYER (pick any):
chat / payments / compute / files / identity / WiFi metering / API resale
You don't replace your transport with QALS. You add QALS on top of whatever you already use, and get receipts for everything. That's the value proposition.