Alternative reporting system

[Aspie96]

I am proposing this as an alternative to NIP-56 due to concerns raised here: #205 (comment)

I've first thought of a reporting system prior to being aware of NIP-56. This is, at this stage, nothing more than a mere request for comments. Please do provide criticism.

The goals are:

• To allow relays to crowdsource moderation efforts.
• To avoid reporting content to relays for breaking rules they don't enforce.
• To help users not be banned by relays for publishing forbidden content to them.

Ideally, if relays chose to adopt rules and forbid certain kinds of content, different relays will have different set of rules, so that overall censorship resistance is preserved.

The goals are NOT:

• To promote censorship.
• To provide a list of content that I believe should be banned.
• To force anyone to ban anything.

If a relay doesn't adopt a rule, that does not mean the admin endorses or allows that kind of content, but simply that they haven't adopted this specific crowdsourcing system to moderate against it.

If a relay does adopt a rule, that does not equate a pledge by the admin to always ban that kind of content.

General idea

Each rule identifies a kind of content which may be forbidden by a relay. Each rule is completely described by three strings:

• An id, computed trough a hash function, which is guaranteed to be unique.
• A short one-word name, which is not guaranteed to be unique, but should be chosen as to be as descriptive as possible of the forbidden kind of content (e.g. "spam").
• A description which describes the forbidden behavior.

The handle of a rule is a dash-separated compound of its name and the beginning of its id.

Each relay exposes the list of rules it adopts.

When choosing to report a note, the reporting user is prompted with the list of rules which are adopted by at least one of the relays the client has received the note event from (that is to say, the relays used by both the note author and the reporting user). The reporting user is then free to select any number of such rules which they believe have been violated. The client sends the report only to those relays, from which it has received the note, that adopt at least one of the rules selected by the user. The user may also be given the option to exclude some of the relays from the report.

Before sending the report, the reporting user is prompted for a text explanation of the report, in which they can provide the additional context needed to understand the situation. The same explanation is sent as part of the report to all relays to which the report is to be sent, regardless of what rules that relay adopts.

If, upon receiving a report, a relay administrator determines that the reported note does indeed violate one of the adopted rules it was reported for, they may decide to unpublish that note.

To avoid clutter, it's beneficial to chose existing rules already adopted by others, rather than creating new ones, but no central repository of rules is required.

When writing a note to be published, the client should prompt the user with the list of rules adopted by at least one of the relays used in writing mode. The user can chose any number of rules the note would break. The client, then, shall not send the note to those relays when submitting the note. The note will only be sent to relays which don't adopt those rules. The user might also be given the ability to exclude some other relays, or to still send the note to a relay even though it adopts a supposedly broken rule.

When a client presents a rule to the user, it should show its handle, which an experienced user will likely recognize for commonly adopted rules. The user has then the ability to see the description of a rule, to evaluate whether a given kind of content breaks that rule or not.

The Other rule

The name of a rule cannot be "Other". "Other" is a special handle which refers to some set of rules which are so specific to a given relay that it wouldn't make sense to expect broader adoption. When reporting a note for Other, the reporting user is prompted with the list of relays which adopt the "Other" rule (among those which published the reported note) and needs to manually select which relays are relevant. None is selected by default.

The "Other" rule is only useful when several users can be expected to be familiar with the policies of some particular relay and such policies can't be wholly summarized by the conjunction of commonly adopted rules.

Illegal content

Different jurisdictions have different laws, so "illegal" doesn't per se mean a lot, if anything at all.

Yet, many relay admins could desire banning content which is illegal in their own jurisdiction, especially in cases where that risks being a legal liability to them.

The solution I suggest is to reserve the name "Illegal". "Illegal-XX" acts as a special handle where "XX" is either an ISO 3166-1 country-code or an ISO 3166-2 subdivision code.

For example, "Illegal-US" bans content illegal anywhere in the United States, while "Illegal-US-AL" bans content which is illegal in Alabama.

