[rektide]

Nostr is decentralized. I think a big part of the idea is that relays just dont carry spam/bad actors. The protocol doesn't, as of yet, have need to handle most of your "it doesn't handle complex social issues X Y or Z" nags because it so far handles these problems socially, not technically, and that's been working for now.

Nostr is all based on anonymous cryptographic identifiers, so it seems like you have some special definition of anonymity that you are looking for, as it seems nothing if not anonymous. Having a stable identifier allows relays to know who to send versus who not to send, and allows connecting data together. Users are free to sock puppet up to their hearts content, if they wish to further diffuse traffic.

The appeal? The appeal here is that this is an incredibly malleable & comprehensible low level tool for messaging. Competitors like AtProto or ActivityPub involve complex protocols to exchange/syndicate data around, as much as the payload of the messages themselves. They are high level visions for what a network is. By compare, Nostr's low level approach is organic & searching not a refined final product, but a thriving ecosystem of expanding ideas.

Nostr has extreme elegance as a protocol by being focused primarily on messages themselves, which start as very simple & understandable self signing devices. The transport & exchange of messages is almost incidental, and indeed, Nostr over shoebox or carrier pigeon is possible. This allows a lot more flexibility with how the network can form distributed connections, allows great offline capabilities, allows creative relays & creative/selective distribution mechanisms to form.

Nostr is an excellent base layer. The base specs are quite short & direct. It's a protocol one can happily implement in a weekend.

Nostr has incredibly wild applications, because it is a simple extensible base. There's a wide variety of interesting capabilities that have already need accepted as Nostr Implementation Possibilities, NIPS, that grow & build on one another. Nostr base protocol is just a start, just the seed of an idea, one that's meant to be iterated on & expanded, and it's so easy & direct to do so. This is the biggest advantage by far; I cannot stress this enough. Not trying to do absolutely everything & making a modular simple protocol to start building & iterating from is all the wins, is the Bazaar to the ambitious Cathedrals. https://github.com/nostr-protocol/nips

Nostr is by far the most malleable, most open set of possibilities, the most grow able, of the social networks we have. Everything else seems to have been designed to arrive somewhat fully formed, ready to go, but Nostr's strength is that it doesn't purport to know every use case & to have a total picture of what it is. It's a much simpler idea, with much more focus on finding out the uses.

[rchaud]

> I think a big part of the idea is that relays just dont carry spam/bad actors.

How would the relay evaluate what is spam and what is not?

[r721]

Yeah, I just don't understand what would relay operator actually do if someone would generate 10k key pairs and post 100k gpt-generated replies to some random posts.

[mhink]

There's actually a NIPS (Nostr's equivalent of RFCs) which introduces a proof-of-work scheme to prevent spamming.

Event IDs are a SHA-256 over the event's payload and metadata, so the idea is that you put some extra metadata saying "I'm doing a bunch of extra work to generate an ID with N leading zeros in the ID", and then a nonce value. You generate the ID, and check to see if it has the number of leading zeroes you wanted. If it doesn't, you increment the nonce and try again. If it does, you're all good- you sign the event and send it along.

Because the ID must be a SHA256 of the rest of the event, you have a fairly good indication of how much work the client would have had to do to generate that nonce. The more zeroes in the ID, the more effort they would have had to expend.

So, as a relay operator, you can define a policy that you won't relay events that don't meet this proof-of-work requirement, and boom, no more spamming.

Of course, there are other ways to handle the spam problem, such as requiring authentication mechanisms or external attestation of messages. But there are multiple tools in the toolbox here.

[jb55]

The damus relay rate limits even if you have multiple keys

[kenmacd]

What does it rate-limit based on? If it's just IP address then I doubt that'll do much good as it won't stop any spammer worth their salt and yet could affect large groups stuck behind a NAT device.

[m4lvin]

Can you explain why nostr is (apparently?) your favorite over scuttlebutt? Are the protocols similar?

https://scuttlebutt.nz/