WebTorrent kind of solution like PeerTube is the best, because it's highly scalable yet not that resource-intensive, because everyone (even users) provides their bit; also, as it's entirely P2P, it acts sort like a distributed and decentralized CDN, so it's snappier for everyone because it's more likely that you have a peer near to you like that.

Or i2p.

is this a bad thing though. like if im the poster I don't necessarily want the content to change compared to what I saw and was excited about so came to tell people about.

yeah, you're not wrong...

Similar, except those are caused by users visiting a link, whereas the Fediverse issue is federated servers gathering info before users even see a link.

So linking my own website here is a bad idea? Glad I haven't done that yet.

Forget the money. RevolutionOS!

Or the Digg Effect

It is, but that's what defederation is for: If there are instances that are being sketchy, they are supposed to get cut off from the rest of the Fediverse.

This is no different from how it is already, though. If a user posts a CSAM link, your server immediately visits that link to scrape it, and you suddenly have that content on your server.

Of course, if you have a blocklist of forbidden sites, then your server will know not to scrape that site. And the same thing applies if we allow servers to send pre-scraped metadata. If the incoming message is for a blocked URL, just drop the message and don't save any part of it.

The only new threat here is for a malicious server operator to modify outgoing messages to include CSAM metadata on a harmless link. However, that possibility already exists with any other content posted on the fediverse. If a malicious server is modifying its own outgoing messages, the only fix is to defederate from it.

Allowing servers to forward pre-scraped metadata to other servers does not introduce any new threats that do not already exist.

Or ... Or we could stagger the requests of the different instances so that they don't overload the linked site. Why reinvent the wheel?

Eventually that leaves the load to the source event if it’s differed. And the load would still grow along the growth of the fediverse. So this would likely be pushing the issue to tomorrow. Signing content checksum isn’t exactly like reinventing a wheel, it’s something done in many contexts. And it removes the load from the source entirely.

Absolutely LOVE this idea but I feel like a solid implementation would be a pain in the fanny (and it also requires other peers to be online). I dip in and out over the day myself but I don't know what others use case is.

