The requirement for paid relay owners to accept moderation reports from unpaying users feels to me like it's overstepping the mark. (Ok, I see now in the NIP it is a SHOULD not a SHALL, this seems more reasonable). Accepting events from unpaid users is a DDOS vector because checking the event kind requires parsing JSON which is relatively expensive for a server. Big relays will have to apply their spam and DDOS filters before checking the event kind. I'm not sure what that means legally. I'm curious what relay owners think about this nostr:npub1xdtducdnjerex88gkg2qk2atsdlqsyxqaag4h05jmcpyspqt30wscmntxy nostr:npub1h72rkut9ljnpdfyrcmw8q9jx52tgn2m8zyg0ehd6z236tz2vmg2sr5k5rt
I spent the weekend rethinking "NIP-69" that nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 and I had proposed. Based on some of the comments we had gottten I started with the idea of "labeling" and made the data needed for #ContentModeration just another type of labeling data.
That required coming up with a NIP for doing labeling. I made it so you can use _any_ coding system / defined vocabulary. Do you want to tag your posts (or someone else's) with some ISO code, or a GeoNames place ID, or some code from a structured vocabulary like MeSH? Or maybe you have your own defined vocabulary (like I do)… You can do that with what I'm calling "NIP-68". You can see it here…
https://github.com/s3x-jay/nostr-nips/blob/master/68.md
I'm hoping that NIP makes Nostr interesting to the scientific community. (It would be very funny if "the gay porn guy" kicked off the process of getting scientists onto Nostr.)
Then… I reworked our NIP-69 proposal so it's just a defined vocabulary for NIP-68 labeling. Actually it's two defined vocabularies. One is somewhat rigid, the other is more organic - anyone can just create a new moderation-related code and start using it. You can see my new NIP-69 here…
https://github.com/s3x-jay/nostr-nips/blob/master/69.md
It does have an impact on how things are done now. It deprecates both NIP-36 and NIP-56 and requires paid relays to accept moderation reports from unpaid users if the content being reported is on the relay. (Without that change relay owners may never know they have illegal content on their relay).
Client apps can keep their current "report post" UI (or enhance it with new features), but they will need to change the event that's sent from type 1984 to type 32123. The few apps that are using the reports to filter/block what their users see (like nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z's Amethyst) may need to make more more substantial changes (but they may want to wait, since this isn't the end of the suggestions regarding content moderation).
I'm still discussing with Rabble the best way to present 68 & the new 69 as Nostr PRs, but that will probably get done in the next day or two.
Discussion
I'll change the wording so it's a bit more flexible. That relays who say they support the (optional) NIP must have the _option_ to allow unpaid users to submit moderation reports related to content on the relay. And should have that option on by default, but may give relay owners the option to disable the feature.
My server is DDOS protected. 😁 Hell, even my DNS is DDOS protected. Though DDOS protection only protects so much. It wouldn't stop someone from slowly eating up a lot of database space with lots of events that have garbage stuffed in `content`.
The issue is a legal one. Right now if I have CSAM on my relay I could serve it to an unpaid user but I wouldn't see their report, and hence there would be no way for me to know I have a legal problem.
I have a rather large list of IPs I block that gets updated regularly. It's just part of being a webmaster. I'll add attacks on my relay to the types of things I monitor and block.
Is this better?
> "For a relay to say it supports this NIP it MUST support the ability for unpaid relay users to submit kind 32123 events that have `vocab` values of "MOD" or "X-MOD", and are related to content on the relay (`e` tag equal to an eventID in the relay database). That ability SHOULD be on by default, but MAY be turned off by the relay webmaster."
Support for NIPs is optional - so not it will only affect relays that want to say they support the NIP…
Btw just fyi 32123 was used by wayman app by wavlake
Was or is? There really needs to be a better list of who’s using what.
That said - does it really matter? If the `d` tags aren’t the same they probably won’t affect each other.
That said, it’s cleaner if it’s on its own kind.
I had asked Google for a random number and it gave me 32144. And it made me think 32123 would be better. So I switched. Maybe I’ll go back to 32144.
Idk, this doesn't seem better to me, just a wordier way of saying the same thing haha. I think it's better to leave it as you had it, or just remove it altogether. IMO this NIP doesn't need to address achieving legal compliance - NIPS are about the semantic meaning of event data. So while I agree that relay owners SHOULD do this, it seems outside the scope of the spec. At least that's my opinion - don't take it too strongly. You are right, NIPs are all optional so it's not forcing anyone to do anything.
I think reports are special and relay owners will have to accept them one way or the other from non paying users, so why not implement it at the relay level.
If relays are not hosting media files directly, I fail to see how they could be hosting illegal content requiring active moderation. Sure there are a few (invalid) exceptions globally, however any text that can be made illegal could be tomorrow’s “100% vaccine effectiveness” truth-speak; courtesy of your local ministry of truth.
It’s not subtle, but if you look carefully, it’s suddenly changed from “explicit content warnings/tagging”, to “scientific community labels”, to “moderation of illegal content” for relay operators. It’s an attack on all things Nostr stand for.
If anyone else here can’t literally see the censorship motive and outcome here… not sure how much clearer it could be.
Nah, if it's an attack on anything it's on people who want no consequences for their speech. Nostr is about freedom of listening as much as freedom of speech, and choosing a moderation strategy is an exercise of that freedom.
I fully support greater client app controls on the content they see and ingest. People can tag their published content with whatever. The problem is if content never gets to devices (or opt-in pre-filtered) to enable client choice - there is a hidden censorship layer.
The proposal above however did not state the above as a goal, nor core value.
Instead however it talked about labelling content specifically for moderation, ransoms making decisions about the legality of content, and relay operators complying with special events no different to the fraud filled DCMA takedowns we have today.
There is nothing novel about this idea or concept. It’s the same unworkable, easy to fake, hard to validate problem with all moderation today.
"It's the same unworkable, easy to fake, hard to validate problem with all moderation today". It's true that you have to do some trusting of relay operators. That's part of the Nostr protocol though and it's probably never going away. If you don't want to trust relays then you need to put your events in some of merkle-DAG, like scuttlebutt, AT protocol, p2panda, and others do. It's been tried, and it works, but it comes at the cost of simplicity because it introduces lots of problems around deleting content, verification of the DAG, and cross-device identities. Nostr's power is it's simplicity.
This *is* better than moderation on all major social platforms because you get to choose your client and your relays. So even though there is trust involved you get to choose who to trust, which is a lot of power. If you want a trustless system you need to find another protocol. This is actually a big criticism of Nostr from some of the p2p social protocols.
Sounds fine. Thankfully we don’t need Nostr to be trustful.
I don’t trust relays. The beauty is they are actually in competition. If they don’t let you easily lookup profiles, replies and threads, it feels like they aren’t working at the user UX level.
My main concern was instead the expectation that we should trust decentralised reports and/or moderation events - which is different.
As a decentralised network, Nostr has censorship resistance properties - however it has a single major fault. Due to all content being hash addressable (an event id or pubkey), it now means to moderate the exact same content or identity, you target this single hash and broadcast bogus reports to all relays.
In effect it’s cheaper moderation than today, where the same content is not linked across platforms with hard references. And we already know US officials email Twitter to suppress tweets with hesitation - it’s not just theoretical.
Market incentives exist to build both general and targeted bot identity farms, to slowly get followed by interacting with you, and posting targeted content to your Nth degree network too. At some point your immediate network becomes 5-15% bots. Your 2nd degree network becomes not 5-10 people, but 50-100+ imposter bots. They now can control what you see using trust thresholds - and it’s hard to detect or notice it’s even happening to begin with.
Now, let’s say I run a Nostr Web Store selling digital goods. Imagine if my shop competitors can now buy or lease an bot identity farm, targeting my current or future customers. They could abuse reports, create fake product reviews, and so forth.. my competition now steals my business away. It could be really subtle too.. barely noticeable at first.
The state has unlimited money. I can already generate 22,000 identities and events/second on my laptop. Twitter, Facebook, LinkedIn use KYC and still has a major bot problem - ironically KYC acted like poor man's CAPTCHA, and kept virtual identities from exploding. That still doesn't work however, as if you go to India or a country with 1B+ population, and just piggy back off their SIM card 'mobile number as KYC' - you can still create mass virtual identities. Being an Indian SIM doesn't mean your profile has to be Indian, or for anyone to else to even know... It's a failure of mobile KYC as proof of identity - but also shows how trusting even centralised identity’s is a extremely problematic.
You also can't ban VPNs from publishing events, as people need them for protection. That means you can't rate-limit IP addresses. How do you propose, at this scale and volume, you can make any decisions from the data - when it can all be spoofed, targeted censorship, and so forth.
nostr:note1rw7rzq6c7f6x9r59677xp9c5p8ueu22vrcavfnsqkyrzjf8e04jq8vgmx0
What you’re describing is content moderation spam. You deal with content moderation spam the same way you deal other forms of spam. In what I’ve proposed if you don’t specify someone as being one of your moderators, you never get affected by their moderation reports. No one can filter your feed unless you agree to it in one way or another.
The only people who will need to interact with the spammers are relay owners. But that just comes with the territory.
Spam is typically two forms. Annoyance and a scam to extract money for idiots or the unfortunate. I’m less concerned about those in general.
I am far more concerned about targeted and malicious coordinated attacks being performed. General spam isn’t dangerous - however the fake hostage phone calls with your daughters voice are. And governments and or malicious actors can 100% no question abuse decentralised moderation. And even people who don’t like you - why, because computers can report faster than humans. Moore makes that law..
I haven’t read your latest proposal in full, so I’m commenting in general around approaches and trade offs.
It sounds like instead, you’re after centralised moderation or curation. Both are asking someone else to make decisions on what you see and don’t see. Again, I don’t see that requiring any protocol level changes… you can do that all on a layer 2 moderation layer above. The important part is it’s opt in and transparent.
My reply earlier to another of your replies states how this is easily possible.
And I’ve even considered how Proof of Work report events could help. Game theory says they can’t because the market dynamics don’t match incentives.
For example, when a bad event costs 1 unit, the report has to cost at least 1 unit too. But many reports are made, like votes, to try surface moderation sooner - or even just lack of information it has been reported (bifurcated network visibility).
That means for each 1 bad event, you have 1+N cost to report it. Spam wins, as the cost is equal at best, but more likely expensive to report then create.
And even if you think that can work, who is coving the cost of the reporters? I was processing 15 million spam events per day until recently. Near zero cost to create, and non-zero greater cost to counteract = clear loser.
Interesting… Sounds like a solution that would help relay owners deal with floods of bad reports.
I’m not a crypto guy and don’t really understand how the PoW part of Nostr (NIP-13) works. Can a relay owner turn that on for just moderation reports? The idea is it slows down the reporting, right? Is POW done for every relay they send to? What happens if they use a blaster relay? How does the relay tell the user PoW is required and what level of difficulty?
I’d be happy to add that to NIP-69 if I can get my head around how it works.
Again - we’re more on the same page than you might think.
I've created a presentation about spam/abuse some time ago here spam.nostr.band, could you guys take a look and disagree, please? I have opinions around PoW etc but that link should give a more complete picture.
I looked at spam.nostr.band… I see existing strategies (e.g. "follower networks") plus NIP-69 (user-specified moderators → feed filtering) as solving the spam issue for users - except perhaps in their "global feed".
Public relays have a big spam problem. You've devised some strategies for that, I'm sure others have as well - but that's beyond my personal area of interest or expertise. (Though I am curious to hear what works.)
Paid relays will have a problem with moderation report spam since it's a catch 22… If they make it so only paid members can file moderation reports, then they have a legal problem. If they make it so anyone can file a moderation report then they have a potential spam problem. They can start by ignoring reports about content that's not on their relay. But they can still be spammed. Which is why I'm so glad nostr:npub1ktw5qzt7f5ztrft0kwm9lsw34tef9xknplvy936ddzuepp6yf9dsjrmrvj mentioned PoW as a possible solution and want to understand that better.
Beyond that - I would look for unusual patterns of reports. First, take out the reports from people (and bots) you trust to one degree or another, then…
- Are there a high number of reports about the same piece of content?
- Are there a high number of reports from the same IP? (use /64 for IPv6)
- Are there a high number of reports from the same pubkey?
- Is the report from a new pubkey?
I monitor for (non-Nostr-related) attacks on my server now. Everything from SQL injection to blog comment spam. It's all IP-based. I look for "bad neighborhoods", so if there are too many IPs with infractions in the same subnet, I block the entire subnet. (More easily done with IPv4 than v6.)
I think pubkey age is a great metric. I see Primal has that data. You probably do as well. That's valuable data! I'd love an API that could be hit to query on the age of suspicious pubkeys. In exchange relay owners could probably give you hashes of IP addresses without compromising privacy laws - so you could answer the question of whether pubkeys are coming from the same IP (without knowing the IP).
User-specified mods would 'solve' spam for people if the mod is software and works very fast, so that client wouldn't have to show all those events to user only to drop them later after a human mod intervenes. Human mod is needed for a very high level stuff that's hard to categorize by a machine.
And if we have such fast mod software (let's call it what it is - a spam filter) then we can also apply them on the relay as well, so repetitive reports would pass through the same AI-powered filter as all the other stuff. Don't see why that wouldn't work for spam/abuse at relay level if it works at user level.
If someone's goal isn't spam (achieving a goal by pretending to be a legit thing), but is pure destruction (take down a relay), then it's not spam, it's DDoS, and PoW could help, although it's not a complete solution - LN paywall at the protocol level should work better, bcs a) it would sponsor the relay, not the PoW miner, and b) it would work for both reads and writes.
The second half of your post is about implementation details of a potential spam filter, those are all good points, but I'd say spam-protection professionals are needed here, and AI will be absolutely required to fight chatgpt-generated spam.
Generally agree, definitely like the way you’re thinking. Two thoughts though…
Having an LN paywall on the relay recreates the problem I was trying to avoid… I’m not sure it’s legal to require payment to report content problems. e.g. a copyright holder shouldn’t have to pay someone who’s violating their copyright. But PoW isn’t payment, which is why that might work.
But then there the problem that PoW is really slow in browsers (see screenshot below). It can’t take a full minute for browser-based users but be instantaneous for bots on servers. That makes no sense. 
Agree that direct LN payment might be a legal issue. Maybe the fact that _any_ interaction with a service requires micropayment would make it a non-issue? Or maybe a spam filter could just whitelist common big copyright reporters, and keep enforcing LN on everyone?
PoW only seems different, but practically no app would use user's device for that, PoW mining services would offer mining for a small payment (Blake is working on one), and apps will integrate those if network requires PoW. There is no way a normal user could compete w/ spammers on PoW, unless they can just buy from a provider. And so small reporters would have to use micropayments for PoW anyway.
I think we might be overthinking it a little at this point. Too much is unclear about how nostr evolves.
Please read the latest commit to the PR. We’re on the same page. Nothing is centralized.
https://github.com/nostr-protocol/nips/pull/457/commits/724e05e762a634e501bdcf6cbefaa91f99b1903b
In fact Rabble had me look over Bluesky’s content moderation model and my comment was that it sucks because it assumes a central moderation team that “resolves” reports. (No one can definitively resolve anything in a decentralized environment.)
Regarding spam. I’m expecting DDOS style attacks by haters who want to silence people. (I’ve already had death threats on Nostr. This is personal for me.) Those DDOS attacks are possible now (especially for getting someone muted on Amethyst). It’s one reason why I’m pushing for a complete reboot of the content moderation tools.
NIP-69 now clearly states that clients should only act on reports by “people” designated as moderators by the user. What that means is DDOS attacks are of little value. They’re like shouting into a void - no one’s listening. They’re only really a problem for relays, not end users.
Censorship is an act of exerting power over someone else. Everything that’s being proposed is voluntary. Ergo, it’s not censorship.
Show me where someone is being forced to do something.
“It _deprecates_ both NIP-36 and NIP-56 and _requires_ paid relays to _accept moderation reports_ from unpaid users if the content being reported is on the relay”.
Your words. Literally.
It doesn’t ‘deprecate’. It offers an alternative.
Relays aren’t ‘required’ to do anything in a NIP. And to ‘accept’ reports…
Everything that can be done with NIP-36 & NIP-56 can be done with NIP-68/69. It makes no sense to have competing methods of doing something as basic as reporting illegal content.
They won’t be the first NIPs they have been deprecated. NIP-08 is deprecated already - and that was also a really basic function where it was counterproductive to have multiple ways of doing it (mentions).
Only NIP-01 is mandatory. No one is forcing any relay to implement NIP-69.
Deprecate = "to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative"
Yes, it "offers an alternative to", but by 69 saying it deprecates 36 & 56 - what that means is that the approval of 69 will result in the deprecation of 36 & 56. I don't see why anyone would want multiple competing solutions for this.
All deprecate means is that 36/56 are losing "favor". There's nothing about them that indicates that they were particularly well thought out. They checked a box that was needed by the App Store. It was "good enough" for the moment, but we've moved beyond that now.
Do you think it's worth making a new type of message with relays (as an optimization)? Like instead of sending ["EVENT", {event JSON}] a client might send ["REPORT", {report event JSON}].