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.
Nice! I don't think it will be hard to implement if it passes, however:
> A kind 32123 event by the original pubkey overrides the labeling in the original event.
is a MASSIVE change to the way Nostr works (non-replaceable events don't get overridden). I hope this doesn't start a trend with overriding events or we will be back in the loosey-goosey web.
I think a Reaction-like idea where events can be reacted to is a more appropriate way of adding (and deleting) labels to an existing event.
I'm confused. Kind 32123 is definited as a parameterized replaceable event, isn't this how they are supposed to work?
"A parameterized replaceable event is defined as an event with a kind 30000 <= n < 40000. Upon a parameterized replaceable event with a newer timestamp than the currently known latest replaceable event with the same kind, author and first d tag value being received, the old event SHOULD be discarded, effectively replacing what gets returned when querying for author:kind:d-tag tuples."
Yep, the event can replace itself and that part is fine. The hard is that it "overrides" the labeling of the original event.
So, if this becomes a thing, one can design a new event kind that overrides Kind 1 texts, for instance.
Do you feel parameterized replaceable events are inappropriate in the context of labeling?
To be more clear… It only replaces the labeling of the person doing the labeling. It does not override the labeling put on it by other users or the original author.
Where I'm going with this is the idea of "trust" - where a user can say they trust certain people and only the moderation actions of those people (and the actions of the relays they pull from) can filter something out of their feed.
I explained it in a lot more detail here: https://s3x.social/nostr-content-moderation (though that hasn't been updated with what I did this weekend). And it's in line with a research paper that was pointed out to be by nostr:npub16zsllwrkrwt5emz2805vhjewj6nsjrw0ge0latyrn2jv5gxf5k0q5l92l7 which calls it "TrustNet".
Still. I don't think it's a good idea to create NIPs with event kinds that replace information in other event kinds. Replacing yourself is fine, replacing the original tags is not (IMO). Even if they come from the same author.
On the other question, the use of a replaceable event destroys the history of changes in labels (relays delete past versions of replaceable events). If we want to use this for serious businesses, it is likely that we will need to keep some historical context for auditing procedures. In that sense, a non-replaceable event structure (like reactions) makes more sense to me. You can save a reaction, you can save the deletion of a reaction, etc. All dates are kept.
