as a dev and nostr user, here’s my elevator pitch:
everything is an event. events are signed using pki so it’s easy to know who sent the event and it’s authentic. they’re human readable json objects. events flow over websockets so it’s “real time”. you can build literally anything on this platform - listen for a type of event, do something, emit another. it can all interoperable. we started with basic twitter clones but are rapidly moving into uncharted territory - people are building music distribution apps, ai agents, and so on. and the entire ecosystem has native, programmatic payments built on bitcoin’s lightning network.
> events are signed using pki so it’s easy to know who sent the event and it’s authentic.
what problem does this solve? how many people are publishing events (tweets) that are inauthentic? you need to be logged in via password + 2fa on twitter to post. if somebody can post from your twitter account on your behalf, they are logged in as you. i don't see how "PKI" on top fixes that?
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.
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.
> 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.
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.
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/jack@strike.me is trustable, because it serves his public key here: https://strike.me/.well-known/nostr.json
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.
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.
I love the programmatic payments. what's the key rollover story? social key recovery? IMO these are table stakes for PKI to reach the general public. There's a technology called KERI (key event receipt infrastructure) that I'm bullish on, has to do with signing new keys with the old, with witnesses, with configurable threshold cryptography (m-of-n key reconstruction)
my favorite part about that last one is the possibility of social key revocation - if you're in a community misbehaving, the same people you trust to save key fragments in case you lose your private key can conspire against you to lock you out of your account, a kind of cryptographic ban hammer.
> listen for a type of event, do something, emit another.
If everything is an event, and you can send any types of events, then you can trivially saturate the network, the clients, and the relays with bogus events.
> but are rapidly moving into uncharted territory - people are building music distribution apps, ai agents, and so on.
None of this is uncharted territory. Uncharted for Nostr, maybe. But time and again anything that comes out of crypto shows that people building this stuff have literally zero knowledge of what has been there in the real world before them.
Yes, including "we send events, and listen to them". Kafka alone is 12 years old this year.
> If everything is an event, and you can send any types of events, then you can trivially saturate the network, the clients, and the relays with bogus events.
I agree this is a problem. However, there is at least one protocol addition (that doesn't involve cryptocurrency per se, although it shares some ideas) that tries to address this: proof-of-work requirements.
The idea is basically this: message IDs are SHA256 hashes of message contents. If you add a nonce to the message metadata, then each time you change the nonce, you'll get a different SHA256. Relays can then choose to ignore messages without a particular number of leading zeroes in the event ID. This means a client will have to do a non-trivial amount of computation to generate an event ID that a particular relay will accept.
> None of this is uncharted territory. Uncharted for Nostr, maybe. But time and again anything that comes out of crypto shows that people building this stuff have literally zero knowledge of what has been there in the real world before them.
I mean, I think it's a direction for social media that hasn't been tried yet on a wide scale. Personally, I look at it as a cool idea- I don't know if it'll actually pan out in the long run, but I think it addresses a bunch of problems with both centralized and federated social media, so it's worth seeing what can be done.
I don't think there's a trivial amount of computation people would want to perform that would cost too much for bots to advertise. I don't think people would be willing to wait 20 minutes on their phone to post a comment on a website. Assuming it's SHA256 like Bitcoin, from this video [1] a Samsung S22 Ultra does 400Kh/s. On a 6700 XT, the hashrate is 24 MH/s, that is like 50 times faster, or 24 seconds per post. If they use an ASIC it shoots up to the TH level. That's milliseconds. The service would need to be unusable on a phone unless people leased servers to validate their posts on, leading to costs for each post.
Hmm. I hadn't considered that. In my defense, I'm actually not a crypto guy at all, and so I hadn't given much thought to the actual dynamics. And now that I think about it, I don't think I've seen many relays actually implement that particular protocol extension, and this is probably why.
On the other hand, I think it's reasonable to note that individual relays could very well change their proof-of-work requirement over time to deal with network conditions. Because clients are expected to send events to as many relays as possible, it's not unreasonable to suppose that a client's message might very well make it through _somewhere_, even if a particular relay won't accept their message at a particular moment. Clients can always try again later.
I think it's also worth treating PoW as part of a "swiss cheese model" for managing abuse. There are layers in front of it (since the protocol uses WebSockets, all your standard DDOS protections can sit in front) as well as behind it (blacklisting or throttling pubkeys you don't know very well.)
One example that comes to mind is another protocol extension which provides a mechanism for client authentication, where a server can send a challenge string, in which case the client is expected to respond with a special event type which includes that same challenge string. Requiring a much higher proof-of-work requirement for this message type (and then accepting a lower PoW for messages sent afterwards on the same connection) is at least one idea of a scheme for mitigating spam.
---
For what it's worth, I wouldn't say I'm a True Believer at this stage of the game, but I find the whole thing pretty compelling, and at the very least it's something fun to hack on and experiment with.
> I think it's a direction for social media that hasn't been tried yet on a wide scale.
What direction? Building music distribution and ai agents? Or building a social network that literally relies on trusted servers (that you're even expected to pay for) to function?
The network is a collection of relays and relays are free to permit - or reject - what they want. You can’t saturate a protocol. You can saturate a given relay (server).
It’s uncharted in the protocol. The protocol has nothing to with crypto other than 1) it depends on cryptography and 2) there is an event type that cares about bitcoin lightning payment receipts.
You are implying there is a singular network. There are a collection of relays on the internet. Each relay has it’s own business rules and may or may not accept your events. Each client may support some type of events.
Explain to me how you trivially saturate this protocol. That’s like saying you can trivially saturate TCP/IP by broadcasting packets.
IIUC, the nostr communication protocol stands on its own, which should allow you to “bring your own payments” to the mix, or even engage without hooking up any payments till you see a compelling need?
From a theoretical standpoint, this answer could get very long, but the real answer boils down to the creator of the protocol prefers bitcoin.
On the theoretical side, I'd argue that bitcoin PoW is the best choice because it is more resistant to malicious actors. Assuming that a solution to the botting issue requires a small proof-of-work or fee to post, on a PoW chain malicious actors would need to control a large amount of energy inflow and hash power to support their botting operation. Whereas on a PoS chain, they simply needs a large pool of capital to be staked, which would give returns that can support their operation. This means that the attack vector is larger on a PoS chain than a PoW chain. This is also why the nostr protocol itself has a proof-of-work component. It's the simplest solution to two-generals problem.
Proof of work also depends on capital, compute isn't free. In fact, it is already incredibly centralized in the Bitcoin blockchain because there's like 3 big players which have already attacked the Bitcoin Cash blockchain. The only reason these huge pools haven't attacked the Bitcoin blockchain is because they have a financial stake on the price being high, which is also the same incentive proof of stake depends on.
Ethereum’s recent move to Proof of Stake undermines the their ability to be decentralized and permission-less. If a validator adds a blacklisted transaction, they will be slashed [0].
Ethereum had an unfair issuance. That means the founders kept a pool of coins for themselves and have unfair control of the network, furthered by PoS.
Ethereum is effectively a private tech company led by a CEO. They have a public roadmap.
Ultimately I think these fundamental properties of Ethereum make it inadequate as a permission-less money protocol. It works great for games and apps, but its foundations are susceptible to coercion and control - and you can’t build a permission-less protocol on that foundation.
No, your link shows that a majority of validators will not include certain transactions in a block. While problematic in itself, there is nothing around slashing other validators who do so, on their allotted blocks.
Technically you can still obtain 32 ETH on the market, permissionlessly set up your own beacon-, validator- and execution clients and wait until it's your go to send out txes.
I think someone did some monero focused client and relay implementation. Go on and create your own nostr eth implementation. Maybe even try to submit a NIP for this.
everything is an event. events are signed using pki so it’s easy to know who sent the event and it’s authentic. they’re human readable json objects. events flow over websockets so it’s “real time”. you can build literally anything on this platform - listen for a type of event, do something, emit another. it can all interoperable. we started with basic twitter clones but are rapidly moving into uncharted territory - people are building music distribution apps, ai agents, and so on. and the entire ecosystem has native, programmatic payments built on bitcoin’s lightning network.