Thread

They don't need NIP-95 for that. You can simply send large kind 1s.

On my to-do list for tomorrow… Add Kind 30064 to my relay’s blacklist… Problem solved. No CSAM on my server…

🤷‍♂️

Kind 30064 is NIP-95 files. Given that I run an explicitly sex and porn-friendly relay I don’t want to run the risk of actually hosting child porn.

Good call. But NIP 95 is not your main problem. I assume you know that people can do this with any event kind. If they just want to turn your server into a storage of illegal content, they have all the nips available to do so. I would target the intention, not the tool.

When it comes to getting hauled into court intent matters. I can document a track record of working to prevent the dissemination of CSAM and other illegal content. Rabble and I proposed “NIP-69” as a first step to get workable, bottom-up content moderation on Nostr. Just today I somewhat publicly challenged the ASACP (the porn industry’s organization that fights CSAM) to get involved in the content moderation questions related to Nostr. I asked them to make statements supporting your approach to NIP-94 and to oppose NIP-95. I’m doing my part. My intent is clear.

And done. Kind 30064 has been blocked on relay.s3x.social. I thought briefly about just specifying a really small size so it could be used for things like animated emojis - but then I took a look at how much you could show in a small file and I figured that was a bad idea as well. The pic below is only 21kb and it shows plenty - enough that if the content were illegal it would be a problem. Let people put their CSAM on someone else's relay!

Can Amethyst add anything in the upload interface to help you?

Wrong kind, though. 30064 was in an old version of the NIP. The current ones are 1064 for file headers and 1065 for the actual base64 data.

Thanks! But isn't it the other way around? > Another defined event is the `1065` which is used as a header for the data contained in an event 1064. This way the data can be disclosed without overloading the communications when sending a large amount of data. Is there any point storing the header if you're not going to store the data?

Somebody else can store the data. That's the beauty of Nostr: Clients need to figure out where things are :)

Thanks! But isn't it the other way around? > Another defined event is the `1065` which is used as a header for the data contained in an event 1064. This way the data can be disclosed without overloading the communications when sending a large amount of data. For now I've blocked both. Is there any point storing the header if you're not going to store the data?

Thanks for asking (seriously). I'm not a lawyer, but having been in the adult industry for ~15 years I've learned a thing or two… The problem is if you're hosting adult content (images/videos, it's not really an issue with text) you need proof of consent and proof of age (plus the proof ownership or license to use that you need for all content). The site doesn't always have to have proof of consent / age on file, but it does need to confirm that they exist. For example - take a photo of someone else on a beach and upload it to the Internet - no problem - it's a public place and there's no expectation of privacy. Do the same thing on a nude beach and you need proof of age and proof of consent. The moment you host something without at least a nominal check of age and consent you open yourself up to all sorts of problems. The laws on CSAM and things like revenge porn are really strict and the penalties are often harsh. Big corporations get away with more because they have teams of lawyers. But a single significant legal incident can put a small company out of business. I've got over a million unique images in my porn database at the moment (and probably another 600K or so I need to import). It's terabytes of data. And if I've learned one thing dealing with those is you don't store images/videos in databases - you store them externally. @nothenry had suggested an approach where there was a more traditional POST to submit the image/video. That's something I could consider. But then it gets to your interface question - I'd need some sort of confirmation of: - ownership/license - consent - age But it's one thing when someone confirms those things on my site, but it's another thing for me to trust a 3rd party to confirm those things. Maybe… But I'd have to think about it some more. But at the end of the day storing images/videos in the relay database is a non-starter for me even with all the documents in the world. I know better than to do that. Which is why I love NIP-94, but not NIP-95.