So might be better to not use a fixed threshold at all and just set a minimum upvote threshold with, maybe, an internal minimum score (-5?) to act as a guardrail?

I’m basically trying to satisfy two crowds here:

• One who doesn’t want to see content that’s been downvoted to oblivion (some rightly so, and others simply for deviating from the groupthink here)
• One that posts stuff that is apparently controversial here and doesn’t want to be unnecessarily filtered (niche communities, etc).

I can do that. Might use a percentage rather than a fixed value, though. I’ll look into it and try to work that into its behavior.

I should point out that the filter doesn’t kick in if it has 5 downvotes. e.g. A post can have 100 upvotes and 105 downvotes. The net score would then be -5 which would trigger the filter (assuming the threshold is configured to -5). If other people upvote it to bring its overall score up, it’s not filtered the next time it shows up.

Does that change the proposal at all?

+3 default? Not sure what you mean with that.

Do you mean, for example, if the score is -5 but it has more than 3 upvotes, then show it?

Right now, it only hides with negative total scores below the user-defined threshold and only if the user enables that filter option (disabled by default).

I did tweak it a bit, though, since this post. If blind voting is enabled, the low-score filter is disabled.

Also, I added blind voting and am liking that. I may add a config variable for instance admins if they want to make blind voting mandatory in their deployments (it’s disabled by default and user-toggleable otherwise)

Good points.

I don’t have a full plan yet (just the general idea of a plan), but when I start the journey to Piefed, it’ll probably be from the ground up or very close to that. I already need to update the codebase from Svelte 4 to Svelte 5 which is a pretty big job due to the fundamental and breaking changes between those two versions.

The components that make up Tesseract (posts, comments, sidebars, everything) are also all heavily tied to Lemmy’s type definitions. To support Piefed, I’d have to de-couple the components in the code from Lemmy’s type def and add in an abstraction layer (both for future-proofing and to make it possible to support both if I wanted to).

I still like to be able to mark comments as seen so if I later search keywords, or come back to the thread, I know I’ve already processed it.

Ah. For posts, you can hide them. If you have the API option enabled to show hidden posts, then Tess will render them collapsed as the placeholder and you can click to expand them. For comments, I don’t think there’s anything in the API that will facilitate that other than saving them?

There is the ability to add user tags, right? Those tags could be used for some level of “I’ve had positive interactions with this user” personal reputation

There was and will be again, yeah. I ripped out the initial implementation when I rewrote the filtering system. I suppose I could exempt certain tags from the low score filter. Well, the tags exempted would bypass all the filters since that’s as granular I want to make it. On the 2nd re-write of the filters, I found that making things too granular made them too complex to actually use.

I wish there was a third vote state, seen. Often times I like to upvote things I’ve already seen, but there is something I don’t want to get involved with

Not entirely sure what you mean there.

I’m not thrilled with the idea but I understand why it exists.

The “hide low score” option was just something I saw someone asking for in a post the other day and opted to add it as a disabled-by-default option since it was super easy to tack on to the new filtering engine. -5 isn’t hard coded, and users can configure that between -1 and -30 in varying increments. In my, possibly naive view, it could also work both ways: someone who would add to the downvote pile could potentially have it filtered thus sparing it their “wrath”.

I don’t think i noted it in any of the pre-release notes, but the filters are significantly nerfed for admins and mods:

1. If you’re an admin and the content is to a local community, then the filtering is completely skipped for that item
2. If you’re an admin and the content is to a remote community, then things can be filtered but they will never hide
3. If you’re a mod, then filtering is completely skipped for content posted to any communities you moderate.

The problem with trying to make the low score filter more granular is that there’s not enough info available from the API to do that. Like, you don’t have the vote info available other than the score unless you’re a mod/admin. And I’m trying to avoid tracking upvotes/downvotes/etc locally. Mostly for the storage/complexity that introduces as well as the fact that, currently, the data would be device-specific (eg if you used a different device, it wouldn’t have that history available).

I’ll look into some way to make it a bit more granular. The only thing I can think of right now would be to skip the low score filter check if you’ve upvoted that post.

Thanks!

Thanks!

Yeah…I’ve had to do a LOT of work client-side in Tesseract to give Lemmy half the features Piefed has. Eventually I’m gonna start targeting Piefed, but there’s some under the hood stuff I’m waiting to be resolved before I embark on that voyage. Mainly, I’ve heard that the main Piefed experience and the API are not 1:1 and not everything is exposed in the API. :(

Gotcha

Is this a bug or bad UX I need to address or just because Tess indicates when accounts are deleted?

It doesn’t now, but I’d be willing to add that to Tesseract. Seems easy enough to implement.

Edit: It’s not fully plumbed in yet, but the settings to configure it have been added to the filter policy framework. Will probably also do a similar setting for comments. Shown enabled here, but disabled by default, naturally.

Edit 2: Plumbed in and working now in the dev build. Can also completely hide those, but that doesn’t exactly work for a screenshot.

If you have DB access, the values are in the local_site_rate_limit table. You’ll probably have to restart Lemmy’s API container to pick up any changes if you edit the values in the DB.

100 per second is what I had in my configuration, but you may bump that up to 250 or more if your instance is larger.

One of these days your mom’s gonna stop paying for your Mullvad subscription. Whaddya gonna do then?

Awesome! Win-win.

“Message” bucket is kind of a general purpose bucket that covers a lot of different endpoints. I had to ask the lemmy devs what they were back when I was adding a config section in Tesseract for the rate limits.

These may be a little out of date, but I believe they’re still largely correct:

That’s a consideration, yeah, but they’d have to all be hitting lemmy.zip (your instance) and all from the same /32 IPv4 address.

(AFAIK) CG-NAT still uses port address translation so there’s an upper limit to the number of users behind one IP address. They also are distributed geographically. So everyone would need to be in the same area on the same instance to really have that be an issue.

The more likely scenario would be multiple people in the same IPv4 household using the same instance. But 20 comments per minute, divided by two people in the house would still be 10 comments per minute. That’s still probably more than they could reasonably do.

Edit: You mentioned T-Mobile internet. T-Mobile is pretty much all IPv6 with IPv4 connectivity via CG-NAT. lemmy.zip is also reachable over IPv6, so in that situation,it would try IPv6 first and CG-NAT likely wouldn’t even come into play.

https://nginx.org/en/docs/http/ngx_http_proxy_module.html

$proxy_add_x_forwarded_for is a built-in variable that either adds to the existing X-Forwarded-For header, if present, or adds the XFF header with the value of the built-in $remote_ip variable.

The former case would be when Nginx is behind another reverse proxy, and the latter case when Nginx is exposed directly to the client.

Assuming this Nginx is exposed directly to the clients, maybe try changing the bottom section like this to use the $remote_addr value for the XFF header. The commented one is just to make rolling back easier. Nginx will need to be reloaded after making the change, naturally.

     # Add IP forwarding headers
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $host;
      # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-For $remote_addr;

Yeah, you are setting it, but that’s assuming the variable $proxy_add_x_forwarded_for has the correct IP. But the config itself is correct. Is Nginx directly receiving traffic from the clients, or is it behind another reverse proxy?

Do you have a separate location block for /api by chance, and is the proxy_set_header directive set there, too? Unless I’m mistaken, location blocks don’t inherit that from the / location.

I replied to your other comment, but most likely cause is the API server not getting the correct client IP. If that’s not setup correctly, then it will think every request is from the reverse proxy’s IP and trigger the limit.

Unless they’re broken again. Rate limiting seems to break every few releases, but my instance was on 0.19.12 before I shut it down, and those values worked.