- Added new dependencies: `adler2`, `crc32fast`, `flate2`, `miniz_oxide`, and `libredox`. - Updated existing dependencies: `tokio-rustls` to version 0.26.4 and `filetime` to version 0.2.27. - Removed the `backup.rs` file as it is no longer needed. - Introduced tests for configuration and credential management. - Enhanced the `identity` module to generate W3C compliant DID documents. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1.6 KiB
1.6 KiB
ADR-004: Tor Hidden Services for Peer Communication
Status: Accepted Date: 2026-03
Context
Federated nodes need to communicate directly for state sync, app deployment, and peer verification. Options: direct IP, VPN tunnel, Tor hidden services, I2P.
Decision
Use Tor hidden services (.onion addresses) for all inter-node communication.
Consequences
Positive
- NAT traversal: Works behind any firewall or NAT without port forwarding
- IP privacy: Nodes never expose their real IP addresses to each other
- End-to-end encryption: Tor provides encryption without additional TLS setup
- Censorship resistance: Onion routing makes traffic analysis difficult
- Stable addressing: .onion addresses persist across IP changes and network migrations
- No central infrastructure: No VPN server, STUN/TURN server, or relay needed
Negative
- Latency: Tor adds 200-500ms per hop; 3 hops per direction = noticeable delay
- Bandwidth: Tor network has limited bandwidth; not suitable for bulk data transfer
- Reliability: Tor circuits can break; connections may need retry logic
- Setup complexity: Requires running a Tor daemon (
archy-torcontainer) - Blocked networks: Some networks block Tor; bridges can help but add complexity
Mitigation
- Use Tor only for RPC/control plane; bulk data (container images) pulled from registries
- Implement retry with backoff for Tor connections
- Container
archy-torruns automatically with host networking for hidden service access - Federation sync interval (5 min) tolerates occasional connection failures