DIP-49 Blocklist and Allowlists

[rosalinekarr]

Summary

Add specifications for shareable blocklist and allowlist features.

Abstract

Many current social networks include features for sharing lists of blocked users that other users may choose to subscribe to. This allows many users to protect themselves against harmful content without having to review the content for themselves and creates the potential for trusted moderation networks of volunteers. Since our specification current does not include any form of content moderation, this seems like a good first step toward a distributed, workable solution.

Specification

The following is proposed for addition to the spec as a new Blocklists.md file under a new Extensions directory:

### Blocklists & Allowlists

Users may maintain blocklists of other users who they do not wish to publicly block but choose to ignore all messages from.
Alternatively, some users may choose an allowlist approach instead, blocking messages from all users by default except for a selected list of approved users.
To accommodate these users, clients must include management systems for these lists and invalidate messages from blocked users accordingly.

Furthermore, individuals and organizations including but not limited to end-users may choose to publish their blocklists or allowlists for others to use.
These shared lists must be hosted at web accessible URIs for users as JSON objects including either a `"blocklist"` or `"allowlist"` key for which the value is an array of hexadecimal user identifier numbers as defined in the [Identity Registry](/Identity/Registry) specification.
The objects may also include an optional `"name"` key with a string value containing a reader friendly name for the list to be displayed in configuration settings.
For example, a blocklist might look like the following:

/```json
{
  "name": "Anti-Defamation League Blocklist",
  "blocklist": [
    "0x1234567890ABCDEF0",
    "0x1234567890ABCDEF1",
    "0x1234567890ABCDEF2",
    "0x1234567890ABCDEF3",
    "0x1234567890ABCDEF4",
    "0x1234567890ABCDEF5",
    "0x1234567890ABCDEF6"
  ]
}
/```

These lists may be published as broadcast messages with of type `"Link"`, and end-users may choose to subscribe to them effectively adding all blocked or allowed users in the given list to their own blocklists or allowlists.

Copyright

Copyright and related rights waived via CC0.

[kfogel]

Hi,@rosalinekarr, @wilwade, and team,

In addition to the proposal described here, I'd also heard -- or possibly mis-heard -- that there's been consideration of incorporating content moderation "scores" into the protocol. Probably not stored directly on-chain, now that I think about it, but rather there would be on-chain links that point to off-chain score-collection files, just like with allowlists/blocklists.

At first I understood this to be orthogonal to the allowlist/blocklist proposal. As in: blocklists and allowlists indicate that someone disapproved or approved of some content, whereas actual CM scores indicate why someone disapproves or approves of some content. But the more I thought about it, the less confident I was about that orthogonality.

So my two questions are:

1. Is it the case that both of these proposals are under consideration, or is this issue's proposal really the only thing on the table right now? (If the latter, then I just misunderstood a verbal description of this proposal and thought it including scoring when it doesn't.)
2. If both proposals are in play, are they considered separate, or would it be one unified system (e.g., the file format sketched out here would be expanded to include the reasons why something is blocked and possibly the scores that indicate the severity/confidence of the block decision)?

[rosalinekarr]

@kfogel, I believe we've discussed both proposals as potential solutions, but this is the only one we have documented in a GitHub issue so far. Assuming we proceed with both proposals, I would expect that they would be separate tools for addressing the same or similar problems and could be used together or not as users see fit.

@shannonwells has done some of the preliminary research into identifying spam with Benford's law and generating spam scores, so she might be able to answer more of your questions regarding the other potential proposal.

[kfogel]

Thank you, @rosalinekarr. I was thinking more about non-spam content moderation (or, as it is known by those who disagree with it, "censorship", to be fair), but I can see how the same labeling mechanism can be used for both.

I'm assuming that the mechanism by which someone decides that some content is objectionable is separate from the mechanism by which that decision -- that label -- is made known to others. My questions are really about the latter, and this issue also seems to be about the latter. I'll check with @shannonwells to see if she's working on both or just the former.

[wilwade]

Closing this proposal for now. While block and allow lists can be built, a deeper look at moderation and the role desired for the DSNP as a protocol to play.