Federated .onion Services: Building Distributed Dark Web Networks

Federation in the context of .onion services means: multiple independent servers, each with its own .onion address, exchanging messages directly with each other over Tor circuits. Unlike a client-server model (one server, many clients), federation is a server-to-server (s2s) communication model. Requirements for .onion federation: each server must be able to make outbound Tor connections to other servers' .onion addresses, and each server must accept inbound connections from other servers through its hidden service introduction points. The critical configuration: the federating server must route its outbound s2s connections through Tor's SOCKS proxy so that when server A connects to server B's .onion address, the connection routes through Tor rather than trying to resolve the .onion address on the clearnet DNS.

Prosody supports s2s federation with other XMPP servers. For .onion-to-.onion federation: both servers must have mod_s2s enabled and the mod_onions community module installed (available from prosody-modules.hg.prosody.im). mod_onions enables Prosody to resolve and connect to .onion XMPP servers without DNS. Configuration: in prosody.cfg.lua, add plugin_paths = {'/path/to/prosody-modules'}, modules_enabled = {'s2s', 'onions'}. The mod_onions module routes s2s connections to .onion addresses through Tor's SOCKS proxy (configured with tor_socks_host and tor_socks_port settings). Test federation: register accounts on two separate .onion Prosody instances, send a message from user@server1.onion to user@server2.onion, and verify delivery. Federation enables messages to travel between servers without any clearnet exposure.

Matrix Synapse handles federation through its federation client, which makes HTTP requests to remote homeservers. For .onion federation: configure Synapse's federation client to use Tor as a proxy. In homeserver.yaml: federation_client_minimum_tls_version: '1'. For outgoing connections through Tor, use the proxied_requests_blacklist/whitelist configuration or environment-level proxy settings (HTTP_PROXY=socks5://127.0.0.1:9050). Synapse federation uses the .well-known/matrix/server endpoint or _matrix._tcp SRV DNS records for server discovery. For .onion servers, direct IP (actually .onion) addressing is required since DNS-based discovery cannot work for .onion addresses. Use Synapse's destination configuration to override discovery for specific .onion server addresses. Test: create rooms on both instances and invite users across the federation link.

Mastodon and other ActivityPub implementations (Pleroma, Misskey) support federation via ActivityPub protocol over HTTP. For .onion-to-.onion federation: configure the HTTP client to use Tor for outbound federation requests. In Mastodon's environment.production: add http_proxy=socks5://127.0.0.1:9050 to route ActivityPub federation through Tor. Mastodon uses WebFinger for account discovery (@user@server) which relies on HTTP requests to /.well-known/webfinger. For .onion servers, WebFinger must work at the .onion address. Configure RAILS_ENV=production and MASTODON_SERVER_NAME to the .onion address. Note: Mastodon federation with clearnet servers from a .onion instance routes clearnet HTTP through Tor exit relays - the clearnet server sees a Tor exit IP, not the .onion address. This hides the .onion server's clearnet IP but may trigger Tor-blocking on some clearnet servers.

A federated .onion network is only as resilient as its failure handling. Test scenarios and mitigation strategies: (1) Node failure: when one federation member goes offline, messages destined for that server queue and are retried. Configure federation queue timeout (how long to retry before delivery failure). For XMPP: mod_s2s has configurable connection timeout. For Matrix: federation backoff is configurable. (2) Partition: if two groups of nodes can only reach each other through a third node and that node fails, the groups are partitioned. Design federation topology with redundant pathways. (3) Sybil federation member: a malicious node joining the federation to monitor messages. Use federation whitelist configuration (only allow federation with trusted servers) for high-security federated networks. (4) Certificate/key rotation: when a node changes its .onion key (address changes), all federated partners must update their connection targets. Establish a procedure for coordinating address changes across the federation.