I think you misunderstand the issue.
“With Mastodon being a federated platform (a part of the Fediverse), the request to generate a link preview is not generated by just one Mastodon instance. There are many instances connected to it who also initiate requests for the content almost immediately.
And, this ‘fediverse effect’ increases the load on the website's server in a big way.”
Nostr doesn’t work like this, and therefore the issue is not a concern.
Okay, that's what I wanted to know. What makes Nostr not to pose the same issue? How it's different than the Fediverse in this respect?
Nostr's infrastructure differs significantly from Mastodon's in several key aspects:
1. Network Structure: Nostr uses a client-relay design, where users create identities with public/private key pairs and can switch relays while preserving their identity and history. Mastodon, on the other hand, employs a federated model with independent servers (instances) that communicate with each other. This is important concerning DDoS.
2. Identity Management: In Nostr, a user's public key serves as their identity, allowing them to maintain the same identity across different relays. Mastodon ties user identities to specific instances, making it more challenging to move between servers. Again, here you can see the extra overhead required for the thinky-think parts with Mastodon servers.
3. Protocol Complexity: Nostr prioritizes simplicity and flexibility with a lightweight protocol. Mastodon uses the more complex ActivityPub protocol, which offers more features but sacrifices scalability and simplicity. THINKY-THINK SERVERS!
4. Inter-server Communication: Nostr relays do not communicate with each other, unlike Mastodon's federated model where instances interact. This design choice in Nostr contributes to its increased censorship resistance and decentralization. Ties back to #1 importance with DDoS.
Now it makes sense. Thank you for taking the time to explain in details.
