OH011 - Freedom Browser

Episode 11

Episode Notes

Recorded June 17, 2026, live from a conference floor.

A wide-ranging conversation about the Freedom Browser — a browser for the decentralized web — covering peer-to-peer content protocols, the problem of trusting RPC providers for ENS resolution, light clients, agentic protocol re-implementation, an integrated Web3 wallet, and HTTP 402 micropayments.

Guests & hosts

  • Meinhard — Freedom Browser
  • Florian — Freedom Browser (gave the on-stage talk that morning)
  • Dirk — co-host, and creator of Myotis, a trustless Ethereum light-client SDK
  • Ksenya - co-host

What's covered

[01:26] Intro. Episode 11, two guests, one topic: the Freedom Browser.

[03:22] What is the Freedom Browser? An access portal that looks and feels like Chrome, Safari or Brave, but speaks extra protocols. It resolves ENS names (e.g. vitalik.eth), reads the content hash they point to, and fetches the content directly over peer-to-peer networks through a local node that auto-starts in the background — "like your browser acquired superpowers" without the pain of running nodes yourself.

[04:09] Supported protocols. Started with IPFS and Swarm, later added Radicle.

[04:33] What is Radicle? Git as a peer-to-peer protocol — effectively a decentralized GitHub. Freedom ships both a Radicle node and an interface that renders the data structures it receives, so you browse something that looks like GitHub but is fully client-side.

[05:13] Pinning vs. seeding. How content persistence differs across IPFS (pinning), Swarm (paid postage), and Radicle (a node "seeds" a repo and serves it whenever online). Notes on discovery reliability and Radicle's growing peer count.

[07:25] The ENS problem. ENS resolution is the least decentralized part of the browser — talking to the registry's smart contracts normally needs a full Ethereum node or a trusted RPC endpoint.

[08:00] RPC poisoning & phishing. How public/compromised JSON-RPC endpoints have been hijacked (including via DNS) to feed clients malicious data and redirect users to phishing sites — sometimes poisoning only specific records. Reference to a recent bridge-related hack where an internal RPC service was compromised.

[10:35] Why verifiable data matters. With Merkle/state proofs, that whole attack surface disappears — a verifying client would simply reject the bad data.

[11:25] Mitigations & their limits. Running a quorum of RPCs (e.g. 2-of-3, 3-of-5) before showing a site, plus caching — better, but slower, and still reliant on intermediaries.

[12:57] Permissionlessness & public RPCs. Free public RPC servers exist but come with no service guarantees: you need a list of ~10 and round-robin logic, you get rate-limited, and there's no economic alignment between providers and users. Mentions of Infura, Alchemy, and dRPC. "Altruism is great, but it doesn't scale."

[16:15] Myotis — a different approach. Dirk's project: a light client that uses sync committees to verify data and the SNAP protocol to pull state from execution-layer clients, then exposes it as a local RPC service. Runs well on a laptop and reasonably on a phone, supports Ethereum and Gnosis Chain, and resolves both standard ENS and CCIP-Read names — with everything verified. (Someone had once claimed a light client couldn't resolve ENS. It can.)

[18:43] CROPS & the speed/decentralization tradeoff. The "C" is censorship resistance — and leaning on a single gateway undercuts it. Roughly 80% of users may pick the instant, trustless-but-switchable-off gateway; the rest wait a little longer for the fully peer-to-peer path via Myotis.

[19:55] Fanning out SNAP requests. Splitting heavy queries across peers, verifying in parallel, and using multicall3 for batched balance lookups (the trick MetaMask uses).

[20:43] The incentive critique. SNAP has no incentive layer — if everyone ran light clients, execution nodes might stop serving state for free. Dirk's three goals: find projects that need Myotis, secure funding, and push the Ethereum Foundation to make this data reliably available if it's serious about its mandate.

