Files
featherChat/warzone/UAT/PHASE4.md
Siavash Sameni c8b51fa96b UAT test plans for all 7 phases
UAT/PHASE1.md — 20 test scenarios, 80+ checkboxes
  Identity, encryption, messaging, TUI, web, groups, aliases,
  auth, OTP replenishment, session persistence, cross-client

UAT/PHASE2.md — 7 scenarios (WASM, receipts, files, multi-device, HW wallet, groups, history)
UAT/PHASE3.md — 6 scenarios (DNS discovery, key transparency, federation, mutual TLS, gossip)
UAT/PHASE4.md — 10 scenarios (mule identity, pickup, delivery, receipts, dedup, expiry, compression)
UAT/PHASE5.md — 6 scenarios (Bluetooth, LoRa, mDNS, Wi-Fi Direct, USB export, fallback chain)
UAT/PHASE6.md — 3 scenarios (sealed sender, traffic analysis resistance, onion routing)
UAT/PHASE7.md — 8 scenarios (ntfy, DoH, DB encryption, admin CLI, rate limiting, audit, CI, monitoring)

Each test has exact commands to run and checkboxes for pass/fail.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-27 08:01:36 +04:00

3.9 KiB

Phase 4 — User Acceptance Testing (Warzone Delivery / Mule Protocol)

Phase 4 is NOT YET IMPLEMENTED. This is a pre-written test plan.

Prerequisites

  • Phase 3 UAT fully passing
  • Two isolated networks (can use VMs or Docker networks)
  • A device that can move between networks (the mule)

1. Mule Identity & Authorization

cargo run --bin warzone-mule -- init
cargo run --bin warzone-mule -- register -s http://server-a:7700
  • Mule generates its own identity
  • Mule registered with Server A
  • Server admin authorizes mule: warzone-server admin authorize-mule <mule-fp>
  • Unauthorized mule rejected on pickup attempt

2. Message Pickup

Server A has queued messages for users on Server B (which is offline):

cargo run --bin warzone-mule -- pickup -s http://server-a:7700
  • Mule connects to Server A
  • Mule authenticates (challenge-response)
  • Server returns queued outbound messages (encrypted blobs)
  • Messages marked as "IN_TRANSIT by mule X" on Server A
  • Mule stores messages locally
  • Mule reports capacity: "Picked up 42 messages (1.2 MB / 50 MB capacity)"

3. Physical Transport & Delivery

Mule moves to Server B's network:

cargo run --bin warzone-mule -- deliver -s http://server-b:7700
  • Mule connects to Server B
  • Delivers encrypted blobs
  • Server B queues messages for local recipients
  • Server B returns delivery receipts (signed)
  • Mule stores receipts locally

4. Receipt Delivery

Mule returns to Server A's network:

cargo run --bin warzone-mule -- receipts -s http://server-a:7700
  • Mule delivers receipts to Server A
  • Server A marks messages as DELIVERED
  • Server A removes messages from outbound queue

5. Receipt Enforcement

Mule tries to pick up again WITHOUT delivering previous receipts:

cargo run --bin warzone-mule -- pickup -s http://server-a:7700
  • Server A rejects: "outstanding receipts not delivered"
  • Mule must deliver receipts first (or submit signed failure report)

6. Deduplication

Two mules pick up the same messages:

  • Mule 1 picks up and delivers to Server B
  • Mule 2 picks up same messages (still in transit)
  • Mule 2 delivers to Server B
  • Server B deduplicates: messages delivered once, no duplicates for recipients

7. Message Expiry

Messages older than TTL:

  • Server queues message with 7-day TTL
  • After 7 days without pickup → status changes to EXPIRED
  • Expired messages not given to mules
  • Expired messages cleaned up from DB

8. Outer Encryption (Metadata Hiding)

  • Messages from Server A to Server B wrapped in outer encryption (Server B's pubkey)
  • Mule sees only: "encrypted blob for Server B"
  • Mule cannot see sender/recipient fingerprints
  • Server B unwraps outer layer, routes inner messages to recipients

9. Partial Sync / Resume

Mule connection interrupted during pickup:

cargo run --bin warzone-mule -- pickup -s http://server-a:7700
# kill connection mid-transfer
cargo run --bin warzone-mule -- pickup -s http://server-a:7700
  • Second pickup resumes from where it left off
  • No duplicate messages in mule's local store

10. Compression

  • Message bundles compressed with zstd before transfer
  • Mule reports compressed size: "42 messages: 1.2 MB → 400 KB (67% compression)"
  • Decompression on delivery

Summary

# Feature Result
1 Mule identity & auth
2 Message pickup
3 Physical delivery
4 Receipt delivery
5 Receipt enforcement
6 Deduplication
7 Message expiry
8 Outer encryption
9 Partial sync
10 Compression

Tester: _______________ Date: _______________