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.
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?
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?
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?
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.
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? 🤪
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:
