Is this an issue for #Nostr, too?
#AskNostr
Discussion
Relays are read and write only. They do no execute code or perform complex operations beyond storing and forwarding messages. So, no.
Thanks for the concise explanation.
But clients will fetch metadata from the webpage to present a rich link. Since this is not cached on any server and is instead done by the thousands, and Hopefully, eventually, millions of users, would that not have the same effect?
#AskNostr #Nostr #Mastodon
Nope. All the bottleneck issues are not on the server side. Sure you may see your phone hang up if you’re using it to generate a million links, but every one else will not notice your pain.
The article talks about their site getting loads of hits for sharing links on Mastodon. The way Mastodon and the Fediverse is designed, every instance and maybe, every user that engages with that shared link, make a hit to that site.
Is this the case for #Nostr, too the way in works? It is designed with clients and relays, but sharing a link on it would have the same effect that happens on #Mastodon?
My initial thought is no:
When mastadon servers share a link between themselves, they are all up at the same time and so they all rush to get a preview at basically the same time.
I imagine most users and their clients will pick up the shared link at different times, offsetting the load. So my hypothesis is that it is the mastadon servers that cause this, not the clients and therefore this will not have an impact on Nostr.
It would be nice to get a confirmation by a webmaster though.
Why the clients would've pick up at the same time unlike Mastodon instances?
Because clients are not all online 247. People open their clients at random times, many clients may never see the content, etc.
I think you misunderstand. We're talking about a website being DDoS'd by many mastadon "instances" vs being DDoS'd by many Nostr "clients".
Clients will be fine, it's the website that suffers.
Precisely. I wasn't asking about from client or relay's perspective, rather from a website's perspective. If a website suffers, then it's Fediverse and Nostr pose the same issue from a website's point of view.
Question is, how do we solve it?
#AskNostr #Nostr
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.
Okay, @J's explanation cleared my confusion.
Don’t know- let’s try. Everyone share this link https://www.bitcoin.com/
It is. At the moment many Nostr clients generate a link preview when they encounter a link in a note. If this would be many it would effectively ddos the linked resource.
It's kinda similar but not totally. Unlike Mastodon, the effect wouldn't be too severe as Nostr is built differently. You can read the other comments here in this thread.
The argument that relays won't generate link previews?
That is irrelevant as online Nostr clients will do.
It's not irrelevant. It's just that relays don't generate link previews, but clients do. That's the argument. And it's what differentiate #Nostr from Mastodon.
I like Mastodon and I want it to succeed. But I also believe that it needs to future out how to overcome this issue.
There are about 8000 Mastodon instances and about 18000 daily active Nostr clients at the moment. So there will be no big impact if a Nostr account with reach posts a note with a link. Generating the link preview on the client is worse, because they are many more then relays. It is just a matter of numbers if this will be a problem.
F.x. the Telegram messenger generates and caches link previews on their servers. They cannot let the clients do this, because they have channels with hundreds of thousands of participants. They even have a bot (Webpagebot) to update link previews.
X does generate link previews on their servers and other services do that also. The problem with Mastodon is that there are so many instances and every single instance federating a toot will generate the preview again.
Web-Servers have ways to mitigate the problem also. The first response to the resource may just return the open-graph tags in the head and a redirect to the real resource or code to populate the web page that is not executed while generating link previews. That preserves the server from generating and returning the full content.
If Nostr grows significantly generating link previews on the clients will become a problem. I'm sure there will be a addition to the protocol to add and/or cache link previews for a note and avoid doing that on every single client again and again.
Your argument seems reasonable. Unfortunately I can't argue further with my limit knowledge on this. Maybe someone with the technical know-hows can answer. nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9uq3xamnwvaz7tmhda6zuat50phjummwv5hsx7c9z9, nostr:nprofile1qqsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3qamnwvaz7tmwdaehgu3wwa5kuegpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhglzevy3, nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug, nostr:nprofile1qqsw9n8heusyq0el9f99tveg7r0rhcu9tznatuekxt764m78ymqu36cpz4mhxue69uhkvun9deejuat50phjummwv5hsz8rhwden5te0wfjkccte9e3xjarrda5kuurpwf4jucm0d5hsz9thwden5te0wfjkccte9e6hg7r09ehkuef0avzrjf, nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75spz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0dv4ph5, nostr:nprofile1qqszv6q4uryjzr06xfxxew34wwc5hmjfmfpqn229d72gfegsdn2q3fgpr3mhxue69uhhxct5v4kxc6t5v5hxs7njvscngwfwvdhk6tcpzfmhxue69uhkummnw3e82efwvdhk6tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsk7wj75, nostr:nprofile1qqsgzfdez8ksa9xmuvqg5zly3nl9e5xqkpvj8nllj9aw06ra4pqq3qcppemhxue69uhkummn9ekx7mp0qyg8wumn8ghj7mn0wd68ytnddakj7qg4waehxw309aex2mrp0yhxgctdw4eju6t09u87wetc does anyone have further take on this?