You can get it removed here:
bsky.app/profile/join...

It seems like some accounts don't have it and I don't know why though (maybe missed somehow during backfill or maybe the automation isn't working at the moment?).

Here's one that has a label for each month:
bsky.app/profile/did:...

By default I believe it just shows a badge (and that's its intended purpose) but... nothing stops you from selecting Hide instead for a particular month's label.

I don't think that lists from accounts that have been taken down still affect anything (might be wrong) but at the very least no new users will subscribe to the lists and block you.

From my understanding, if they are just showing as a DID in clearsky, that typically means the account that had the list has been taken down. This can be confirmed with PDSls.dev Labels section with moderation.bsky.app as the labeler DID/handle and the did in question as the URI pattern.

Also, are you still getting duplicate notifications?

That should have been fixed from what I understand:
bsky.app/profile/offl...

If it's still happening, I'm sure Skywatch would love to try to fix the problem.

It's also what's recommended by Bluesky:
"Before setting up your Ozone service you should create a new account on the network, separate from your main account."

github.com/bluesky-soci...

It would be fascinating to have a syndicated national newspaper of the best stories from college papers.

I think I preferred it when you selected the moderation service first and then selected the reporting reason. That seems to me like it would be the only way to have custom report types.

List creators and Bluesky already get enough conspiracy theories about their motives and how they're trying to "divide communities". Having follows disappear on block and not reappear on unblock would make that so much worse.

I just had a horrifying thought though:

If a PDS did process a block as a request to unfollow and actually did unfollow, then all of those false positive list additions that eventually get corrected would then be unfollow events as well.

The "authenticated" part of atproto would prevent the rogue part of that though, wouldn't it, so that only the actual account doing the blocking would be able to trigger the logic to make the change? I'd still worry the logic could be exploited somehow, like smart contracts are.

How about "Hail", in keeping with the atmospheric/from the sky theme of a lot of Bluesky/atproto tools.

Might not need that. The authors of 230 have indicated they're skeptical it applies in the past:
www.lawfaremedia.org/article/the-...

I believe any effect from other third-party services issuing them would require the receiving services to be set up to trust them in some way, see:
github.com/bluesky-soci...

The section on Takedown and InfraTakedown specifically.

And now that they have the power, users expect them to use it (e.g. see users wanting Bluesky to ban certain accounts, to moderate lists they find offensive, to take over third-party labelers entirely that they think are defamatory, etc).

and demands for more moderation from users now meant that they had to kind of become arbiters of the platform in a way they weren't prepared for and didn't necessarily want.

From what I've read of the origins of Bluesky/atproto, I believe that was kind of the intent but rapid growth of the single Bluesky app without others on the protocol keeping up, third-party moderation not materializing to the extent needed,

No donations (AFAIK), just hiring the maintainers for working on it instead?
fflabs.eu#:~:text=FFLA...