Skip to content

Add SOCKS5/Tor proxy support for relay connections - #51

Merged
TheCryptoDonkey merged 2 commits into
mainfrom
tor-proxy-support
Aug 7, 2026
Merged

Add SOCKS5/Tor proxy support for relay connections#51
TheCryptoDonkey merged 2 commits into
mainfrom
tor-proxy-support

Conversation

@TheCryptoDonkey

Copy link
Copy Markdown
Member

What

All relay connections (reads, publishes, NIP-46 signing, bridge fetches) can now route through a SOCKS5 proxy:

gopherkind read <target> --proxy socks5h://127.0.0.1:9050
export GOPHERKIND_PROXY=socks5h://127.0.0.1:9050   # same, for everything
  • socks5h is enforced (DNS resolves at the proxy), which also makes wss://....onion relay URLs reachable; they are rejected when no proxy is configured.
  • Trusted relays on local addresses (development relays) are still dialled directly, since Tor cannot reach loopback.
  • When a proxy is active the connection-time DNS guard cannot run (the proxy resolves and dials), so untrusted relay URLs from hints/bunkers keep only the hostname-level internal-address check. Documented in SECURITY.md.

Why

Relays learn a reader's IP address alongside every subscription filter. This removes the network-location half of that leak. The read-pattern half is inherent to Nostr and is stated plainly, with mitigations (relay choice, onion relays, onion-service deployment), in the new docs/privacy.md threat model page, which also says clearly what this tool is not: not anonymous, not metadata-resistant, not secret.

Verification

  • New tests: proxy URL validation, onion acceptance only when proxied, internal-address rejection through a proxy. Full suite 327/327, biome + tsc clean.
  • End-to-end: all four default relays observed connecting through a local SOCKS5 forwarder; read succeeds through the proxy; dead proxy yields no data.
  • Also verified end-to-end through a live Tor daemon (--proxy socks5h://127.0.0.1:9050).

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

TheCryptoDonkey and others added 2 commits August 7, 2026 18:20
Readers and bridge operators can route all relay traffic through a SOCKS5
proxy via --proxy or GOPHERKIND_PROXY (socks5h, so DNS and .onion names
resolve at the proxy). Onion relay URLs are accepted only when proxied.
Trusted local development relays are still dialled directly. When proxied,
the socket-time DNS guard cannot run, so untrusted relay URLs keep only the
hostname-level internal-address check; this is documented.

docs/privacy.md states the threat model plainly: gopherkind is a durability
and authorship tool, not a privacy tool. It covers what is public by design,
what relays and bridges can observe, Tor and onion-service mitigations, and
what is out of scope.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@TheCryptoDonkey
TheCryptoDonkey merged commit 937ae34 into main Aug 7, 2026
3 checks passed
@TheCryptoDonkey
TheCryptoDonkey deleted the tor-proxy-support branch August 7, 2026 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant