Oddbean new post about login | logout 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