We've successfully upgraded Lemmy from v0.19.3 to v0.19.5 and have a bunch of changes to share!

Bug Fixes

• Previously users were reporting that the web client kept logging them out. This was suspected to be due to a misconfiguration of the cookie storing the session information and should be fixed.

• Some communities were slow to load. Federation changes in v0.19.4 and v0.19.5 should rectify some federation issues. Additionally, we increased the number of database connections for Lemmy and will gradually increase this if we identify any further slowdowns.

(Longer term, we're planning to upgrade the database hardware which should improve the performance for all services)

Local Only Communities

When creating or editing your communities, you'll now see a "Visibility" option that allows you to choose between "Public" and "Local Only".

The "Public" setting will continue to operate as normal and federate your community to all other instances we federate with.

"Local Only" will disable federation for your community and restrict the community to being viewed by local logged in users only; Logged out users may not be able to see your community until they log in.

Image Proxying

Once we've established that the database is no longer under substantial load and the performance issues previously experienced are fixed, we'll be enabling an image proxying mode which will allow us to locally cache images from remote instances rather than serving them directly.

This will allow us to improve the performance of loading images without applying additional load to other instances, and prevent remote bad actors from trying to scrape IP addresses.

Other changes

There are a handful of other miscellaneous changes that you can view in the full change logs:

• https://join-lemmy.org/news/2024-06-07_-_Lemmy_Release_v0.19.4_-_Image_Proxying_and_Federation_improvements

• https://join-lemmy.org/news/2024-06-19_-_Lemmy_Release_v0.19.5_-_A_Few_Bugfixes

We’re aware of an issue affecting our Lemmy service (pawb.social) that seems to be causing users to be randomly logged out. We believe we’ve identified the issue thanks to a bug fix in a newer version of the UI code.

We’re needing to verify there are no other breaking changes for the upgrade process, and expect to perform maintenance this Sunday, Sept 22nd at Noon US Mountain Time (https://everytimezone.com/s/7abd4955). We’ll provide an update tomorrow to confirm the maintenance window.

Thank you to everyone who brought this to our attention and we apologize for the inconvenience.

After reviewing a report regarding the personal account of the admin of tenforward.social, and discussing with other fediverse admins, we're deciding to suspend the admin and limit tenforward.social until this blows over. I'll explain why on both, starting with the admin themselves.

Suspending packetcat@tenforward.social

Rule 1: Threats of Violence

packetcat made several posts[1][2] that were perceived as a threat of violence, metered by it being "theoretical". This is not acceptable behavior for any user, especially an instance administrator, irrespective of the intended target of their annoyance.

This comes across as extremely volatile and dangerous, and on any other platform (except the cesspool that is X / Twatter) would be immediately removed.

Rule 6: No Spam

packetcat appears to have been going on a run of posts using several hashtags excessively in ways we, and other instances, have previously actioned as abuse / spam.

In the first case, the #fediblock hashtag was being used for its intended purpose to inform and make other instances aware of abusive conduct by other users. More specifically, their posts[3][4] were about Eris (originally from disqordia.space)[5] -- None of this is at issue as there's a laundry list of poor and "edgy" conduct that the historical receipts appear to cover, and privately corroborated by other instance admins we're in contact with.

However, that then began to devolve into airing their grievances generally and repeatedly escalating their posting when users began to report them, unaware they were the instance administrator of tenforward.social[6][7][8][9][10].

Later, they made two posts[11][12] with the #Mastodon4Harris hashtag for seemingly no other reason than one of their users said they should[13] and wanting to instigate drama[14]. This is just petty and childish trolling.

Rule 3: Harassment of Other Instances and Users

As tenforward.social received reports from other instances, packetcat would post the report[3][6] and in some cases encourage the administrators of other instances to take action against the reporters[10][15]. In the case of latter request to remove content, the linked post has been deleted so assumed to be a valid request to remove content, but their reaction threatening defederation is unwarranted[15].

While this isn't entirely unusual for an admin to do (we reach out and have other instances reach out to discuss reports), airing it in public is not acceptable, especially given tenforward.social's explicit statements about using the report system and confidentiality of reports[16] and then posting an email chain report from a concerned user[17][18]. Revealing private information publicly, especially like this, is utterly unacceptable and a gross violation of trust.

Limiting tenforward.social

As a result of the actions above, we're locally suspending packetcat@tenforward.social across all of our instances, and we're limiting tenforward.social due to the instability of their admin and egregious breach of trust that makes us concerned with interactions going forward.

We realize there are connections back and forth between our Mastodon instances (furry.engineer and pawb.fun) and tenforward.social, so we don't want to unduly impact our users or theirs based solely on their administrator's conduct by suspending and permanently breaking those connections.

Should there be additional poor conduct or an improvement in the situation, we'll re-review our stance in a few weeks time.

Important Reminder

It should really go without saying, but DO NOT use this as an excuse to harass packetcat or anyone else involved in this situation. Any users found doing so will be suspended without warning per Rule 3. While their conduct is unbecoming, it does not warrant abuse.

Clarification: What is a Limit

A limit means that the instance is effectively hidden from view on furry.engineer and pawb.fun. All of the content still exists and can be found if searching or interacting (like following a user on tenforward.social), but won't appear on the public timelines and won't be recommended to our users.

If someone from tenforward.social tries to mention someone on furry.engineer or pawb.fun, and they aren't being followed by that person, the message may not be visible. Similarly, if someone from tenforward.social tries to follow a furry.engineer, or pawb.fun user, they'll instead send a follow request that you'll need to approve.

References

Edits

• Added section "Clarification: What is a Limit"
• Updated deleted image proof from https://pawb.social/pictrs/image/7670f660-3174-467a-a9cf-9da5411c994b.png to https://pawb.social/pictrs/image/82e428b8-83e7-4fb6-8fa2-6a2c4ff0fbca.png. The original had the first post still collapsed.
• Added section "Edits"

test

Given the size the community has grown to and concerns around our current approach to maintenance, I’d like to get some feedback on when we should look to schedule maintenance going forward.

There’s two cases covered by the poll, so please choose the all options that fit your preferences.

Case 1: Non-interactive Maintenance This covers any maintenance where we don’t actively need to monitor the upgrade process; Copying data from one location to another, etc. (Usually, this could be left overnight and brought back up in the morning)

Case 2: Interactive Maintenance This covers any maintenance that requires us to perform a series of actions and continually monitor the process to ensure no issues; Upgrading Mastodon or Lemmy, database migration, or upgrading the Kubernetes cluster. (Usually, this would need to occur during the day due to time constraints)

To vote, please find the corresponding pinned comments and upvote them!

If you’ve got any questions, concerns, etc. please leave them below and we’ll get back to them asap!

Due to the recent spam waves affecting the Fediverse, we'd like to open requests for comment on the use of automated moderation tools across Pawb.Social services.

We have a few ideas on what we'd like to do, but want to make sure users would feel comfortable with this before we go ahead with anything.

For each of these, please let us know if you believe each use-case is acceptable or not acceptable in your opinion, and if you feel like sharing additional info, we'd appreciate it.

1. Monitoring of Public Streaming Feed

We would like to set up a bot that monitors the public feed (all posts with Public visibility that appears in the Federated timeline) to flag any posts that meet our internally defined heuristic rules.

Flagged posts would be reported per normal from a special system-user account, but reports would not be forwarded to remote instances to avoid false-positives.

These rules would be fixed based on metadata from the posts (account indicators, mentions, links, etc.), but not per-se the content of the posts themselves.

2. Building of a local AI spam-detection model

Taking this a step further, we would like to experiment with using TensorFlow Lite and Google Coral Edge TPUs to make a fully local model, trained on the existing decisions made by our moderation team. To stress, the model would be local only and would not share data with any third party, or service.

This model would analyze the contents of the post for known spam-style content and identifiers, and raise a report to the moderation team where it exceeds a given threshold.

However, we do recognize that this would result in us processing posts from remote instances and users, so we would commit to not using any remote posts for training unless they are identified as spam by our moderators.

3. Use of local posts for non-spam training

If we see support with #2, we'd also like to request permission from users on a voluntary basis to provide as "ham" (or non-spam / known good posts) to the spam-detection model.

While new posts would be run through the model, they would not be used for training unless you give us explicit permission to use them in that manner.

I'm hoping this method will allow users who feel comfortable with this to assist in development of the model, while not compelling anyone to provide permission where they dislike or are uncomfortable with the use of their data for AI training.

4. Temporarily limiting suspected spam accounts

If our heuristics and / or AI detection identify a significant risk or pattern of spammy behavior, we would like to be able to temporarily hide / suppress content from the offending account until a moderator is able to review it. We've also suggested an alternative idea to Glitch-SOC, the fork we run for furry.engineer and pawb.fun, to allow hiding a post until it can be reviewed.

Limiting the account would prevent anyone not following them from seeing posts or mentions by them, until their account restriction is lifted by a moderator.

In a false-positive scenario, an innocent user may not have their posts or replies seen by a user on furry.engineer / pawb.fun until their account restriction is lifted which may break existing conversations or prevent new ones.

We'll be leaving this Request for Comment open-ended to allow for evolving opinions over time, but are looking for initial feedback within the next few days for Idea #1, and before the end of the week for ideas #2 through #4.

On Feb 14th we migrated Lemmy from its standalone Docker setup to the same Kubernetes cluster operating furry.engineer and pawb.fun, discussed in https://pawb.social/post/6591445.

As of 5:09 PM MT on Feb 14th, we are still transferring the media to the new storage, which may result in broken images. Please do still reply to this thread if your issue is media related, but please check again after a few hours and edit your comment to say "resolved" if it's rectified by the transfer.

As of 11:02 AM MT on Feb 15th, we have migrated all media and are awaiting the media service coming back online and performing a hash check of all files. Once this is completed, uploads should work per normal.

To make it easier for us to go through your issues, please include the following information:

• Time / Date Occurred
• Page URL where you encountered the issue
• What you were trying to do at the time you encountered the issue
• Any other info you think might be important / relevant

tl;dr summary furry.engineer and pawb.fun will be down for several hours this evening (5 PM Mountain Time onward) as we migrate data from the cloud to local storage. We'll post updates via our announcements channel at https://t.me/pawbsocial.

In order to reduce costs and expand our storage pool, we'll be migrating data from our existing Cloudflare R2 buckets to local replicated network storage, and from Proxmox-based LXC containers to Kubernetes pods.

Currently, according to Mastodon, we're using about 1 TB of media storage, but according to Cloudflare, we're using near 6 TB. This appears to be due to Cloudflare R2's implementation of the underlying S3 protocol that Mastodon uses for cloud-based media storage, which is preventing Mastodon from properly cleaning up no longer used files.

As part of the move, we'll be creating / using new Docker-based images for Glitch-SOC (the fork of Mastodon we use) and hooking that up to a dedicated set of database nodes and replicated storage through Longhorn. This should allow us to seamlessly move the instances from one Kubernetes node to another for performing routine hardware and system maintenance without taking the instances offline.

We're planning to roll out the changes in several stages:

1. Taking furry.engineer and pawb.fun down for maintenance to prevent additional media being created.

2. Initiating a transfer from R2 to the new local replicated network storage for locally generated user content first, then remote media. (This will happen in parallel to the other stages, so some media may be unavailable until the transfer fully completes).

3. Exporting and re-importing the databases from their LXC containers to the new dedicated database servers.

4. Creating and deploying the new Kubernetes pods, and bringing one of the two instances back online, pointing at the new database and storage.

5. Monitoring for any media-related issues, and bringing the second instance back online.

We'll be beginning the maintenance window at 5 PM Mountain Time (4 PM Pacific Time) and have no ETA at this time. We'll provide updates through our existing Telegram announcements channel at https://t.me/pawbsocial.

During this maintenance window, furry.engineer and pawb.fun will be unavailable until the maintenance concluded. Our Lemmy instance at pawb.social will remain online, though you may experience longer than normal load times due to high network traffic.

Finally and most importantly, I want to thank those who have been donating through our Ko-Fi page as this has allowed us to build up a small war chest to make this transfer possible through both new hardware and the inevitable data export fees we'll face bringing content down from Cloudflare R2.

Going forward, we're looking into providing additional fediverse services (such as Pixelfed) and extending our data retention length to allow us to maintain more content for longer, but none of this would be possible if it weren't for your generous donations.

We've updated to Lemmy v0.19.3!

For a full change log, see the updates below:

• v0.19.0
• v0.19.1
• v0.19.2
• v0.19.3

Major changes

Improved Post Ranking

There is a new scaled sort which takes into account the number of active users in a community, and boosts posts from less-active communities to the top. Additionally there is a new controversial sort which brings posts and comments to the top that have similar amounts of upvotes and downvotes. Lemmy’s sorts are detailed here.

Instance Blocks for Users

Users can now block instances. Similar to community blocks, it means that any posts from communities which are hosted on that instance are hidden. However the block doesn’t affect users from the blocked instance, their posts and comments can still be seen normally in other communities.

Two-Factor Auth Rework

Previously 2FA was enabled in a single step which made it easy to lock yourself out. This is now fixed by using a two-step process, where the secret is generated first, and then 2FA is enabled by entering a valid 2FA token. It also fixes the problem where 2FA can be disabled without passing any 2FA token. As part of this change, 2FA is disabled for all users. This allows users who are locked out to get into their account again.

New Federation Queue

Outgoing federation actions are processed through a new persistent queue. This means that actions don’t get lost if Lemmy is restarted. It is also much more performant, with separate senders for each target instance. This avoids problems when instances are unreachable. Additionally it supports horizontal scaling across different servers. The endpoint /api/v3/federated_instances contains details about federation state of each remote instance

Remote Follow

Another new feature is support for remote follow. When browsing another instance where you don’t have an account, you can click the subscribe button and enter the domain of your home instance in the popup dialog. It will automatically redirect you to your home instance where it fetches the community and presents a subscribe button. Here is a video showing how it works.

Moderation

Reports are now resolved automatically when the associated post/comment is marked as deleted. This reduces the amount of work for moderators. There is a new log for image uploads which stores uploader. For now it is used to delete all user uploads when an account is purged. Later the list can be used for other purposes and made available through the API.

• Instance: pisskey.io
• Type: Defederation
• Affects: Pawb.Social, furry.engineer, pawb.fun
• Reason: Nazi imagery, affiliated with poa.st and other known abusive instances
• Fediseer Action: Censured

• Instance: the.asbestos.cafe
• Type: Defederation
• Affects: Pawb.Social, furry.engineer, pawb.fun
• Reason: Homophobia, harassment, trolling, admin involved abuse
• Fediseer Action: Censured

Block has been applied to the entire domain.