Thread - Nostr Hypermedia

For the last part, I'd say it's more like this: The server needs a public/private key pair to set up the key exchange for HTTPS. Before DNSSEC+DANE (which no one implements... ugh), there was no secure way to know if a public key of a server is really that server, or a malicious actor in the middle pretending to be them. So, certificate authorities (CA) were created, which try to do secure checking of you owning the domain name before giving you a certificate saying "This public key is trusted for this domain". And your OS vendor trusts a certain set of CAs that they know is good and reliable, but not just anyone, because any trusted CA could spoof any website they want, like google.com. With newer CAs like Let's Encrypt the ownership checking is automated and they check your DNS from multiple random points on the internet to ensure there is no one tampering.

↑ Parent

Replies (2)

mike mike@mikehardcastle.com 1 month ago

I was trying to make it simpler, not more difficult, now you've ruined it again 😂

1 replies ↓

semisol semisol@nostr.land 1 month ago

Or, even simpler, it is similar to this: You want to talk to John Doe on Nostr. The problem is anyone can pretend to be John. So, someone says "I will check your ID that you are John Doe, and I will give you a badge that I checked". Your client implements a list of trusted checkers, and when you search for John Doe, only the verified npub appears. The others get a big scary warning "This may not be John Doe". The client only trusts checkers that adhere to a given standard and have reputation, to prevent bad actors from being able to issue fake badges for anyone. This is how HTTPS works but instead of npubs it is servers' public/private keypairs, and instead of people it is domain names, and badges are certificates

1 replies ↓