Files

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.0 KiB

Raw Blame History

Phase 3 — User Acceptance Testing (Federation & Key Transparency)

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

Prerequisites

Phase 2 UAT fully passing
Two warzone-server instances on different domains
DNS zone control for both domains

1. DNS Server Discovery

Setup TXT record:

_warzone._tcp.a1.example.com  TXT  "v=wz1; endpoint=https://wz.a1.example.com; pubkey=base64..."

Test discovery:

cargo run --bin warzone-client -- discover a1.example.com

Resolves TXT record
Shows endpoint URL and server public key
Server pubkey pinned on first contact (TOFU)

2. DNS Key Transparency

Publish key to DNS:

cargo run --bin warzone-client -- publish-key --domain a1.example.com

TXT record created: manwe.a1.example.com TXT "v=wz1; fp=...; pubkey=...; sig=..."
Self-signature is valid
Only server's delegated zone is modified

Verify key via DNS:

cargo run --bin warzone-client -- verify-key @manwe.a1.example.com

Fetches TXT record
Verifies self-signature
Compares against server-provided key
Match → "Key verified via DNS"
Mismatch → "WARNING: server may be performing MITM"
No DNS record → "Falling back to TOFU"

3. Federated Messaging

Server A (a1.example.com) and Server B (b1.example.com):

Alice is on Server A, Bob is on Server B.

Alice sends to Bob:

/dm @bob.b1.example.com hello from server A!

Client resolves b1.example.com via DNS
Fetches Bob's bundle from Server B
X3DH + Ratchet encrypt
Message sent via Server A → Server B relay
Bob receives on Server B
Bob decrypts successfully

Bob replies:

/dm @alice.a1.example.com hey alice!

Reverse path works (B → A)
Existing ratchet session reused

4. Server-to-Server Mutual TLS

Server A connects to Server B with TLS
Both servers verify each other's pubkey (from DNS TXT)
Invalid server pubkey → connection refused
Man-in-the-middle between servers → TLS fails

5. Gossip Peer Discovery

Server A knows Server B. Server C joins:

Server C registers with Server A
Server A gossips Server C's endpoint to Server B
Server B can now route messages to Server C users
No manual configuration needed on Server B

6. Hard-coded Peer List (DNS Fallback)

DNS is down:

cargo run --bin warzone-server -- --peers "https://wz.b1.example.com,https://wz.c1.example.com"

Server connects to listed peers directly
Federated messaging works without DNS

Summary

#	Feature	Result
1	DNS server discovery	☐
2	DNS key transparency	☐
3	Federated messaging	☐
4	Server mutual TLS	☐
5	Gossip peer discovery	☐
6	Hard-coded peer fallback	☐

Tester: _______________ Date: _______________

3.0 KiB Raw Blame History