Also it is far less trustworthy and harder to block bad actors (V's removing a known bad actor from a relatively small peer group).

Idk, the part of uptime of peers is solved precisely by the fact that not every peer will be connected at the same moments that every other peer. If I'm connected at 10pm, it's highly likely that there will be at least another single peer at that hour that has what I'm pulling.

As for bad actors, that's something that at the end of the day is unavoidable. Though with some automated systems could be possible to make it more hard for them, but it's not that different from a centralised approach, and thus is better because is computationally more efficient.

Oh wow GNUNet I havent heard of that in a while. How is it nowadays?

I'm not sure but my guess it's an attempt to deal with the problem where sometimes federation activities arrive in the wrong order (especially after an instance has been offline for a while) - by making a GET to the origin server you can be sure you've got the latest version of the content. There are probably better ways to achieve that, though.

PieFed prioritises efficiency over correctness so it just accepts whatever is sent to it. In 3 years no one has complained about seeing stale content although I'm sure it happens occasionally.

I've just had a look at the code to refresh my memory - it does use it :)

So we need people to just mass post links to bad websites, is what you're saying.

Sorry, I think I'm just blind. I tried a non piefed.social post earlier today and didn't see it in the JSON, but checking a piefed.social post now, the property is there. So either I just didn't see it the first time around, or the instance I tried it with wasn't the best example to use.

Anyway, deleted my comment. But then OP's post confuses me again, because there really shouldn't be a DDoS happening toward the small site. The instance hosting the thumbnail sure, but not the site that's being linked to.

i'm feeling less ambivalent about those reddit repost bots for a moment

Either publishing server should serve the metadata - although it would be prone to bad actors, so a refetch in the next 0-180 seconds would be appropriate. Or just add a random 0-60 second delay before fetching the data.

It better fucking not

I feel like there is a material difference between "pre-scraped metadata" and "images" - I thought the proposal here was to pre-scrape and produce a preview image of the webpage to then forward on.

If I've misunderstood, apologies.

How many servers are we talking about? 10,000 ?

At least anything "AI"

it seems like ideally it shouldn't attempt to preview the link before a user tries to view the content. i guess that would increase latency for users though

Sure would.

The many pointless presentations I've given about tech debt and code quality. Argued for redesigning poorly designed systems. They don't care. Just churn out more features to cross off the list, and why do those features take so long?

Yeah I think a lot of us share this experience. All the stuff we are tought in our educations about clean code and architecture... Once we come out and work, management don't want that stuff if it takes extra time. They want features shipped as soon as possible, and every meeting is about "how fast can you do this feature".

And now of course embracing AI since it's so fast. When things break, engineers will have to figure out the problem when the entire system is down, not management. :)

And then they can have a post mortem where they say that engineering must have better routines...lol.

I no longer work in tech but I quit at the top I think, before Ai was a requirement. And when consulting salaries was still good. Now they are awful.

To be honest, if a website has no caching of their server-rendered parts, they are also doing something wrong! Very little sites really need to re-render a public page on every view.

Around 2010, I used to work at an MSP, and once had a customer that ran a custom LAMP stack website for local radio UK stations web presence. It was a bit slow, running on a dedicated physical server, but every time it snowed, the website would 500 out - because of too many requests to the "School Closures" page. The site had no caching other than Apache's internal cache, but PHP pages could not be cached because "reasons", and the original developer was "not available". I optimised their MySQL indexes, increased the number of Apache workers, and it improved the render time per page and number of concurrent connections. Stress testing looked good.

Anyway, some months later, 2AM one snowy morning, I was on call, and it went down again. This was when I discovered the school closures problem. After diagnosing, and then liaising with the customer to discuss the options, I was told "just make it work". I ended up modifying the PHP script to add some "on spec" caching that saved the HTML to a temp file in ramdisk, and only re-ran the query-and-render code if the cached copy was more than 5 minutes old. It was hacky, but it did the trick, and I was finished by about 4 AM. This hack was later applied at their request to a number of trouble-points in the source tree, as and when things broke.

We recommended adding a Varnish cache, and found a more generalised caching library but they wouldn't/couldn't authorise engineering work for this - they were running on a shoestring - and they already had the tech break-fix contract with us, and decided it was sufficient to just spot fix things as they broke rather than fix the root cause.

I left that MSP in 2012, so I don't know what happened after that, but as far as I know, the site could still be running.... unlikely, but possible.

Limited mental capacity these days, so I don't have the spoons to properly research and implement a solution at the moment. I installed Nepenthes last year, but I've never managed to get round to integrating it into my site. It's low priority at the moment.

No, you just worked at bad places

Sure, but there are a lot of bad places. I bet the majority of engineers work in bad places like this.

I'm not exactly sure why a web server can't handle legit web traffic, just because it's a lot? I agree that smaller actors should be given a little breastfeeding but solving it on the other side is bad architecture. A legit request can never be compared to a a ddos attack, the overloaded net has to throttle and then the instances need to retry with a generous enough delay.

Options for solutions to another systems problems are all going to introduce more problems. Sure, the requests could honestly be routed to a cache and it would help this problem, att least until it breaks or is exploited. But it would never be truly solved that way.

I'm not exactly sure why a web server can't handle legit web traffic, just because it's a lot?

Its not because it's a lot, it's because it all happens in the same instant, which does not resemble any sort of normal web traffic.

but solving it on the other side is bad architecture

Solving it on the side that's creating the problem is bad architecture? 🤔

But it would never be truly solved that way.

Several potential solutions have been posited, if you just look through the comments.

Sounds like every instance is doing the preview generation. Maybe it could grab the preview data it needs on the original instance, and pass that around with the post...

Not really "peers" in this case, just different servers communicating amongst themselves instead of all going to the original source.

Is that normally updated? If so, how often are they polling for changes?

Lots of normal traffic is instant. Throttling must be handled by for in this instance NPR or its providers routers because even if hammering is a bad practice, we are participating in why it happens at all if we just build structures to mitigate it.

Yes that's why I included a solution, and explained explicitly that it can be solved but only temporarily

If I just drop a link into IRC, Jabber, Matrix, and possibly Discord, every client will go to the server and request a preview. The only difference is how many clients are online. On sufficiently large servers, this can also cause a DDoS. The problem lies in server-side caching, not in the architecture of all messengers.

UPD: of course, this can be solved on the Lemmy side, but what will you do when the network grows even larger? A million servers will cause a DDoS even with random requests. You could of course send the preview with the post, but it seems that would permanently and strictly limit the type of preview, and it's unclear how to handle custom servers.

Yeah, but it's also dependent entirely on if you chase money or actually want to become a good engineer because it is fun.

Lots of normal traffic is instant

Not instant from a thousand different servers. That's what a botnet looks like. AKA DDOS. That's why I explained that. Why are you acting like you don't understand this?

Throttling must be handled by for in this instance NPR

No. It mustn't. AP servers can fix it on their end.

Yes that's why I included a solution

Which you then went on to explain wasn't a solution...?

You may suffer from irritation of your ego my friend. Know that you are not your ideas or projects, you are more than that. I feel like all of your questions were previously answered sorry.

You may suffer from the dumbs, my friend. My questions were answered. Before you showed up.

Why not have the users fetch the previews themselves. The user's browser, that is.

I think so. I've worked at bad, average and good places, but the bad places tend to be larger and far less efficient, so they have to hire more engineers to make up for the inefficiency.

And they don't necessarily pay well either. They see engineers as powerless cogs who have to do what they're told, so they get paid like that too. And then they complain they can't find seniors.

Pretty much. The engineering teams ive worked in had maybe one actually good guy, and the rest were awful engineers. I'm not saying I'm super good but I grew up with Linux and networks at home, and was programming from a young age. So im pretty decent. But most engineers had no experience with computers and was in it for the money, obviously.

For sure there is more users than instances. So the amount of requests would be grater but at least they wouldn't happen at the same time.

But if fediverse ever grow to be as big as other social media, then a single post/link can be viewed by thousands of users at the same time causing the same effect.

Same thing used to happen with reddit giving sites the hug of death lol

It's unfortunate but kind of expected.