search

element-hq / synapse

Synapse: Matrix homeserver written in Python/Twisted.
https://element-hq.github.io/synapse
GNU Affero General Public License v3.0
1.26k stars 156 forks source link

Anonymous Homeservers (Tor/I2P) #7088

Open matrixbot opened 9 months ago

matrixbot commented 9 months ago

This issue has been migrated from #7088.

Intro

Several people in the Matrix community, including myself, would love to see anonymous homeservers. It didn't seem appropriate to use either of the other I2P or Tor threads, since both had some awesome points by awesome people (looking at you @richvdh @cyphar @vsatmydynipnet @ekleog @ara4n). Big thanks to @ara4n for giving this a proofread before I posted!

Why this Tor/I2P thread

It seemed appropriate to start a new thread (and lock) for the following reasons and with the following hopes:

  1. Create a central thread for the discussion of Tor/I2P homeservers and DNS-addressed homeservers that federate to Tor/I2P homeservers, merging the I2P homeserver thread #5455 with the two Tor homeserver threads #5152 and #2111 (as each thread contained at least some useful and non-duplicate information that I have tried to consolidate in this post). Both protocols could theoretically be implemented, but for the sake of anonymous homeservers, we should just pick one.
  2. Come to a community decision about which anonymity network to use for homeservers and for what reasons
  3. Create a roadmap and/or tickets that I and other community members can start working on

Since this is a large post on a new thread that discusses several steps that are dependent on the previous, for the sake of organization it will probably make sense to break this into smaller threads over time, rename threads, and/or move stuff to a wiki or something.

Tor or I2P?

Here is an excellent and pretty unbiased post comparing Tor and I2P from I2P’s website: https://geti2p.net/en/comparison/tor

(Summarized from above link):

Benefits of Tor over I2P

Benefits of I2P over Tor

I am no expert in network protocols and I don't want to provide an ill-equip opinion, but it seems that Tor HSs would be easier to implement, while I2P HSs appear more 'proper'.

UX and Federation Behavior

I thought it would be useful to include expected behavior in this discussion. This and everything below this will be split into a separate thread with more details after decision on Tor or I2P.

UX (Client)

In a perfect world, I would think we would want the following behavior to apply (I will use terms 'Tor/I2P HSs' and 'DNS-addressed HSs' to describe homeservers that end in .onion/.i2p and in .com/etc for lack of better terminology):

  1. Tor/I2P HSs and DNS-addressed HSs should be able to participate in the same rooms and federate to each other (I can ping @matthew:matrix.org and @somefella:sdfasdfdfd.i2p/.onion in the same message without having to do anything special).

Behind the scenes (Server)

  1. Having a HS that does not support federating to Tor/I2P HSs should not break anything.
    • How would we handle legacy HSs that don't support specifying a Tor/I2P client? Would adding a bridge to the room solve catching Tor/I2P servers up or would it be cleaner to do a breaking server update during a big release? interesting comment related to this by @OlegGirko on #2528 )
  2. In a perfect world, we would have every HS running a Tor/I2P client, providing native federation to all HS types. I don't think this should be a requirement as this will probably induce non-insignificant overhead, but we should include a server config entry to just specify an external relay (ie IP/port of a Tor SOCKS5 proxy). Maybe include native Tor/I2P client in the stable Dendrite release? Food for thought, I'm just dreaming here.
  3. Tor/I2P HSs would have to route all their requests through Tor/I2P while DNS-addressed HSs would split where they route outgoing packets.

@richvdh in #2111 recognized that for both types of HSs to federate to each other, it may be easiest to propose a change to the Matrix specification (specifically 'raising an MSC in the matrix-doc'). See post for context.

Depending on the expected future support of Synapse and with the building of Dendrite, would it make sense to skip building this for Synapse and just implement this for Dendrite?

Next steps

I hope this post finds the community well and brings some organization to the awesome discussions started around Tor/I2P homeservers. What should we start with? Tor or I2P?

nihilist001 commented 1 month ago

to whoever that wants to work on this : add .onion support for matrix servers to federate as an opt-in feature, no need for i2p (userbase is too small)

i'll pay whoever successfully implements this in matrix and merges it with 5 Monero (XMR) (meaning 750 euros)

take the usecase where i have a matrix server at home, at whateverlink.onion with port 8448 ONLY accessible over the onion link through tor alone, and with just that it needs to be able to federate to other servers, and over tor.

exactly what was described above :

Tor/I2P HSs and DNS-addressed HSs should be able to participate in the same rooms and federate to each other 
(I can ping @matthew:matrix.org and @somefella:sdfasdfdfd.onion in the same message without having to do anything special).

Point is, i shouldnt have to pay for a VPS, and a domain with port 8448 forwarded, to be able to federate somewhere. (maybe add a server setting somewhere to prevent abuse, fine by me if that's the concern)

nihilist001 commented 1 month ago

detailing the idea a little further, by default your matrix synapse server doesn't come equipped with the capability to access a potential matrix server through tor.

So you would need a server setting mentionning the SOCKS5 proxy (by default 127.0.0.1:9050 for tor connections), and for the onion nodes, they'd need to access the clearnet nodes through tor (meaning through the socks proxy)

"socks-proxy":"127.0.0.1:9050" (empty by default)
"access-clearnet-peers-through-socks-proxy" set to false by default

There, to prevent abuse on the clearnet matrix servers, i guess you would have the 2 following settings:

"allow-onion-peers" set to false by default, 
"allow-clearnet-peers" set to true by default.

So you would have the following ecosystems: image

1) the clearnet ecosystem of nodes federating with each other

requirement per clearnet node : -1 public ip -port 8448 forwarded, -a clearnet domain

"allow-onion-peers":false
"allow-clearnet-peers":true

2) the clearnet w/ optional onion ecosystem:

requirement per clearnet node: -1 public ip -port 8448 forwarded, -a clearnet domain -and the opt-in setting to allow onion federation, with the mentionned SOCKS Proxy port 127.0.0.1:9050

"socks-proxy":"127.0.0.1:9050"
"access-clearnet-peers-through-socks-proxy":false
"allow-onion-peers":true
"allow-clearnet-peers":true

requirement per onion node : -1 server (can be self-hosted), no need for any port forward nor any public IP -needs tor service running locally, -a .onion domain that can access the local port 8448 -the setting saying they want to access clearnet nodes through the local socksproxy 127.0.0.1:9050

"socks-proxy":"127.0.0.1:9050"
"access-clearnet-peers-through-socks-proxy":true
"allow-onion-peers":true
"allow-clearnet-peers":true

and to federate to the clearnet, it would require a clearnet node to also have access to a tor socks proxy, and to have enabled the setting that they allow federation from onion nodes (opt-in due to the abuse potential of course)

3) purely onion ecosystem (no clearnet at all)

requirement per onion node : -1 server (can be self-hosted), no need for any port forward nor any public IP -needs tor service running locally, -a .onion domain that can access the local port 8448

"socks-proxy":"127.0.0.1:9050"
"allow-onion-peers":true
"allow-clearnet-peers":false

and the nodes would federate with each other, no clearnet needed at all, just matrix servers with tor connectivity.

nihilist001 commented 1 month ago

moving it to https://github.com/matrix-org/matrix-spec/issues/1277 as the issue is with the matrix protocol itself apparently