Oddbean new post about login | logout Child porn is what I'm referring to
Yes, CSAM posters already post to the main nostr relays
They are allowed to write on the Internet. Relays aren't hosting the images.
They *can host the images, but most public relays are not going to accept them. And if they do they will be quickly banned and removed.
The relays are hosting the media directly, rather than only the events containing the links? Or do you mean that someone might store the media on the same machine as the relay?
NIP-95. Relays can store media directly although it's deprecated
LOL, that would have killed Nostr off.
Geez. Imagine if people were storing their kiddie porn on our cell phone relays.
Data URLs are still a possibility for store binary, unfortunately, and some clients render them.
Eww. @Michael J we need to watch that. @cloud fodder can we filter such events out?
We could probably pass everything through a filter layer client-side before downloading.
Could NKBIP 01 or 02 offer an attack vector?
Possibly, especially if indices reference external URLs.
Okay. We need to preclude this.
Maybe we can run external URLs (as opposed to event IDs) through a content scanner that automatically blocks suspect images or sites.
Seems almost Aedile-worthy.
@ChipTuner what do you think? Where/how should we solve for this?
Client code can always be bypassed. If were talking hiding content from dirty relays for the majority of users yeah I this would be pretty useful! In the case of aedile, we maybe could add a toolkit/utility that can filter this content if it's fetched from a dirty relay. I don't recommend opinionated libraries so I think it should be left up to the application builder to decide how they want to handle this because csam stuff casts a wide net that is constantly expanding. I've been thinking of the architecture more and how we might be able to implement a "pluggable" event filtering system which I think would be pretty neat, kind of similar to how Grain's kind handlers are implemented.
An event data validator?
Could it be both for clients and for relays?
Well, I suppose those would be two different functions receiving the data, but couldn't we create an event validator system that could be customized? Like symfony has? I think one of the other NDKs did something like that, but on a simpler/smaller scope.
I agree that it should be voluntary, but it seems like a core-library-level function that we should be offering in our NDK package, even if it's a separate repo/tool. It's data validation will be beyond the abilities of many people using our NDK to build. You see how many apps just accept any garbage.
Totally cool with that yeah, just having tools available for developers to choose to filter/moderate content within their clients to offer some protection from rogue relays. I kind of like that too I suppose. It gives client devs the ability to pass that power to the user if they choose.
That would be a real value-added.
Community guidelines for writing to and broadcasting to our relays. Being a smaller focused community, moderation should be managable. I think that's a fair ask for anyone using our products. Also fair to ask users to help curate and identify content that is irrelevant or doesn't align with our standards.
you can make sure kinds 1064 and 1065 are disallowed, to prevent nip95s
Could they coopt a different kind's content field?
sure, anyone can use a kind if it's allowed in there by the ACLs.. but it's less likely. This is why I'm adding some metrics into the trex. Already showing kinds (last 30 days) and then a count of last 24hr. This will come with charts #soon.
You FOMOing into Grafana or Kibana or...?
the stats are in influxdb, which i will render using chart.js or etc. thats where those kind counts are already pulling from.
limiting event size seems a good measure against that, i mean they're not going to store a high res photo in say, 32kB of b64 encoded data
Yes, useful, but we keep having to raise event size limits for OtherStuff.
yes i know the pressure, imagine how difficult it was to keep the bitcoin block size down to manageable levels😀
Found it! https://github.com/nostr-protocol/nips/commit/a090de2b90f9fd83e49fa39ff4c7ef52750e904b Next commit moved it to a new branch
I think the trickier question to answer, is whether concerted campaign could hurt a commercial relay? Reading this thread made me wonder if paid relays will ever work. My reasoning goes like this. Everything that's been said applies to free relays, but what happens if a commercial relay is targeted? A lot of paying customers won;t want to pay for a relay with that reputation, so there is a good incentive to target paid relays this way.
Having a reminder in the docs "do not pay extortionists, ever" might be a good idea, reduce the incentives to attack and prevent a financially-motivated attacker from getting a self-sustaining operation going. It will remain a risk, though, just like there are ideologically-motivated attackers who dDoS Tor at their own expense bcoz "free speech is right-wing extremism" etc.
But they have to pay to attack.
And you think nation states won't do that?
It's the same game theory as Bitcoin. Attacking it means paying the people that run the things... It's a futile effort. There are much easier things nation states can do to target specific relays. Again, it doesn't effect nostr if one relay goes down what's.
As you said that I was wondering whether the #GFC admins have figured out how to block #nostr #relays by protocol behavior as they've done with #signal. From what I've read it depends how simple the protocol is. #xmpp is hard to block even for China because it's so simple, but most others are a done deal already.
nostr is extremely simple. It's all just json being passed around websockets