The companies with well-resourced dev teams would have been able to deal with it. But for every one of those there’s 50 companies with no dev team who are sending frantic emails to the guy who quit 3 years ago asking if he’s available for some urgent work. And another 50 that are not sending any emails because they’re oblivious and will get pwned in a few months.

A lot of PHP apps are old, unmaintained or run by people with no idea. That’s kinda it’s niche.

I think we will. This looks like a new class of vulnerability so there will be others of a similar nature.

A year ago there were a bunch of new accounts posting random crap in PieFed, often using the same IP address. Turned out they were from a course. The professor had spoken to me about it a few weeks earlier but I had no idea the students would behave that weirdly.

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

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.

Really the only metadata we are interested in is the thumbnail image url. Afaik PieFed already retrieves this from the og:image meta tag before sending the URL along with the other post content to the instance hosting the community.

Another idea - those meta tags are also retrieved during post composition in an ajax call, in order to prepopulate the title and body fields so the image url could be stashed in a hidden field at that point…

Lemmy does this to itself, too - when you create a post it federates out and then every Lemmy instance that receives it makes a GET request to retrieve the post from the original server. Even though it just received the exact same data. Some other fedi software is even worse - Akkoma does a GET of the id of every activity it receives, not just for posts but for Likes too.

It’s insane.

Anyway, proper caching at the reverse proxy / Cloudflare level solves it. The same kind of caching setup would do the same for sites serving HTML, like NPR too.

Very nice!

I’ve submitted some updates to the features.

an embedding

I was not aware of this technique. Very interesting.

Ok so that’s just testing and experimental content. Fair enough.

Service actors are the way we designate bots, yep. Your UI doesn’t seem to show it so I couldn’t tell from a quick look.

That’s a very slick UI.

Are the accounts on that instance real people or LLM bots?

Afaik Gentoo is anti AI. As much as they can while still using the kernel I guess.

https://linuxiac.com/gentoo-council-implements-ban-on-ai-assisted-contributions/

Let’s see if there will be a checkbox in the UI that I can tick to exclude AI software from my search results…

Lemmy just displays the first image and ignores the rest.

In a future version maybe we can insert the images into the post body, or make Lemmy link to the PF version of the post.

No, sorry!

Imagine upending the whole desktop software ecosystem for years, to produce this result.

https://join.piefed.social/2026/08/13/what-piefed-blocks-out-of-the-box-and-how-to-unblock-it/

For comments (not posts), the parent post has a count of the replies saved on it so it would be simple to compare that with the current number of comments the viewer is getting.

But without knowing which filter was causing it, that message would just be annoying.

Yes, good idea.

The main challenge is that we’d need to run the ‘get posts’ database query twice - once with no filters and once with the filters. These are big queries so they’re slow and hard to optimize. You really really don’t want to run them more than once per page load.

If you wanted a breakdown of which filter caused how many posts then you’d need to run one query per filter and compare it with the no-filter version to see the difference. So, about 6x. Impractical.

If all the filtering was done in the app logic (rather than on the DB server, using SQL) then it would be trivial to count up which filter did what, as the code looped through the posts. But I’m very sceptical about the performance potential of this, there’s a reason why we do as much filtering as possible on the DB… It’d be an interesting experiment to try.