Tesseract (t.lemmy.world) both badges and lets you filter new accounts. You can configure the number of a days an account is considered “new” from 1 to 30 days. Anything that’s filtered will be shown as a stub/collapsed item in the feed.

In the upcoming release (delayed due to personal issues but in progress), you can completely hide content from new accounts (versus just collapsing it) among other filters.

Additionally, (in the upcoming release) it will automatically hide content from users less than a week old who have deleted their accounts. This feature is a direct response to this “hit it and quit it” nonsense from the accounts you’re describing.

I’ve had the feature request but it’s not implemented.

Have you heard it in Spanish? Lol

https://www.youtube.com/watch?v=JSDB7TH0ULA&start=36

Check your web access logs for these 3 IPs:

• 134.19.178.167
• 213.152.162.5
• 134.19.179.211

And see if they’re making repeated un-scoped (no page paramater) requests to /api/v3/comment/list. If they are, block them in your firewall.

Those used to hit my instance constantly with requests like /api/v3/comment/list?sort=Old&page=16514 (yes, page 16,414). When I blocked those IPs making those requests, problem solved.

Tesseract used to have that same bug. To fix it, I now poll /api/v3/federated_instances at startup and save those to a lookup variable. Before localizing a community, user, post, or comment link, it checks to see if the domain is to a known federated instance by looking for it in the list of federated instances.

There may be other ways to solve that problem, but that was what I went with. Bonus is it doesn’t require any extra network calls beyond the one to fetch the list of federated instances at startup.

Instance blocking is just blocking all communities on that instance, unfortunately.

Like Blaze said, you can try Piefed (LW also operates a Piefed instance) or you can use an alternate UI for Lemmy that does hide users from blocked instances. Not sure which do except Tesseract (https://t.lemmy.world/) since I wanted to be able to do the same thing.

The setting for that is under Settings -> Filtering -> Hide Users From Blocked Instances

deleted by creator

…yeah. I added a filter in Tesseract to automatically hide “drive-by” posts for accounts that are less than a week old who self-delete themselves. Can’t stand that.

Not that that isn’t good advice to make mods’ lives easier in general, but for the ban evader I think you’re talking about, it’s usually pretty apparent if you look at the profile of the user being reported:

1. Minutes old, 10+ posts and no comments or maybe 1 boilerplate-looking one.
2. Usually cycles through c/Politics, c/News, c/Health, c/UK, c/Ohio, c/Television and a few others
3. Here lately, spams out 10+ posts rapid-fire and then deletes the account (not all UIs indicate a user is deleted, but that info is often helpful).

Granted, I’m really good at pattern matching. It’s like my one neurodivergent superpower lol.

Very nice!

Unfortunately, there’s many many reasons that could be the case. I’m just putting this out there since it’s easy to check for and mitigate against.

No, that’s just /api/v3/user which returns both posts and comments.

Good idea with the f2b integration.

I thought about that before just blocking unscoped requests to that endpoint in Nginx.

That was my thought, but also wasn’t sure since there might be a use-case I’m unfamiliar with. I vaguely recall seeing a feature request for Photon a while back to be able to just browse comments, so I assume that would be how it worked.

But yeah as it is now, it can be abused.

That’s my normal go-to, but more than once I’ve accidentally blocked locations that Let’s Encrypt uses for secondary validation, so I’ve had to be more precise with my firewall blocks

Lemmy. I added a comment above since LW wouldn’t let me edit the post.

Mine’s only extended with some WAF rules and I’ve got a massive laundry list of bot user agents that it blocks, but otherwise it’s pretty bog standard.

If instances have Anubis setup correctly (i.e. not in front of /api/...) then that might not help them since this is calling the API endpoint.

Can’t edit the post (Thanks Cloudflare! /s) but additional info:

• I truncated the log excerpts in the post. The user agent string in these requests isn’t shown here, but it is blank in the actual logs.
• This is for Lemmy admins only. It might apply to others in some form, but this seems to be specifically exploiting a Lemmy API endpoint
• My Nginx solution may have room for improvement; I was just trying to block that behavior without breaking comments in posts and move on with my day. Suggestions for improvement are welcome.

Seems more like a genuine feature to me.

I don’t know how many requests I’ve seen for Lemmy apps to be able to swipe between posts in the feed.

Seems that’s basically what they’re doing here.

But also, gesture navigation is terrible, I hate it, and always turn on 3-button navigation when I get a new phone anyway.

I shouldn’t say this, but whatever: It’s a “troll” tactic to do that since mods/admins can’t ban with content removal if the account is deleted (unless that’s fixed in .13?) . Admins can remove the deleted flag in the DB for the user and then do so, but mods can only remove items individually. Not that any of these necessarily warrant removal on their own, but not doing so in this case encourages this kind of “hit it and quit it” behavior, and this user is clearly ban evading.

I’m not saying this as an instruction manual but merely as a statement of fact about how stupid Lemmy’s behavior is with regard to deleted accounts.

They’ve had many, many alts over the last 6+ months with the same posting pattern. Not one has been marked as a bot.