I built something similar if you’re interested in checking it out.

GitHub

GitHub - btcjt/titan: A native nsite:// browser for the Nostr web. Named after Titan, moon of Saturn.

A native nsite:// browser for the Nostr web. Named after Titan, moon of Saturn. - btcjt/titan

Browsers are just spyware with a facade, perpetuated by the likes of Gates and Bezos.

Didn't even know about it until you mentioned it.

My agent's analysis. FYI, I was previously calling this "reckless browser" Tauri Evaluation: Rejected — does not fit the reckless browser I evaluated Tauri against the reckless browser's requirements and documented the findings in a new "Considered and rejected" section in plans/options.md. What Tauri is A framework for building desktop apps with a web frontend (HTML/CSS/JS in the system webview) and a Rust backend, communicating via Tauri's IPC layer. On Linux it uses WebKitGTK under the hood via the wry crate. Why it doesn't fit (fundamental mismatches, not fixable) Language mismatch — Rust vs. C99. The entire architecture is C99: the host, the didactyl integration (C, in-process), and the n_signer integration (C API via nostr_core_lib, direct link). Tauri forces a Rust host, requiring FFI shims at every integration point for zero benefit. Security model is the opposite of what we need. Tauri is designed to be secure — CSP enforcement, IPC isolation, capability-scoped commands. The reckless browser's premise is stripping web security (CORS, same-origin, TLS cert enforcement, cookie sandboxing). Tauri doesn't expose the low-level WebKitGTK settings needed to do this. Tauri abstracts away the exact APIs the project depends on. The POC and plans require direct access to webkit_web_context_register_uri_scheme() (FIPS routing), WebKitUserContentManager + JSC (window.nostr injection), webkit_web_context_allow_tls_certificate_for_host() (cert stripping), shared WebKitWebContext (cross-origin identity), and webkit_web_view_load_html() (the browser_render agent tool). Tauri's wry crate hides these — you'd have to fork/patch wry, at which point you're just using WebKitGTK with extra steps. Tauri builds apps, not browsers. In Tauri, the webview renders your app's bundled frontend. In the reckless browser, the webview loads arbitrary URLs from the internet — it is the browser content area. Agent architecture is incompatible. The didactyl integration requires multiple webviews managed directly by the C host, window.agent.tools.* injected as native C functions, and browser_render loading agent-authored HTML/JS into named windows. Tauri's model (one webview, Rust backend, IPC commands) has no concept of this. The POC already proved the right path. WebKitGTK + C99: 17 KB binary, 130 lines of C, real site loaded in under an hour. Tauri would add a Rust framework layer on top of the same WebKitGTK, removing control and adding complexity. Bottom line Tauri is the wrong tool — it's a framework for building secure desktop apps with web frontends, not a framework for building a browser that strips security and needs low-level webview control. If a Rust host were ever desired, Servo (Option C) is the purpose-built alternative. Tauri is neither a browser engine nor a C99-friendly embedding path. The decision to use WebKitGTK + C99 (Path A) stands.