Well said

Primal?

For one, we have relays, they have pubkeys, and yet, we still rely on the certificate chain. In a better world, relay lists should contain the relay host (or better, its IP) AND its pubkey, and those pubkeys should be directly used in diffie-hellmann key exchange when initializing secure connection. The problem with this approach is that there is - to my knowledge - no technology embedded in browsers by default that achieves it effectively.

The first time I sent a note from nostrudel running on local host totally blew my mind.

These are not just clients, they are tools like a metrics dashboard, search engine, and remote signer. But yes, there needs to be a way to access these tools that doesn’t depend on DNS and hosting providers.

I have posted notes directly from the CLI and it feels like a superpower.

This is the way @fiatjaf

nsec.app shouldn't require any servers, it runs in your browser. Or at least that's what I was told.

Biggest issue there imo is secp256k1. It's just not a curve you can easily do this kind of core infra stuff with. It's not supported by passkeys (webauthn), it's not supported by SubtleCrypto, it's not supported by the secure enclaves of iOS or Android devices, you can't use a secp256k1-based certificate to sign a tls 1.3 handshake, then there's JWTs, JOSE, list goes on. It's just absent from a ton of web standards. mainly because it isn't NIST-stamped, so it's sidelined most places by secp256r1. Basically if the goal from the start is to replace the certificate chain and all the rest, secp256k1 is definitely not what you'd choose.

Are all these things because of secp256k1 or because these guys who made these things decided to not support it?

I guess @brugeman runs both of these domains, which would explain why they’re down at the same time. I haven’t found the repo for nsec.app yet to try running it locally.

Then run it on a PC and you can access it from the browser of any device in your LAN.

yes, we should go back to http, and make the encryption protocol level :p

Those guys of course. Though you could make a technical argument that something like Ed25519 is a better choice for this kind of use case. Or ML-KEM for interop with Chrome's post quantum hooks. Or this or that. Anyway, we're not talking about reinventing the whole internet based on secp256k1. Right?

They didn't decide not to support it because it's so niche supporting it was never considered in the first place. You coded yourself into a corner, #cointard.

But hey, secp256k1 is "edgy" isn't it? 🤪

Assuming this one has its project files somewhere that is accessible, then it would work without a server, i'm assuming. The presented issue isn't the nostr client itself (i assume, i didn't use it), but rather people's reliance on 'nsec.app', their reliance on that one domain, on that one individual that controls it, to present people with the project that it has. The issue is people's reliance on ICANN-DNS/IANA and CA. With that said, I'm building the solution, and progress so far is DNS issue is handled (no reliance), and CA issue is handled as well (no reliance). IANA is half-handled and ready to be future handled for a future where mesh internet (example: Tollgate) becomes more of a thing. Once this solution is up and running (calling it DNN), I'd imagine people would just grab the hash of a project (like nsec.app), slap it in the address bar and download/use it (or load/use it) from whever it can be grabbed from (someone will make this or me i didn't think too much about this specific process in this parapraph).

on it / already have a DNS solution called DNN =3 (not released yet, but can video-demo / there are one/two clips of it)

There was one guy here I forget who that performed these coding gymnastics to get secp256k1 quasi-working for passkeys/webauthn via the PRF extension and a bitwarden software vault and a bunch of other stuff, and the result I'm guessing was something impressive but that can't really function in the real world given that webauthn mandates that it's up to users to choose how they want to store passkeys, not websites, and users will just choose keychain or whatever they see first.

yup.

Already worked on / working on what you're thinking. On what I've built (still in-dev) resulted in no more reliance on DNS at all, IANA / IP can 'not' be the identity target but rather an NPUB would be, and there's no reliance on CA to co-sign your cert, you self-sign and it's still secure without a need for validity expiration. Here's a short demo:

I wasn't. I was just talking about hosting Nostr clients in a way that is independent from domain names. If your client is just client-side assets these can be hashed and downloaded from many different places, they don't have to come from one canonical URL controlled by one guy.

That part makes sense. But how would you make a nostr metrics client? If I remember right Artur was from a web-crawling background and made is own nostr crawler from scratch. Or you mean just for publishing, like writing daily stats events to the relays?

🔴 Muslims follow all prophets and messengers, peace be upon them ⚠️ God has said in the Quran: { They say, "Be Jews or Christians [so] you will be guided." Say, "Rather, [we follow] the religion of Abraham, inclining toward truth, and he was not of the polytheists."( 2: 135 ) Say, [O believers], "We have believed in Allah and what has been revealed to us and what has been revealed to Abraham and Ishmael and Isaac and Jacob and the Descendants and what was given to Moses and Jesus and what was given to the prophets from their Lord. We make no distinction between any of them, and we are Muslims [in submission] to Him." (2:136)}

those can run - own relay - own app server - use own browser mobile / pc need nothing else - POWER + INTERNET and npub to read/post that simple

nak - can do auto post - schedulineg

Perhaps the old IRC could inspired?

PWA offline support + mirrors The web is still the best distribution platform.

for real though, why not, it's just a message wrapper and solves so many issues

This looks like a good enough solution.

No, the metrics and search stuff are unrelated, these definitely require special servers. But I think the main note was about nsec.app, or maybe I misread. In any case I wasn't talking only about that, that was just one example, my point is valid for many other cases.

Web apps are just as "real nostr clients" as any other app. They all requires servers one way or another, and if a relay doesn't update their certificate, no data will flow, no matter if your app is deployed from a centralized corporate approval system (Play Store/App Store), that can wipe your app off the earth by will, or if your app is downloaded from a git repo or web server to be installable, or if it's retrieved using web technology. There is also a big difference between a client web app and server web app. Any server web app has an online dependency. Any client web app is just like any other native app, just using web tech for rendering.

I wasn't saying that web clients aren't real Nostr clients at all! After all web clients can run locally and be totally independent of any server (except for some server that may have to initially, once, serve their assets, but that doesn't even have to be a single server).

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.