Federally illegal content in the US would be against both "Illegal-US" and "Illegal-US-AL" (since it's not allowed in Alabama, even if it's not a state law). Content forbidden by a specific California law, however, would violate "Illegal-US" (since such content is illegal somewhere in the US) but not "Illegal-US-AL" (since in Alabama one doesn't have to care for California state laws).

While the EU is not a country, "Illegal-EU" shall refer to content illegal anywhere in the European Union, with the same principles as the examples above. This is consistent with the fact that the "EU" code is reserved for this purpose.

A rule for enforcing the law of a specific EU country, however, should not include "EU" (for example, content illegal in Italy is "Illegal-IT", not "Illegal-EU-IT").

Examples

The following are examples of rules that a relay could enforce:

• ["Porn", "Representation of explicit sexual acts or of sexual organs for sexual purposes."]
• ["Spam", "Unwanted and/or unsolicited advertisement, excessive repeated messaging or other actions which abuse or deteriorate the technical functionality of the service."]
• ["CP", "Representation of a real minor involved in explicit sexual acts or of a real minor's sexual organs for sexual purposes."]
• ["Loli", "Representation of explicit sexual acts or of sexual organs for sexual purposes featuring a fictional character which is or appears to be a minor."]
• ["Impersonation", "Attempt to misrepresent one's identity as that of somebody else or of one's relationship with another party."]
• ["Nudity", "Videos or photographs exposing private or intimate body parts."]
• ["Gore", "Material which is severely disturbing, graphically violent or otherwise extremely shocking."]
• ["Threat", "Credible threat of illegal physical violence or of other criminal attacks."]
• ["Scam", "Fraud or misleading or false advertisement or attempt at phishing."]
• ["Profanity", "Insulting or outrageous form of expression."]

Please note that I am not endorsing the adoption of any of the rules above, nor suggesting that any specific kind of content should be banned.

However, I would like feedback on these rules. I think they are likely to be adopted by some relays and I hope they can inspire the wording of future rules in order to avoid proliferation of differently worded rules identical in meaning.

Technical details

There are actually several simple ways to implement this solution, and it really is a matter of picking one.

One could imagine rules being published as events. Each relay would have to make sure to publish the rules they are enforcing. What I don't like about this solution is that each rule would be inherently attached to an author, as all events are. I fear the perception of the rule and that of the author may reflect on each other.

Another solution is that each relay exposes all data about its own rules, and that they simply make sure to copy one another to limit proliferation.

There is a tiny bit of complexity coming from the fact that most rules have a description but "Other" and "Illegal-XX" do not. I suggest that a reasonable format when publishing an adopted rule can be a 2-entry array such as:

["Name","Description."]

The id of the rule is, then, the hash of this JSON structure.

In the case of the "Other" rule and the various "Illegal-XX" rules, the second parameter is omitted. The hash is computed as before, based on a one-element JSON array:

["Illegal-US"]

When the user reports a note, the report contains the list of broken rules, each represented by its id and the explanation.

Together with the list of adopted rules, each relay may also optionally publish a link to its content policy. This is presented to the user when selecting the "Other" rule and in any other case determined by client developers (such as when adding a relay).

Final remarks

It should be noted that rules can overlap and the same behavior could be a violation of two different rules. A rule might even be a subset of another. For example, anything which breaks "CP" would also break "Illegal-US", because child pornography is illegal in the US. What rules to include is totally up to relay admins and how they want to handle moderation. Including "Illegal-US" but not "CP" would still forbid child pornography, but it wouldn't distinguish it from other kinds of illegal content, which may or may not be what the admin wants.

Overall, I don't think this solution is as complex as it may look at first glance. I think it's rather simple once the details are settled, and that it would allow for the flexibility a decentralized system should have.

[weex]

Since #205 was merged, what you might want to do is create an issue restating the problem you see with NIP-56. It may also be helpful to provide evidence from users and relay administrators who find NIP-56 to be insufficient. Otherwise, this can be dismissed as more theory than problem in practice.

[staab]

Much of this conversation has been had already (since?) in #532 and #457. The idea of having relays publish content policy is a new idea though. I'll go ahead and close this, but please do leave your thoughts and feedback on the above if still interested.