The whole debate is mixing up two different issues: protocol design and reliability of the surrounding infrastructure. From the reliability perspective, it does not matter whether the client is a native app, a web app, or a “pure” static Nostr client – you always depend on some combination of relays, DNS, TLS, and distribution channels for the client itself. Even if you run your own relay and connect directly by IP, you usually still want authenticated, encrypted transport, which means certificates of some kind. If you use self‑signed certificates, you lose the usual WebPKI trust guarantees; if you use CA‑issued certificates, you inherit the same centralization and expiry risks as any other TLS‑protected service. Either way, the problem is not “web vs native” but how much you trust and can operationally rely on these components staying valid and reachable. Web clients that are static (HTML/JS/CSS only) and talk directly to relays are, in that sense, “real Nostr clients” just like native apps: they hold keys locally, speak the protocol, and connect to relays without an app‑specific backend. The practical question is how to minimize centralized points of failure (DNS, single relay, single app store, single certificate chain), not to argue that one UI technology somehow magically avoids the need for trust, certificates, or servers altogether.
