There's more to it than just letting them age… Right now no relay owner knows where to start with Kind 1984 events to do content moderation because there's no structure to the reporting. It needs a vocabulary of likely problems so relay owners (and others) can zero in on the ones that are most important to them. That's what #[5] & I proposed with "NIP-69"…
https://github.com/nostr-protocol/nips/pull/457
One thing that I mentioned in there is that if someone forgets to put a `content-warning` on their post (NIP-36) that a NIP-56 report after the fact could serve the same purpose, but not if Amethyst is going to punish them for it!
Someone else proposed that the NIP-56 reporting system be converted into a generic "labeling" system so it's less about censorship. But that means Kind 1984 could be used for a lot more than content takedowns…
https://github.com/nostr-protocol/nips/pull/459
There's a whole discussion going on about content moderation right now and it could use the input of more people - 'cause what we have right now doesn't work.
If Amethyst is already filtering based on reports - I would suggest there be "Trust Lists" that work like follow and block lists. Reports only get acted on if someone on your trust list issues the report.
I may want to follow someone who's on the opposite side of the political spectrum, but I don't want them moderating my feed!
This is why #[5] and I proposed "NIP-69". The reporting system is basically broken / non-existent. There needs to be more structure in the reporting system. Some people/communities could care less about certain types of reports while others are super sensitive to things.
Having a one-size fits all and based on people you follow is just wrong. It punishes the people who follow people they don't agree with. Following someone doesn't mean you want them to moderate your content for you!
You actually have the power to make NIP-05 mean something… Just start treating the relays that are listed in NIP-05 as mandatory. That would serve a variety of purposes…
1) The user can make sure the relays they pay for never accidentally get dropped from use if they get them listed in the NIP-05 relay list.
2) Organizations/companies that use NIP-05 to validate that the person is part of their organization can mandate their relays be used so they can monitor what's said using their official accounts. (If you don't like that - don't get verified with them - or temporarily switch or disable your NIP-05).
When you think about it the NIP-05 relays can't be changed by the user (unless the user controls the domain). So it was written to give the domain owner, not the user, control over that particular relay list (whether it was intentional or not). That's actually it's advantage over NIP-65.
After sleeping on it I’ve kinda changed my mind. I’m now favoring #[2]‘s approach. It gives accessibility options and if the file is changed or goes missing (404) then the relays can be queried for another URL for the same file. That’s kinda major. That to me is backwards compatibility and worth the hassle of the change.
Iris and Snort.social are the two best web clients.
I see a bracketed zap on your profile. I don’t see it on mine though. 
Oh please no!
Files do not belong on relays! Find some other solution and have Nostr support it. But no files on relays!
Nostr doesn’t need to go absolutely everything.
There’s also utility in emoji reactions. A 😈 means something very different than a 😡.
I’m really surprised more clients don’t support emoji reactions.
I still don't get why Web SRI was not part of notes. Any href references outside of nostr benefits from an integrity check.
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Does anyone use that in real life for images or is it just for script/css files?
Use block when someone you follow follows someone you really despise and it gets into your feeds as a result. Don’t block people in global feed. It’s pointless.
Think about how easy it is to get a new public key. Of course the maximum impact is when you have followers, but relay operators have to deal with the guys who are basically doing the Nostr equivalent of DDoS attacks.
It’s trivial to get around this… could just post a profile event and post each time on a random key.
Exactly. The IP of the spammer (/64 for IPv6) is more important than their public key. But for a professional spammer even IP isn’t an obstacle. And the issue is that you can’t hold bad behavior against the IP for too long. It needs to age off the ban list.
Use a client that caches the images. (Most of the popular ones do - at least to some extent). That way you’re retrieving the image from the server you can’t get to.
Or use a VPN.
Oh… Hmmm… So yeah, if that wasn't there yesterday when you deployed NIP-94 support, then it changes things a bit.
I'm kinda in the middle of the debate. I get where you just did an embed in a Kind 1 event (a pretty reasonable way to implement it). But I get where others are saying "don't mess with images" (because they're such an important part of the interface).
And I get your accessibility arguments, though I wonder how often people will include enough detail to help with accessibility (people are lazy). Still, there's the ADA and sites can be fined for not handling accessibility issues - so you at least letting the blame fall on the users rather than the apps seems like a good approach.
And I get where knowing if a file/image changed is important - but how often is that an issue - especially for a casual pic in a social media post?
The short version is that NIP-94 says "NIP-94 support is not expected to be implemented by "social" clients" and someone put support for it in a social client and all hell broke loose.
NIP-94 is not the first time NIPs have been implemented weirdly.
For example on something as basic as relays - pretty much all clients say they have support for NIP-05 - but do any of them really properly handle the list of relays that's part of that NIP? It's as if those relays are ignored and the only relay list any client looks at are the NIP-65 relays. IMHO, that's wrong.
I get how NIP-65 is important, but IMHO NIP-05 relays should be the ones that are hard coded and NIP-65 should be presented as optional/editable add-ons (if not redundant with the NIP-05 relays). The client can't set the NIP-05 relays - they're set by the website authenticating the user, so they should always be used and never deleted from the user's relay list. But what client does that?
For example NIP-05 validators should be able to enforce the use of things like #[3]'s #[4] - or ensure that their own relay is used by the user. (When corporations start using Nostr they're gonna wanna make sure all their employees' Nostr messages go through their relay).
#[5] #[6] #[7]
The answer to the NIP-94 debate is in the first paragraph of NIP-94…
> NIP-94 support is not expected to be implemented by "social" clients that deal with kind:1 notes or by longform clients that deal with kind:30023 articles.
I get #[0] 's point…