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 can’t saturate a protocol. You can saturate a given relay (server).

Here's what I said, verbatim: "then you can trivially saturate the network, the clients, and the relays with bogus events."

What are you arguing against?

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.

> Each relay has it’s own business rules and may or may not accept your events. Each client may support some type of events.

Even if they don't accept your events, you can still trivially saturate their bandwidth and processing.

> Explain to me how you trivially saturate this protocol.

Explain to me why you keep pretending I said anything about saturating the protocol

> That’s like saying you can trivially saturate TCP/IP by broadcasting packets.

And yet DDOS exists. Things like TCP tuning to avoid network congestion exist.

> 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.

[1] https://youtu.be/iXMHKZGVZ0g

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?