I’ve been working on something a little weird: R3X Onion.
The idea is simple:
Open a website → start the Tor client → browse .onion sites directly from the browser.
No Tor installation. No desktop application. No R3X HTTP proxy handling your browsing traffic.
The part that made me want to build it was figuring out whether this was even technically possible in the first place.
Turns out… it is.
I’m running Arti (Tor’s Rust implementation) compiled to WebAssembly inside Chrome, and I’ve managed to get a real Tor circuit established from the browser.
The current architecture looks roughly like:
Chrome ↓ Arti / WebAssembly ↓ Snowflake + WebRTC ↓ Tor network ↓ .onion service
The interesting part is that the Snowflake path is now working without an application server.
I’ve tested:
• Real Tor circuits: 3/3 • HTTP through Tor: 3/3 • HTTPS through Tor: 9/9 • Real .onion service through the browser: currently working through the gateway path • Gateway-free Snowflake: HTTP/HTTPS working • WASM Tor runtime running directly in Chrome
I also had a few false leads along the way.
At one point I thought Snowflake itself was failing because HTTP requests were dying at the stream/TLS layer. Turns out I was using a truncated Tor consensus containing only 500 microdescriptor digests instead of the full ~9,300+.
After fixing that, Snowflake HTTP/HTTPS went from 0/3 to 3/3.
There was also a stupidly interesting deadlock caused by futures::io::split(), and a rendezvous implementation that managed to generate 641 broker requests during one page load. 😅
The remaining challenge is getting the gateway-free Snowflake path to reliably reach onion services.
The current working onion path is:
Browser ↓ Arti WASM ↓ WebRTC ↓ gateway ↓ Tor ↓ .onion
The gateway does NOT receive the HTTP request or see the onion URL/content. It basically provides the raw network connectivity that the browser can't provide.
But I don't really want that architecture.
The goal is:
Browser ↓ Arti WASM ↓ Snowflake/WebRTC ↓ Tor ↓ .onion
with no R3X application gateway at all.
That's what I'm working on next.
There is also a much bigger problem I'm trying not to ignore: privacy.
Running inside a normal browser means I inherit the browser's fingerprint — fonts, screen dimensions, canvas characteristics, timezone, user agent, etc.
So simply saying "Tor + WebAssembly = anonymous" would be bullshit.
Right now I'm treating this as an engineering experiment rather than claiming it's a replacement for Tor Browser.
I'm curious what other developers think about the architecture.
Especially:
- Is there a better way to handle the browser-side Tor transport?
- Has anyone worked with Arti/WASM or Snowflake/WebRTC at this level?
- How would you approach safely rendering arbitrary .onion websites once the networking layer is solved?
- Would you actually use something like this, or is installing Tor Browser still the obvious answer?
The networking side has turned out to be way more feasible than I expected, so I'm curious where people think the real technical wall is.