Relay Architecture
The Problem
Even with perfect E2E encryption, third-party relays can expose metadata: who communicates with whom, when, how long, and from which IP address. Encryption protects the content — not the communication structure.
Current Architecture
| Component | Function | Risk Level |
|---|---|---|
| Kaspa Identity Layer | Public key anchor on BlockDAG | Low (decentralized) |
| Ephemeral Relay Pool | Message forwarding | Medium (relay sees sender IP) |
| SMP-style Queues | Unidirectional anonymous queues | Medium (queue server is central) |
| KAS Micropayments | Relay operator incentives | Low (decentralized) |
Threat Model
| Level | Adversary | Protection Status |
|---|---|---|
| L1 | Passive Observer (network sniffing) | Achieved (E2E) |
| L2 | Active Relay Operator (IP, timing) | Partial |
| L3 | State-Level Adversary (global observation) | Target of this roadmap |
Solution: Tor Hidden Services + Onion Routing
Phase 2 (Q3 2026) — Tor for Relay Nodes
All relay nodes operate as .onion Hidden Services. Clients connect via Tor SOCKS5 proxy. Neither client IP nor relay IP is visible to third parties.
// Android: tor-android library
dependencies {
implementation 'info.guardianproject:tor-android:0.4.8.12'
implementation 'info.guardianproject:jtorctl:0.4.5.7'
}
// Proxy-Socket for OkHttp via Tor-SOCKS5
val torProxy = Proxy(Proxy.Type.SOCKS, InetSocketAddress("127.0.0.1", 9050))
val client = OkHttpClient.Builder().proxy(torProxy).build()
// .onion address of the relay node
val relayEndpoint = "http://xxxxxxxxxxxxxxxx.onion/queue"
Kaspa Node-Registry On-Chain
Relay nodes register their X25519 public keys and .onion addresses directly on the Kaspa BlockDAG via OP_RETURN transactions — trustless, decentralized, immutably traceable.
| Component | Kaspa Integration |
|---|---|
| Node-Registry | X25519 PubKey in Kaspa OP_RETURN Tx |
| Node-Reputation | KAS deposit as stake (Sybil protection) |
| Node-Payment | KAS micropayment per forwarded message |
| Node-Selection | Client randomly selects 2 nodes from registry |
Phase 2 — 2-Hop Onion Routing (Pro Tier)
ONION ROUTING FLOW (2-Hop):
Layer 3 (outer): Enc(PubKey_Node_A)[Enc(PubKey_Node_B)[Enc(PubKey_Bob)[Message]]]
Alice --encrypt(A,B,Bob)--> Node_A
Node_A removes outer layer. Knows: Alice sends to Node_B. Does NOT know: Bob.
Node_A ----------------------> Node_B
Node_B removes second layer. Knows: Node_A has something for Bob. Does NOT know: Alice.
Node_B ----------------------> Bob
Bob decrypts. Knows: Message is from Alice. Cannot trace which nodes.
Phase 3 (Q4 2026) — Advanced Privacy
- → 3-hop Onion Routing for Elite tier (maximum anonymity)
- → Cover Traffic: dummy packets at regular intervals against traffic analysis
- → Pluggable Transports: obfs4/Snowflake for users in censored regions
Crypto Stack Compatibility
The entire SecureChat crypto stack is transport-agnostic. XChaCha20-Poly1305, X25519, Double Ratchet work identically over Tor, direct P2P, or internal onion routing. No changes to the crypto core required.
Long-Term: Nym Mixnet (2027+)
Nym provides timing obfuscation beyond Tor — packets are delayed and mixed with dummy traffic. Currently too immature for Android production. Monitoring recommended. Roadmap candidate for 2027+.