this post was submitted on 14 Dec 2025
18 points (95.0% liked)

Privacy

7851 readers
88 users here now

A community for Lemmy users interested in privacy

Rules:

  1. Be civil
  2. No spam posting
  3. Keep posts on-topic
  4. No trolling

founded 2 years ago
MODERATORS
 

cross-posted from: https://lemmy.wtf/post/34083286

Given the US recently made a bid to fast-track multiple censorship bills, KOSA included, and is also trying to kill Section 230 now, which will pose an existential threat to Fediverse instances hosted over the clearnet, how feasible would it be to host said instances over Tor/I2P?

you are viewing a single comment's thread
view the rest of the comments
[–] Yuzuki@lemmy.kikuri.moe 1 points 1 day ago

Coming from someone who is in fact hosting fediverse instances over Tor, I can tell you right off the bat that it is challenging. Most fediverse software is not created with privacy in my mind — including Matrix which features E2EE for certain rooms and DMs. Here is a breakdown of my experience with individual tools:

Matrix: While Matrix can technically work over Tor, you will have significant challenges with using desktop clients to connect to the server and getting federation working properly. Even if you have both a clearnet domain and hidden service, desktop clients like Element, Fluffy, and Cinny are unable to resolve hidden services. Despite the connection technically working via the utilization of torsocks, the DNS resolution is a problem. For this reason, the primary way of accessing a Matrix server hosted as a hidden service is via a web client. If you do choose to use a web client via the Tor Browser, you must enable dom.ServiceWorkers.enabled for media to play on instances with authenticated media enabled and javascript.options.wasm for E2EE. The latter is enabled by default since one of the latest releases of the Tor Browser. I also suggest enabling SVG support in about:config by setting svg.disabled to false.

Similar to the DNS resolution issue with desktop clients, there is a similar problem with federation. However, one way you can attempt to get both working, is by installing iptables and using nat rules to route all traffic through Tor and use the tor DNS resolver. You can use an existing set of iptables rules published on the Arch Linux wiki: https://wiki.archlinux.org/title/Tor#Transparent_Torification

You also won't be able to federate with clearnet instances, if your instance uses a hidden service as its primary domain (i.e. @user:kxnsyyr[...].onion]. I remember someone who got it working to a certain extend, but fundamentally you are on your own, if you wish to get federation working with both clearnet and hidden service instances. I also urge you to verify whether there are any IP leaks. Last year I discovered Matrix Synapse was making direct connections to other instances completely bypassing Cloudflare and reverse proxies. I noticed this as after attempting to whitelist a specific instance that was behind Cloudflare. After whitelisting Cloudflare's IP ranges, it simply would not work. When I was checking my logs, I noticed not connections. After that, I went into my Element Web client and typed in the designated instance. Once I did, I noticed an IP address in the logs that wasn't a Cloudflare IP address. After whitelisting it, the connection worked. I haven't tested this is in a while, but this was certainly the case last year when I was playing around with Matrix Synapse.

Lemmy: My instance is hosted on the clearnet with a separate hidden service front-end. While I haven't upgraded Lemmy in a while, the hidden service client nonetheless pulls external images, such as avatars, via the clearnet. Running on version 0.19.5, not all images are yet being proxied and — as a result — you will make some connections over Tor to the clearnet. This is a common issue. In the case of Matrix, if your instance is hosted on a clearnet instance, but features a separate hidden service proxy, some elements may still be pulled in via the clearnet over the hidden service client.

Mitra: This is the only client that I know of, which is built for the darknet. It is a project developed by silverpill and features integrated Tor and i2p support. It enables you to federate with both clearnet and darknet instances rather than just one or the other. It is relatively minimal compared to Mastodon or Pleroma, however it does have some significant privacy benefits. Meanwhile, I have experienced issues with the likes of Pleroma and Akkoma. For example, my main instance was hosted on the clearnet, but featured a hidden service version. Unfortunately, by default, all images were still being loaded through external calls to other instances on the client side. So while you are accessing an onion address, you will still make clearnet connections to fetch media content from other instances and thereby leak the exit node to them. An alternative is use the media proxy and proxy all content through the server. However, you are only able to define one media proxy address. So if you would like to have both a clearnet and darknet front-end, you will have to select a clearnet domain for the media proxy. A workaround requires manual editing of the front-end to change the media proxy from clearnet to darknet when a user is accessing the darknet front-end.

Long story short, you will have a steep uphill climb ahead of you, if you would like to operate fediverse instances on the darknet. There are many pitfalls and issues since almost none of these instances are built explicitly for the darknet.

For my own platform, I'm developing a custom community forum that is made for the darknet that will integrate with Mitra to pull in the Mitra feed through the back-end. This will effectively show the Mitra feed in a javascript–free web application and make the fediverse accessible to darknet users. For chat, we are working on configuring an XMPP server with prosody, since prosody has a module enabling federation over Tor. At this time, XMPP is a much more viable option for the darknet than Matrix, which is especially the case as you can run it via a desktop client over Tor. While I do host a SimpleX relay, I'm not fond of SimpleX due to the glitchy UI, the VC funding, and the direction of the project as a whole. It also lacks significant moderation features, which are paramount for running a stable community. For now, we have both a SimpleX relay and a Matrix instance, but will switch to XMPP soon until something better comes along.

The only issue I have with XMPP relates to the registration. You can enable or disable registration. Technically, prosody does have mod_invites_register, which generates invitation tokens that are similar to Matrix Synapse's registration token. Unfortunately, not a single client has implemented XEP-0379 to my knowledge rendering this feature effectively useless. If you would like to have a separate invitation form, I suggest creating a simple web application with a dedicated form and a simple database that allows you to approve / reject applicants.

Lastly, I also want to emphasize that open–source does not automatically mean free and open–source — that is free as in freedom as in libre. There is a rise in open–source software, yet little of it feels actually free. As for hosting anything on the darknet, compared to the clearnet, anything on the darknet takes 10 times the time, requires 10 times the resources, costs 10 times as much, and gives 10 times the headaches.

Best of luck!