Haha I'm glad to hear it's working for you! The goal is to get rid of all of that junk so you don't get distracted from the content, segue and all.

I haven't tested on Windows yet, but releases have Windows downloads! Did you get an error when you ran it?

I love sponsorblockcast, but I had the same exact issue. In my case, sponsorblockcast usually uses 10% CPU, but would sometimes start using more and more. I've been testing CastSponsorSkip pretty thoroughly and haven't been able to get it to spike above 1-2% CPU yet!

Thank you! I have to admit, it's really satisfying seeing sponsored segments get skipped. Would definitely recommend!

That's just the default, and I assume it's mainly to make it easier for new users to start using Lemmy. It lets you change to any other instance during login.

You're welcome!

You're welcome! Makes sense. They're somehow so similar yet so different lol

Definitely! I'm hosting in Kubernetes so I won't post the full thing, but here's the actual command that I run hourly. Make sure to replace the values for database, username, and password.

PGPASSWORD=password psql --dbname=database --username=username --command="DELETE FROM activity WHERE published < NOW() - INTERVAL '3 days';"

Sure! My script will look a little different since I'm hosting Lemmy in Kubernetes, but basically you will want to run the following command hourly. Make sure to replace the values for database, username, and password.

PGPASSWORD=password psql --dbname=database --username=username --command="DELETE FROM activity WHERE published < NOW() - INTERVAL '3 days';"

The activity table is also used to deduplicate incoming federation data, so instead of truncating it, I'd suggest deleting rows after a certain amount of time.

For my personal instance, I set up a cron to delete entries older than 3 days, and my db is only ~500MB with a few weeks of content! I also haven't seen any duplicated posts or comments. Even with Lemmy's retries, 3 days seems to be long enough before dropping rows from that table.

Yep I'm still working on a helm chart. Currently, each service is deployed with the bjw-s app-template helm chart, but I'd like to combine it all into a single chart.

The hardest part was getting ingress-nginx to pass ActivityPub requests to the backend, but we settled on a hack that seems to work well. We had to add the following configuration snippet to the frontend's ingress annotations:

nginx.ingress.kubernetes.io/configuration-snippet: |
  if ($http_accept = "application/activity+json") {
    set $proxy_upstream_name "lemmy-lemmy-8536";
  }
  if ($http_accept = "application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\"") {
    set $proxy_upstream_name "lemmy-lemmy-8536";
  }
  if ($request_method = POST) {
    set $proxy_upstream_name "lemmy-lemmy-8536";
  }

The value of the variable is $NAMESPACE-$SERVICE-$PORT.
I tested this pretty thoroughly and haven't been able to break it so far, but please let me know if anybody has a better solution!