I have a question for #amethyst users. I'm not asking this to dish on nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcppemhxue69uhkummn9ekx7mp0qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpqgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqss2dqr , but only because his users are my users, and I care about my users' (for lack of a better word) "safety" on nostr.
Currently, when you report something, Amethyst does two things:
- Publishes a kind 1984 report event
- Reacts on your behalf with a ⚠️ kind 7 reaction
TLDR; do you find the emoji reaction to be a problem? Full background below.
I've always been skeptical of public reports, because regardless of intent, they publicly and permanently associate your public key with objectionable content. This may be as harmless as reporting spam, which is fine to do publicly, or as sensitive as reporting directed abuse (sharing additional information about your associations), or reporting CSAM (which is a legal gray area in some jurisdictions, since it may constitute "advertising" the content).
I personally use nostr:nprofile1qyfhwumn8ghj7ur4wfcxcetsv9njuetn9uqsuamnwvaz7tmwdaejumr0dshsz8nhwden5te0dak8jmtsd93hxv3sxg6zumn0wvh8xmmrd9skctcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9uqzqrezcph2cyqzdp80e35026z5p6p595tqn4gghn2rztqr3esef79kpu7u7y 's nostr:nprofile1qyvhwumn8ghj7un9d3shjtnndehhyapwwdhkx6tpdshszymhwden5te0wp6hyurvv4cxzeewv4ej7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uq3qamnwvaz7tm99ehx7uewd3hkctcpzamhxue69uhhyetvv9ujumn0wvh8xmmrd9skctcqyptdfv7kxy86mdeffdlsgx4tg6w9llyfjxcmrve3nqdedgjx76hx2a33ch8 to anonymously and privately process reports in Coracle, because I want to protect my users as much as possible. But I'll admit that use of kind 1984 is nuanced and open to debate.
Much worse than using kind 1984 though, which semantically fits the concept of "reporting", is using reactions to signal reports. First of all, this doesn't really add any new information that kind 1984 doesn't already contain. It also has the effect of generating content on behalf of a user that they may not know they're consenting to.
In many clients (formerly including Coracle), "likes" are not filtered down by emoji, and so these kind 7 "reports" end up showing up as "likes". Completely fixing this problem is impossible, because it requires mapping a high-fidelity subjective medium (emojis) to a low-fidelity objective medium (up/down vote) in order to show likes. This can only be done with a reasonable degree of reliability for a very few emojis. This creates a problem for like-based clients in that lots of reactions can't be included in like tallies, resulting in lower social signal.
At any rate, I implemented the partial fix of whitelisting "obviously positive" emojis when calculating "likes" a long time ago, because reactions can be negative. I however didn't apply this to the "likes" tab on user profile pages, which was brought to my attention earlier this year when an Amethyst user asked me why a bunch of CSAM was showing up under his "likes". He wasn't aware that "reporting" in Amethyst created a public record of his consumption (unintentional or otherwise) of illegal porn.
This problem has since been fixed in Coracle, but likely still occurs in other clients that haven't yet addressed this problem, "trending" algorithms, and coracle custom feeds based on retrieving kind 7 (since kind 7 sentiment can't be filtered against on the relay side).
This is a Really Bad Thing, because it results clients advertising content as connected with the person who had intended to dissociate themselves with it. While clients processing reactions can mitigate this, the root issue is that a field for user-generated content is being overloaded for use in an application-specific context.
So, that's my opinion. What do you think? Do you find it surprising that reports in Amethyst may be treated as "likes" in other clients? Is it Amethyst's fault for creating the reactions, or other clients' fault for not filtering them out?
For more discussion, see the thread on github: https://github.com/nostrability/nostrability/issues/88