[22:30] Beacon-chain quirks. SNAP bootstrapping, missing bootstrap/update calls on some beacon clients, discovery v5 limitations, and blacklisting nodes that don't serve what's needed.

[24:15] Protocol vs. implementation. Whether Myotis is a spec or a single codebase; rewriting BLS signature verification in Rust for speed; the long-term goal of an Android wallet (view history, build and send transactions); and maintenance around hard forks.

[27:42] Back to Freedom's nodes. Why Bee (Swarm) and Kubo (IPFS) are too heavy for phones — discovered at a Budapest hackathon where running both "fried the phone."

[30:10] Rolling their own light clients. Using coding agents to build fresh Rust light clients for Swarm and IPFS, mobile-optimized and production-ready "as of this week." The next Freedom release replaces Bee with their own smaller implementation; the IPFS light node is nicknamed Lumo.

[32:24] Agentic re-implementation. Re-implementing Swarm surfaced years of edge cases (the Swarm creator has worked on it for a decade). LLMs are well suited to translating a protocol between languages and to optimization tasks — they made the IPFS path roughly five times faster — at the risk of occasionally "cutting corners" on the protocol.

[38:18] IPFS, opportunistically. Freedom's IPFS node keeps no persistent peer connections — it grabs content and shuts the connections down. Resource-friendly on mobile, if a little parasitic. Built using a coding agent's long-running "goal" mode as a hill-climbing lab environment (~100 hours of self-improvement).

[40:17] Freedom as a developer platform. Exposing the protocols to web pages via a reserved navigator.freedom / dweb namespace (dweb fetch, push, upload, download, even node control) — each gated behind an explicit permission prompt. A static page can effectively be a dapp.

[44:39] window.swarm. A live, shipped API modeled on EIP-1193 (window.ethereum): a site can ask to publish content to Swarm under your identity, and you approve it like a wallet connection.

[46:14] The integrated wallet. Send/receive assets, add/remove EVM chains, connect to dapps via EIP-1193 (eth_call, getBalance, signing, transactions). One seed phrase derives every identity — Swarm, Radicle, IPFS, and wallet — with a choice of app-scoped, Bee-wallet, or main-Ethereum identity per site.

[49:35] Why Gnosis Chain by default. It's cheap and well-stocked with assets — and Swarm's storage payments (stamps/postage), gas, and the BZZ utility token / xDAI gas token all settle on Gnosis Chain.

[50:46] HTTP 402. Freedom may be the first browser to actually use the long-dormant HTTP 402 "Payment Required" status. A callback to SatoshiPay ~10 years ago — but where that needed heavy JavaScript shimming, this now works through pure HTML, with the browser attaching a payment proof in the request header. Enables things the old approach couldn't, like pay-per-byte range requests for video.

[53:14] x402 & agents. The x402 standard (pushed by Base/Coinbase) lets agents pay for content over HTTP — but Freedom's implementation is aimed at humans, with an "autopay baseline" that feels like subscribing to the whole internet while paying creators frictionlessly under a self-set monthly cap.

[56:22] Do micropayments actually work? The classic objection (mental transaction cost) gets pushback: people do collect bottles and chase discounts. Publishers tend to resist micropayments (subscriptions are stickier), while users like paying for a single article. Micropayments already power gaming, streamer tips, and social platforms.

[58:39] Circles integration. A working-but-unshipped feature lets you pay for Swarm publishing with the daily UBI you earn on Circles (CRC). Imagine a metered internet where your reputation-based basic income covers much of your consumption — and Circles' trust graph doubles as a reputation layer.

[04:01] Original vision & wrap-up. A nod to Brewster Kahle and the Internet Archive's dream of one-download software that makes you both a reader and a node of the decentralized web. Plans for a possible Episode 2 at DWeb Camp (mid-July).

Projects & references

Shoutout & thanks to Recording Station & ZK AV Club people for recording equipment & other visible & invisible infrastructure at Dappcon.

Listen on: