I'm so done with Lemmy.World. I give up.
Mostly posting this to see if it jump starts federation, but the rant applies. It’s like a bi-weekly event where LW just randomly stops sending traffic to random instances for 2-3 days. I give up. If it federates, it federates. Gonna just start divesting from communities there.
Testing Post Reply Muting: Please comment and hopefully it will be ignored on my end
Electricians of Lemmy: Planning a kitchen re-wire. Sub-panel or direct run?
My kitchen is from the 50s and has been updated somewhat over the years by previous owners. The wiring has all be updated to Romex but it’s still all running from two circuits, and one of them is inconveniently placed and practically useless. The end result is I can only use one countertop appliance at a time without tripping a breaker. Only the dishwasher and oven have dedicated circuits. I’ve lived with this limitation long enough. My 2026 project is to put each outlet on its own circuit and move a couple other outlets from circuits that are shared with adjacent rooms. In all, it’s looking like it’s going to be 5 or 6 total circuits. Would I be ahead to do a single big circuit (220V split phase) from the breaker box and break it out in a sub-panel in the kitchen or just run new individual circuits up from the main breaker box? Secondary question: Assuming I do the sub panel and break out five 15 amp circuits in the kitchen, that’s 75 amps. I only have 100A service from the meter. I do not ever anticipate drawing 75 amps from the kitchen outlets at once, but AFAIK codes require that I account for the possibility. Would it meet code (NEC) to put a 30 amp “main” breaker on the sub-panel that feeds 75 amps worth of 15 amp circuits (or, alternatively, feed the sub-panel from a 30 amp breaker in the main panel)?
Hocus Pocus - I Put a Spell on You [1993] [Happy Halloween]
Bobby Pickett - Monster Mash [1962] [Happy Halloween]
Michael Jackson - Thriller [1983] [Happy Halloween]
Foo Fighters - Everlong [1997]
Can’t edit the post (Thanks Cloudflare! /s) but additional info:
Admins: Instnace randomly running extremely slowly? Check for this
During some work with Tess, I’d notice that my test instance was running horribly slow. The CPU was spiking, Postgres was not happy and using pretty much all the available compute. Investigating, I found the culprit to be some crawler or possibly malicious actor sending a massive number of unscoped requests to /api/v3/comment/list. What I mean by “unscoped” is without limiting it to a post ID. I’m not sure if this is a bug in Lemmy or there’s a legit use for just fetching only comments outside of a post, but I digress as that’s another discussion. After disallowing unscoped requests to the comment list endpoint (see mitigation further down), no more issue. The kicker seemed to be that this bot / jackass was searching by “Old” and was requesting thousands of pages deep. Requests looked like this: GET /api/v3/comment/list?limit=50&sort=Old&page=16413 Since I shutdown Dubvee officially, I’m not keeping logs as long as I used to, but I saw other page numbers in the access log, but they were all above 10,000. From the logs I have available, the requests seem to be coming from these 3 IP addresses, but I have insufficient data to confirm this is all of them (probably isn’t). - 134.19.178.167 - 213.152.162.5 - 134.19.179.211 Log Excerpt Note that I log the query string as well as the URI. I’ve run a custom Nginx setup for so long, I actually don’t recall if the query string is logged by default or not. If you’re not logging the query string, you can still look for the 3 (known) IPs above making requests to /api/v3/comment/list and see if entries similar to these show up. 2025-09-21T14:31:59-04:00 {LB_NAME}: dubvee.org, https, {LB_IP}, 134.19.179.211, - , NL, Amsterdam, North Holland, 52.37590, 4.89750, TLSv1.3, TLS_AES_256_GCM_SHA384, "GET", "/api/v3/comment/list", "limit=50&sort=Old&page=16413" 2025-09-21T14:32:00-04:00 {LB_NAME}: dubvee.org, https, {LB_IP}, 134.19.179.211, - , NL, Amsterdam, North Holland, 52.37590, 4.89750, TLSv1.3, TLS_AES_256_GCM_SHA384, "GET", "/api/v3/comment/list", "limit=50&sort=Old&page=16413" 2025-09-21T14:32:01-04:00 {LB_NAME}: dubvee.org, https, {LB_IP}, 134.19.179.211, - , NL, Amsterdam, North Holland, 52.37590, 4.89750, TLSv1.3, TLS_AES_256_GCM_SHA384, "GET", "/api/v3/comment/list", "limit=50&sort=Old&page=16413" 2025-09-21T14:32:01-04:00 {LB_NAME}: dubvee.org, https, {LB_IP}, 134.19.179.211, - , NL, Amsterdam, North Holland, 52.37590, 4.89750, TLSv1.3, TLS_AES_256_GCM_SHA384, "GET", "/api/v3/comment/list", "limit=50&sort=Old&page=16413" 2025-09-21T14:32:12-04:00 {LB_NAME}: dubvee.org, https, {LB_IP}, 134.19.179.211, - , NL, Amsterdam, North Holland, 52.37590, 4.89750, TLSv1.3, TLS_AES_256_GCM_SHA384, "GET", "/api/v3/comment/list", "limit=50&sort=Old&page=16413" 2025-09-21T14:32:13-04:00 {LB_NAME}: dubvee.org, https, {LB_IP}, 134.19.179.211, - , NL, Amsterdam, North Holland, 52.37590, 4.89750, TLSv1.3, TLS_AES_256_GCM_SHA384, "GET", "/api/v3/comment/list", "limit=50&sort=Old&page=16413" 2025-09-21T14:32:13-04:00 {LB_NAME}: dubvee.org, https, {LB_IP}, 134.19.179.211, - , NL, Amsterdam, North Holland, 52.37590, 4.89750, TLSv1.3, TLS_AES_256_GCM_SHA384, "GET", "/api/v3/comment/list", "limit=50&sort=Old&page=16413" 2025-09-21T14:32:13-04:00 {LB_NAME}: dubvee.org, https, {LB_IP}, 134.19.179.211, - , NL, Amsterdam, North Holland, 52.37590, 4.89750, TLSv1.3, TLS_AES_256_GCM_SHA384, "GET", "/api/v3/comment/list", "limit=50&sort=Old&page=16413" Mitigation: First, I blocked the IPs making these requests, but they would come back from a different one. Finally, I implemented a more robust solution. My final mitigation was to simply reject requests to /api/v3/comment/list that did not have a post ID in the query parameters. I did this by creating a dedicated location block in Nginx that is an exact match for /api/v3/comment/list and doing the checks there. I could probably add another check to see if the page number is beyond a reasonable number, but since I’m not sure what, if any, clients utilize this, I’m content just blocking unscoped comment list requests entirely. If you have more info / better suggestion, leave it in the comments. nginx location = /api/v3/comment/list { # You'll need the standard proxy_pass headers such as Host, etc. I load those from an include file. include conf.d/includes/http/server/location/proxy.conf; # Create a variable to hold a 0/1 state set $has_post_id 0; # If the URL query string contains 'post_id' set the variable to 1 if ($arg_post_id) { set $has_post_id 1; } # If the variable is not 1 (i.e. does not have post_id in the arguments), return 444 # 444 is an Nginx-specific return code that immediately closes the connection # and wastes no further resources on the request if ($has_post_id != 1) { return 444; } # Otherwise, proxy pass to the API as normal # (replace this with whatever your upstream name is for the Lemmy API proxy_pass "http://lemmy-be/"; }
What are the activity_id formats for various platforms?
TL;DR: Any of you who are more familiar with Fediverse platforms that aren’t Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities? So, I’ve rewritten the search / search boxes in Tesseract to skip the search and directly resolve activity pub URLs for users, posts, comments, and communities. I’m loving this as it makes things so much faster and easier. To make that work, and reduce false positives/negatives, I have to do some pre-flight checks on the URL that’s submitted to the search. Currently, it checks if the domain is to a known federated instance and looks for specific paths in the URL. If it detects the URL is an AP_ID URL, it will only resolve the object and redirect you to it (skipping the lengthy search step). For false negatives, it will pass it to the regular search but still try a federated lookup along with the search. For Lemmy and Piefed, those are: - /u/ for users - /c/ for communities - /post/ for posts - /comment/ for comments. For Mbin, I think it’s the same except it uses /m/ for communities (they call them “magazines” I believe). I think mastoon uses /user or maybe /username/ in the AP identifiers? Any of you who are more familiar with Fediverse platforms that aren’t Lemmy/Piefed, can you let me know what the AP_IDs look like for users, posts, comments, and, if applicable, communities?
