PLC Filtering for Mirrors - guidelines, rulesets, and experiences

Discussion
1

The PLC gets a lot of, shall we say adversarial operations, junk accounts and content. My analysis shows there are two broad classes

  • PDS doesn’t exist (pds-trump-com)
  • images chunked and embedded into operation payloads

This impacts the resources required to run PLC mirrors, as several of us do now.

I’m starting this topic is to relay our experiences, share our filtering rules, and craft guidelines for various schemes to running a PLC mirror.

7 Likes
2

My experience was checking on the disk usage of my machine and noticing the PLC database had doubled in size (July ‘25 timeframe). I did some digging and discovered around half the PLC operations were bogus. Below is a graph of the labels I applied to the operations (determined through manual inspection and rule crafting.

The two biggest sources are by far:

  1. Images embedded into PLC operations. This is supposedly originating from someone in the Nostr community. I heard this through word of mouth, supposedly there is a post out there somewhere describing how to do this, perhaps code as well. More recently, an app was created to demonstrate this method ( @tree.fail on Bluesky )
  2. Invalid PDS domains, most notably pds dot trump dot com, which spams legitimate operations with the Chump entourage as a list of alsoKnownAs

I currently keep all operations (so I can make pretty pictures of mean people’s behavior), filter while ETL’n into another table, and make this configurable in my atmunge tool for others who run a PLC mirror with the tool.

Links into the atmunge repo:

Screenshot 2025-07-08 at 12.45.57 PM
Screenshot 2025-07-08 at 12.45.57 PM1236×964 81.6 KB

2 Likes
3

It feels like it’d be reasonable for PLC to only accept requests where the service is able to verify that a PDS actually lives where indicated.

Likewise, it seems reasonable that the PLC would limit the size of fields & validate their contents to prevent it from being abused as an arbitrary free blob storage service

4 Likes
4

Full agree. And I like the framing that this is a did method concern, rather than a [per-] directory concern– at some point there needs to be a “network covenant” of some kind (whether in the DID method spec or at some other layer of federation) that defines behaviors for which a PDS or #identity event emitter should be banlisted by any directory, rather than having this be reinvented divergently by each stander-up of a directory. transitioning to a rule-driven system where anyone can stand up a directory and have confidence they’re not splintering the network would actually make this a deterministic VDR instead of a central directory with “replicas” forking its recordset with no guarantees… big thanks for open-sourcing your efforts in that direction.

2 Likes
5

It’s not made recently, what Tree posted is exactly what was used to make those operations before, see: @mackuba.eu on Bluesky

2 Likes
6

I think there’s a quote there that was referencing Bluesky posts from some Nostr guy who was talking about his idea, but he ended up deleting some posts (or mabye whole account) when we started talking about this

1 Like