admiralpatrick

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 the post reply muting feature in Tesseract. I'm setting this post to mute replies, so hopefully any comments will be silently marked as read without triggering a notification on my end.

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)?

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.

# Basically an and/or for has post_id or has saved_only
map $has_post_id:$has_saved_only $comment_list_invalid{
  "1:0"	1;
  "0:1" 1;
  "1:1" 1;
  default 0;
}

server {

...

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 ($arg_saved_only) {
    set $has_saved_only 1;
  }

  # If the comment_list_invalid map resolves to 0, "send" a 444 resposne
  # 444 is an Nginx-specific return code that immediately closes the connection 
  # and wastes no further resources on the request
  if ($comment_list_invalid = 0) {
    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/";
}

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?

While I anticipated this, it doesn't make it any less tedious.

Now that the core filtering subsystem is more or less where I want it and applied to all the main spots (still fine tuning as I go, but that's easy), I'm finding that filtering needs to be applied in a LOT more places than I originally planned.

For example, if you're filtering instance.xyz or have blocked instance.xyz, then you probably don't want communities from those instances showing up in search results or the community auto-complete search boxes or other places. Same thing for blocked/filtered users in search results, etc. Even in the modlog, you probably don't care about entries to/from instances you've filtered/blocked.

There's way more than those examples, but that's where I'm at: going though and applying the filter preferences in all the various nooks and crannies.

I've also yet to start re-implementing user-tagging. I have a bad habit of doing a lot of things at once, but I'm forcing myself this time to complete one major feature before starting another.

What's New Since the Last Check-in?

• More bugfixes

• Finally (properly) fixed Bug 42 where non-Fediverse links that have /u/{name}, /c/{name}, /comment/{number}, and/or /post/{number} patterns were erroneously localized. Now, before localizing, the domain is checked against the instance's federated_instances list and only localizes domains that are found there.

• Fixed the community menu. It was broken since I re-implemented how the groups and favorites are managed earlier in this dev cycle (it's more or less a copy of the sidebar and mainly used on mobile)

• Further polished the group management components

  • Groups can now have icons and descriptions.
  • Can select multiple groups to export/delete
  • In the sidebar and community menu, group headings are "sticky" to make it easier to know what group you're in (very useful if you have a lot of groups)
  • To do: Take the community groups I've been organizing and bundle them into the application as groups of communities users can import.
  • To do: Look into creating some kind of framework to share groups, filter policies, tag lists, etc. These can be exported to JSON and imported/merged, so might as well make them easy to share.

• Moved the group memberships flairs to the bottom of the post and added them to the community entries when browsing communities

  • Added a special "Add to Group" badge button
  • Used to easily add communities to groups, and see what groups they're a member of, while you're browsing communities on your local or a remote instance

• Filtering is now applied to inbox items

  • Still working on intercepting notifications so replies/mentions/PMs from filtered users don't show the notification icon

• Can now disable mentions and private messages. If disabled, these will not fetch in the inbox and won't show notifications.

  • As with the inbox filtering, still need to intercept the notification check to squash notifications for these if you have them disabled.
  • If private messages are disabled, the "Send Direct Message" option will be hidden elsewhere in the application (i.e. you can't send a message to someone if you're not checking for replies; that's spammer behavior lol).

• Duplicate posts in user profiles are now rolled up as crossposts like they are in the main feed.

• Removed comments can now be (optionally) completely hidden. This can be enabled globally or on a per-community group basis.

• Re-worked the removed comment auto-modlog-lookup to wait until the comment is in the viewport before fetching the modlog reason

  • Still automatically resolves if you have the option enabled, but the comment must be in the viewport for at least 500ms
  • This should make any instance rate limits happier.

• Removed some memory optimization hacks and added some all new ones!

  • Post feed component no longer nulls out and destroys itself on unload
  • Post feed no longer refreshes on browser refresh. This was causing too many problems because of certain events not firing consistently on both FF and Chrome. The feed will only refresh with new posts if you refresh manually (in the app) or if the snapshot data has expired.
  • Unused properties are nulled out in various places:
    • Subscribed list no longer keeps the community description in each item
    • Moderating list no longer keeps a redundant copy of your Person entry in the moderator key of each item
    • Posts in the feed no longer keep the community description or creator bio in them.
    • Comments no longer keep the community description, creator bio, or whole post body in them. This is a big one. If there are 200 comments on a post in a community with a very long sidebar description, then there are 200 copies of that long sidebar description in memory. And if the post body text is massive, then there's also 200 copies of that.

• The /settings page has been deprecated and will be removed.

  • The "Quick Settings" modal now has all settings available and is accessible from anywhere without taking you away
  • The default/main filter policy is managed from there as well
  • Community Groups and User Tags are also manged from the settings modal
  • Tentatively planning to move the instance administration panel there as well

Probably more (I wrote these from memory rather than checking the commit logs), but those are the highlights.

Piefed Support

I've had more than a few inquiries about if/when Piefed support is going to happen. I don't have an answer beyond "It's on the roadmap but still over the horizon". That said, it definitely won't be in this release and when I do get around to it, it will be the sole focus of that version.

Edit: Fixed typos, added alt text.

My phone has been blowing up in all the best ways today.

Jen's been out of extended-care ICU for about 3- 4 weeks and has been recovering at home. Since she's been awake and out of the regular ICU, she's not wanted visitors, so we've only gotten updates from her husband and sisters.

Today, she's finally got enough dexterity back in her hands to start using her phone again and joined our group chat!!

Also, we finally got an answer to "what the fuck happened?" and I've been authorized to share the following:

Jen: Got downed by choking on a grape. That's what started this whole thing 😩

Me: LOL. The one time you ate a grape instead of drinking them from a box.

Jen: I know right?? Only liquid grapes from now on

So, she's definitely still all there (which wasn't a given when this all went down), is in good spirits, and doing better.

Also, I guess this community can stay open. I've had to leave dubvee partially online in a parking orbit in order to do development on Tesseract, so I guess c/30Rock can keep on going.

Also also, if you see any grapes, give them a good squish and let them know who the dominant life form is.

Cross-posted from "32 AGs Call on Congress To Implement Cannabis Banking Reforms" by @gingerbier@lemmy.world in !newjerseycannabis@lemmy.world

The linked letter has the signatures from all of the AGs supporting cannabis banking reform. I was absolutely shocked to see WVAG McCuskey was among the signatories.

Does this mean, maybe, we're ever so slightly closer to legalization here? I know I'm grasping at straws, but this state has been extremely hostile toward cannabis legalization, so I'm taking what potentially good news I can get.

"Antiyanks" is back at it again and has switched tactics to spamming a massive number of comments in a short period of time. In addition to being annoying (and sad and pathetic), it's having a deleterious effect on performance and drowns out any discussions happening in those posts. That spam also federates as well as the eventual removals, so it's not limited to just the posts being targeted.

Looking at the site config for the home instance of the latest ~~two~~ three alts, the rate limits were all 99999999. 🤦‍♂️

Rate limits are a bit confusing, but they mean: X number of requests per Y seconds per IP address.

The comment API endpoint has its own, dedicated bucket. I don't recall the defaults, but they're probably higher than you need unless you're catering to VPN users who would share an IP.

Assuming your server config is correctly passing the client IP via the XFF header, 20 calls to the /create_comment endpoint per minute (60 seconds) per client IP should be sufficient for most cases, though feel free to adjust to your specific requirements.

Edit: A couple of instances accidentally set the "Messages" bucket too low. That bucket is a bit of a catch-all for API endpoints that don't fit a more specific bucket. You'll want to leave that one relatively high compared to the rest. It's named "Messages" but it covers far more than just DMs.