Denke gerade darüber nach, wie ich die Content Moderation in der neuen Crpyto Space 77 App implementieren soll.
Grundsätzlich möchte ich so wenig Content wie möglich filtern, und die Entscheidung eher den Usern überlassen.
Die App ist so designed, dass sie lokal im Browser läuft und Content nicht über meinen Server geroutet wird.
Auf Hive gibt es 3 bis 4 Ebenen, wo Content Moderation und Zensur stattfinden könnte.
Erstens auf Witness, Block Producer, Blockchain-Ebene. Witnesses (BPs) könnten User, Transaktionen und Inhalte ablehnen und zensieren. Allerdings ist dies auf Blockchain-Ebene eher unwahrscheinlich, da es viele Witnesses gibt, und eine koordinierte Zensur daher eher schwierig ist.
Die zweite Ebene ist die HAF (Hive Application Framework), HAFSQL und API-Ebene. Damit man auf den Content effizient zugreifen kann, gibt es HAF und API Server, die auf nostr Relays heißen, auf Hive oft als RPC Node oder API Server bezeichnet werden. Auch diese können von sich aus Inhalte filtern und sperren.
Die dritte Ebene sind dann die Front-Ends, die Inhalte blocken können. Captain Obvious.
Die letzten beiden Ebenen sind am angreifbarsten, da es nicht so viele Nodes und Front-Ends gibt und es technisch möglich wäre, Inhalte auf diesen Ebenen zu blocken.
Und die vierte Ebene sind die Benutzer und Hive-Communities selbst, die ebenfalls auf Blockchain-Ebene Mutes ausführen können oder eigene Blacklists betreiben können, wenn das die Front-Ends zulassen.
Auf Front-End-Ebene gibt es die Möglichkeit zu entscheiden, wie man mit Downvotes, Low Rep Usern und Mutes, den Moderations-Signalen der API-Server (gray und hide flag) umgeht, und ob man darüber hinaus auch noch Inhalte moderieren und blocken muss.
Im nächsten Release werden downgevotete User (Low Rep User), Mutes und moderierter Content mit einem Hinweis ausgebelendet und einer Option diesen wieder einzublenden.
Sind alles schwierige Entscheidungen, wie man mit moderiertem Content, Downvotes etc. umgehen soll, die bis jetzt für mich eher theoretsicher Natur waren. Als Entwickler eines Hive-Frontends muss ich diese Entscheidungen jetzt aber treffen. Zumindest für die im Web öffentlich zugängliche Version.
Anders sieht es aus, wenn ihr die App direkt über github herunterlädt, dann könnt ihr den Code selber editieren und in Zukunft mit einem God-Flag die Moderation abschalten, soweit das geht. Daher sind Open-Source-Frontends extrem wichtig.
In der jetzigen Alpha-Version (0.15) wird übrigens der Latest-Feed moderiert mit einem einfachen Rep, Comments und Reply-Count-Filter. Ansonsten gibt es noch keine Moderation.
In der nächsten Version, werden User mit weniger als 20 Reputation ausgebelendet und auch Moderations-Flags respektiert, und Content mit einem Hinweis ausgegeblendet, aber vorerst nicht komplett verborgen oder gelöscht.
Sind schwierige Entscheidungen ohne perfekte Lösung. Und man muss sich natürlich auch an die bestehenden Gesetze halten.
Wie würdet ihr Content filtern, mit Downvotes und Mutes umgehen? Sollen gemutete Inhalte angezeigt werden oder heimlich gefiltert werden, etc.? Ab welcher Rep sollen Inhalte ausgeblendet werden?
English
I'm currently thinking about how to implement content moderation in the new Crypto Space 77 app.
Basically, I want to filter as little content as possible and leave the decision up to the users.
The app is designed to run locally in the browser, so content isn't routed through my server.
On Hive, there are 3 to 4 levels where content moderation and censorship could take place.
First, at the Witness, Block Producer, and blockchain level. Witnesses could reject and censor users, transactions, and content. However, this is rather unlikely at the blockchain level, since there are many Witnesses, making coordinated censorship quite difficult.
The second level is the HAF (Hive Application Framework), HAFSQL, and API level. To enable efficient access to content, there are HAF and API servers—called “relays” on Nostr and often referred to as “RPC nodes” or “API servers” on Hive. These, too, can filter and block content on their own.
The third level consists of the front-ends, which can block content. Captain Obvious.
The last two layers are the most vulnerable, since there aren’t as many nodes and front-ends, and it would be technically possible to block content at these layers.
And the fourth layer consists of the users and communities themselves, who can also enforce mutes at the blockchain level or maintain their own blacklists, if the front-ends allow it.
At the front-end level, there is the option to decide how to handle downvotes, low-rep users, and mutes—the moderation signals from the API servers (gray and hide flags)—and whether additional content moderation and blocking is necessary.
In the next release, downvoted users (low-rep users), mutes, and moderated content will be hidden with a note and an option to show them again.
These are all difficult decisions regarding how to handle moderated content, downvotes, etc., which until now have been more theoretical for me. As a developer of a Hive front end, however, I now have to make these decisions—at least for the version publicly accessible on the web.
The situation is different if you download the app directly from GitHub; in that case, you can edit the code yourself and, in the future, disable moderation using a “God flag,” to the extent that’s possible. That’s why open-source frontends are extremely important.
In the current alpha version (0.15), by the way, the Latest feed is moderated using a simple filter based on reputation, comments, and reply counts. Otherwise, there is no moderation yet.
In the next version, users with less than 20 reputation will be hidden, moderation flags will be respected, and content will be hidden with a warning, but for now it won’t be completely hidden or blocked.
These are difficult decisions with no perfect solution. And, of course, we must also comply with existing laws.
How would you filter content and handle downvotes and mutes? Should muted content be displayed or secretly filtered, etc.? At what reputation level should content be hidden?
