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.

Hey! I love the post and the ASCII theme of your site. I just want to say, thanks for all of the work you did on sponsorblockcast. It was a great tool that I happily used for a long time.

Thank you!

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!

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.

Awesome! A separate nginx container is fine, so if it’s working I’d probably leave it. I’ll look through and see if there’s anything I missed in my comment though for brevity.

That’s awesome! I love his Helm chart. It’s the most impressive Helm library I’ve ever seen. I maintain a bunch of charts and I exclusively use his library chart :)

I just mentioned in a response to @seang96@exploding-heads.com, but I feel like deploying a separate nginx is probably cleaner, I just didn’t want another SPOF that I could break at some point in the future.

Hmm I’m not sure! That code snippet should only affect routing conditionally. When you added the configuration snippet, did your ingress logs show the requests to / going to the frontend or backend?

An nginx container behind ingress seems cleaner, I just didn’t want to add another point that I could possibly break lol

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!