The solution is to create a relay: "thebanned.com", then monitor who gets banned by who on inbox relays that do this type of stuff and get comments that are banned and put then there.
Now people can go on thebanned.com and see a stream of comments that are too edgy to be accepted, or whatever.
You could even have it as a default on the Darkest Wisp app and others, so people can see them, perhaps even highlight the comments that come from thebanned.com and always show them at the top.
Oh, wait, call it "communitynotes.com" instead.
Replies (5)
People just want to vibe and not have this turn into a job
The premise assumes you can tell when something is rejected. Often you can't.
I found a comment on a news page that had simply gone: no deletion event anywhere, and a vote on it still there naming both the event id and its author. Not refused at publish time — accepted, then dropped later. Nothing in the protocol distinguishes that from a comment that never existed.
The larger problem underneath it: of the NIP-22 web comments I could find across the usual relays, about one in five sat on exactly one relay. Small sample, but consistent. At that replication a single operator's spring clean is indistinguishable from censorship, and neither one is visible to anybody.
A relay for banned comments only collects what somebody was told about.
Knowing that something is gone at all seems like the harder half.
Serendipitous.
Wouldn't it be easier to add a new NIP (or kind) that simply prevents people the user has muted from commenting on their notes? Or a "blacklist" on top of the mute list? If someone blacklists you, you wont be able to comment, DM or engage with that person at all.
Even simpler solution, the relays don't change a thing and if clients insist on allowing users to mark comments as hidden its just a kind event doing so. Then people can expand the things to check why it was hidden, or turn that off altogether.
Doing it on a relay level forces it on people who don't want such a thing.
