Nuh 🔻 on Nostr: I thought you supported key delegation, do you think signing a delegation to a key ...

I thought you supported key delegation, do you think signing a delegation to a key held by the server is some kind of a sin now?

And no, that is not the current trust model, the current trust model is : ICANN won't take your digital identity.

If we solve that (granted by publishing signed announcements) then we actually solve the vendor lock-in and deplatforming.

Now some applications can't tolerate any delegation of trust for sure and for these apps, I absolutely support complex stuff like e2ee messaging where you can't share keys with your server.

But saying that nothing can work with delegation at all is not honest, if people are OK with using custodial LN, it would be insane to say that trusting a hosting provider to not modify your shitpost or that that would be unacceptable risk.

Finally if you don't accept delegation at all, then you are forcing users to a maximalist trust model that they don't want, and forcing them to deal with the risk of losing their keys for that choice you are forcing on them.

If you do accept delegation then we can argue whether it is safer and more convenient to trust the server with the sub keys or should we only trust clients in our hands, as if these can't be compromised and users get sloppy with.

If you accept delegation, and you accept that being able to fire misbehaving holders of keys, then we are arguing details like whether servers should be trusted to delegate some temporary trust to, or you should limit that to machines you own.

Either way, the moment you accept delegation, it is not up to you, users will do both.

So again, the choice is either key delegation is acceptable or not, once you accept it, then we can discuss why when and where should data still be signed at all, and when it doesn't matter much.

But long story short, if I already delegated signing to an nsecbunker, and that server is the same as my Outbox relay, then people reading from that relay directly don't actually need to verify anything, other than that this relay is still the outbox and is still trusted, verifying signatures would be entirely superfluous and redundant since you already have TLS for MITM prevention.

You can argue then, that we need signed data so that clients don't have to trust intermediary relays, and that is true especially if your client doesn't implicitly trust a hard-coded relay.

if you run your own relay and you trust it, or trust a friend's relay, or simply trust the client so you are OK with trusting the hard-coded relay in it ( because clients can fake things too) then you don't need to verify anything either.

you trust the client, the client trusts the relay and the relay connected directly to the "outbox" relays crawling data . not much need for signed data.

So the actual place where you need signed data, is when you need to gossip events with people you don't trust much beyond not spamming you, basically Torrent/Bitcoin/Git like situations. And for that, you should absolutely use signed roots of the merkle trees of users data, but notice that even then, you are better off still delegating that work to the server so it can offer more features like strong consistency.

You can always sign data on client side when appropriate, nothing prevents you from hosting signed events on a web server, but the argument is, when that is not needed/overkill/ or worse prevents good sustainable key management, then it shouldn't be the default.

I hope you can see the value of fixing DNS with Pkarr, even if we still commit the sin of not signing all blobs including car pics with the root key risking losing it


Anyway, always nice to argue this stuff, enjoy your day.