The problem is that network architecture of Nostr is different from Twitter (and from Mastodon, for that matter). One of the core ideas of the Nostr protocol is getting rid of the idea of "logging in" or "creating an account" on any given relay, and as such it needs some way to reliably identify which posts were made by a particular user.

That's where PKI comes into play: it's not layered on top of a login system, it's a complete replacement.

It removes trusting a 3rd party.

I don't get it. Either I validate who I am when I log in to Twitter, or I validate who I am when I set up my "Nostr" identity?

You generate a public/private key pair. When you want to send a message (tweet), you sign it with your private key and broadcast it to relay(s).

The messages contain your pubkey so others know who sent it. Your messages are signed so others know they came from you.

How is trusting a third party to deliver you the authentic public keys isn't "trusting a third party"?

For any signed message, there is only ONE public key that could have generated that signature. You either know that key, or you don't. The network can either deliver or help you discover the key, or not. That's way different from trusting a third party to not lie to you about authenticity or the source of the message.

How does that work in the context of the whole system where I need to link a key pair to a person? If I know you in real life we can check key fingerprints or something (GPG suggests statistically nobody will) but otherwise I have to trust a third-party who says that the Bob I want to talk to has keys X, Y, and Z.

If you don’t do that, as soon as it becomes popular enough to attract scammers you’re going to have Mallory publishing keys with Bob’s name on them and a million random people who have incredible financial opportunities for you. Most of the decentralized systems shift that problem to another system like email or DNS, Facebook/Twitter/GitHub/etc. at which point it’s worth asking whether there’s still value in decentralization at that point.

Nostr is quite open for what options people use to become more trustable. People can pay couple thousand sats to get a verification, or as you say Nostr can also do the same with shifting to web of existing sources of identity. E.g. it is well known that this Jack is CEO of Strike (strike.me) and so any nostr client can verify that https://snort.social/p/[email protected] is trustable, because it serves his public key here: https://strike.me/.well-known/nostr.json

So that’s trust based on the DNS and web PKI systems, not the Nostr protocol.

They are ignoring the problem of how do you know the other person's public key. And you don't. That's why people post their public keys on their own websites or on X or whatever - basically, a third-party THEY trust and believe you can trust as well, so yeah, this doesn't remove trust on a third-party as that's impossible.

How is this any different from sending an event from an account you authenticated from (like an e-mail, or a Twitter account)?

It removes trusting a 3rd party.

That's not a value proposition.

The only trust a 3rd party like Twitter demands in your example is that I trust they won't impersonate my account with a message (since there's no private/public key proof)

But your system doesn't address that either. After all, what's stopping _anyone_ from just saying they're me and sending out messages?

Like 99% of decentralized usecases, this still falls down to trying to cheat the oracle problem. I actually trust Facebook and Twitter more in this situation because they can at least demand verification in the real world, they've got enough social capital that they can overcome the oracle problem in limited contexts.

It certainly is for some.

You are correct - it allows consumers to know the message has not been tampered.

The downside of your trust model is permission. Facebook and Twitter may revoke your permission to use “your” identity at any time, for any reason.

Requiring ID verification for a rented online identity is a terrible trend imo. These companies are not to be trusted - they exploit users and inevitably sell your data or get breached.

Your system is so poorly secured there is no value in tampering with the message: I can just say I'm you and tweet.

A tweet is not a direct message, it's a broadcast message.

Without a centralized 3rd party mapping names to public keys, the identity of the sender can be set to whatever you want.

Your model only works for non-tweets where I'm sending to people I had communication with in the past and was able to verify a public key... at which point you're just providing E2E encryption with worse ergonomics and no new value prop.

—

You cannot cheat the oracle problem. There is no magic bullet that lets you broadcast messages with known identifies without a centralized 3rd party.

That’s not true. There are methods for proving control of a key, both in the protocol and outside.

- Sharing keys in person

- Sharing keys via other channels like Twitter

- Via DNS using NIP-05

> A tweet is not a direct message, it's a broadcast message.

> Without a centralized 3rd party mapping names to public keys

Sharing in person doesn't work for broadcasting

Other channels require falling back to some non-decentralized system.

Again, it's the oracle problem. You can't say it's not true, that's like saying "1+1=2" is not true.

> how many people are publishing events (tweets) that are inauthentic?

Pretty much everyone, because Twitter doesn't provide a way to tell a tweet written by a user from a tweet written by someone that controls/works at Twitter.

IMO it would be mobility. It's true that a logged in account can also offer validation but that identity is kept and stored on the provider's database whom in turn can withdraw consent to use that. There is some mobility on Mastodon but it still requires cooperation from the instance administrator.

On nostr if a relay or even client decides to ban you from posting you can just post from another client to another relay using the same identity.