crashdoom

joined 1 year ago
MODERATOR OF
[–] crashdoom@pawb.social 2 points 1 day ago (1 children)

👋 This isn't just you! We're aware of the issue and believe that the latest version of Lemmy should fix it; It seems to be an issue with the cookies being set with Strict instead of Lax causing it to not be sent by your browser.

Full announcement for maintenance to perform the upgrade: https://pawb.social/post/14286683

[–] crashdoom@pawb.social 3 points 1 day ago (2 children)

👋 Apologies for the late reply, but we have been investigating and believe that this isn't an isolated case.

It initially appears like our database is being overloaded due to the vast queries that Lemmy runs for generating statistics, so we're trialing a hardware upgrade for a new database server backed by NVMe drives to hopefully improve the throughput.

We're not quite ready to go live with it yet, we're still ensuring everything is in working order and the database replicates successfully from the live copy to the new database reliably.

We're hoping to have this in place before the end of September and we'll post an announcement for maintenance when we go to do the switchover, as the change will also affect furry.engineer and pawb.fun.

[–] crashdoom@pawb.social 4 points 2 months ago (1 children)

Should be fixed now, if folks could give it a try again!

As a test, have a picture of a sandwich!

[–] crashdoom@pawb.social 2 points 5 months ago

US Mountain Time! (I put that on the other posts, but forgot here, my bad!)

Maintenance will typically be as needed, but I think I’ll need to make a new poll for capturing weekend / weekday preferences, I hadn’t thought about differentiating that.

[–] crashdoom@pawb.social 3 points 5 months ago

Case 2 - Overnight (10 PM to 8 AM)

[–] crashdoom@pawb.social 6 points 5 months ago

Case 2 - Evening (5 PM to 10 PM)

[–] crashdoom@pawb.social 6 points 5 months ago (1 children)

Case 2 - Daytime (8 AM to 5 PM)

[–] crashdoom@pawb.social 2 points 5 months ago (4 children)

Case 2: Interactive Maintenance Poll

[–] crashdoom@pawb.social 7 points 5 months ago

Case 1 - Daytime (8 AM to 5 PM)

[–] crashdoom@pawb.social 5 points 5 months ago

Case 1 - Evening (5 PM to 10 PM)

 

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
 

cross-posted from: https://pawb.social/post/3393854

  • Instance: cunnyborea.space
  • Type: Defederation
  • Affects: Pawb.Social, furry.engineer, pawb.fun
  • Reason: Racism, antisemitism, homophobia, abusive admin, nazi imagery
  • Fediseer Action: Censured

Evidence

 

cross-posted from: https://pawb.social/post/3337642

  • Instance: bv.umbrellix.org
  • Type: Defederation
  • Affects: Pawb.Social, furry.engineer, pawb.fun
  • Reason: Toxicity, abusive admin, death threats, emotional abuse
  • Fediseer Action: Censured

Evidence

Admin Note: This block applies to the root domain (umbrellix.org) and all associated sub-domains.

1
liberdon.com (pawb.social)
submitted 11 months ago* (last edited 11 months ago) by crashdoom@pawb.social to c/fediblock@lemmy.dbzer0.com
 

Cleared The Shifting Oubliettes of Lyhe Ghiah with a group of four, hitting every single exclamation mark (though two were secret sweeper trolls)!

Love the fact the devs are willing to troll you. FFXIV is awesome XD

 

Important Update

We’re going to be setting up a fork to maintain some separation, add additional features, and remove references due to raised concerns.

So, we will not be changing software, and will be continuing business as usual.

We've forked the repositories and they can be found at these URLs: https://github.com/PawbSocial/lemmy and https://github.com/PawbSocial/lemmy-ui.

You can follow the instructions at https://join-lemmy.org/docs/en/contributors/02-local-development.html for setting up a local development environment.


[ original post continues ]

Hey everyone!

We received feedback that raised concerns regarding the apparent moderation and censorship issues around lemmy.ml, and allegations made by Feditips about the Lemmy developers.

We'd appreciate some feedback from users of our community (users here, or on the Fediverse), furry.engineer, and pawb.fun.

As it stands, we have defederated from one of the more prominent problematic instances, lemmygrad.ml, but haven't taken any action against lemmy.ml.

So the question stands: Should we continue running Lemmy, or swap to an alternative?

The currently considered alternative would be kbin.pub (example instance: kbin.social) which shares being a FOSS project with full ActivityPub support.

If we continue to run Lemmy, we wouldn't be opposed to having a forked version that removes certain elements from the UI, such as the donate icon, but, we would require community assistance to maintain this fork.


Receipts:

view more: next ›