This is a proposal to make changes to how blacklists are maintained for the Hive network. In particular, the proposal is a way to decentralize blacklists so that anyone can easily establish their own blacklist and can also choose which blacklist(s) they wish to interact with. But before I get into the details of this idea, I want to provide some background on the current state of Hive blacklists:
A Hive blacklist is a list of Hive accounts that are reported to be engaged in some form of behavior that other users find annoying or worse. Blacklists were created as a way to protect unwary Hive users (especially new ones) from various forms of trickery.
As an example, a blacklist might be created to warn of one or more of the following behaviors: phishing attempts to steal private keys, misleading account names that are very close to business services such as exchanges, spamming of plagiarized content and claiming it as their own, identity theft, etc.
Several different groups currently maintain blacklists for Hive (BuildAWhale, HiveWatchers, etc). 
A blacklist by itself is nothing more than list of accounts that are publicly published. But these lists are often used by various Hive services such as Hive wallets and browsing sites to warn their users to be wary of interacting with the accounts on the blacklist.
For example, several popular wallets warn a user if they are about to send funds to a Hive account that is very close to the name of an exchange or payment service, to prevent a user from mistyping and sending the funds to the wrong place. As a side note, most exchange wallets do not provide this service, so be extra careful when sending funds from an exchange.
There’s really several ways a service can get blacklist data: directly from the list maintainer (often in a git repository), via API calls to themarkymark’s server, or via hivemind servers (several of which currently get data from themarkymark’s server).
For example, hive.blog currently gets it’s blacklist data from hivemind. Hivemind servers primarily read data from the blockchain about posts and votes and provide this information to most user frontends such as hive.blog, peakd.com, and esteem.
I’m making this proposal for three reasons: 1) to improve hivemind performance, 2) to democratize/decentralize the creation of blacklists to some extent by making it easier for anyone to create a blacklist, and 3) to make it easier for users to choose what blacklists they want to use.
Since most frontends rely on hivemind servers to provide them with blacklist data, I think the simplest thing to do is enhance the code base of hivemind itself.
Hivemind already supports a feature that allows users to follow or mute a user. Following a user adds their posts to the user’s feed so it’s easier to find when a favorite author makes a post. Muting a user hides that user’s posts from the user.
My proposal is to add two similar features to hivemind: allow a user to “blacklist” users, and allow a user to “follow” another user’s blacklist. These two features will allow anyone to construct a set of blacklist users and will allow each user to use one or more blacklists created by others.
As mentioned previously, this change will also substantially improve hivemind performance, because the data will be stored locally in hivemind instead of being fetched from an external service. During our work optimizing Hivemind response times, we found that code for computing blacklisting was one of the main causes of slow response times (there were several other causes as well, but these are mostly fixed now, more on that in another post).
Muting an account means you don’t want to see the account’s posts and comments. Most frontends honor muting by preventing those posts from being displayed when you view the site.
Blacklisting an account implies you think the account is doing something wrong, and is intended to be used as a way to warn others that you think they should be careful when dealing with that account.
This will require a change to the various Hive frontends, which is ultimately up to the developers and operators of those frontends.
For condenser sites (e.g. https://hive.blog), the site would generally assign a set of “starter” blacklists provided by well-known community members to protect new users. Condenser will also provide an interface for adding and removing blacklists from the profile settings page.
A similar interface would be added for adding and removing users from the user’s personal blacklist (if they wish to create one).
The good news is, this should be a relatively easy change to implement, maybe a week or less to implement and test at Hivemind level, and relatively little work for the frontends, at least ones that already have features for following and muting, since the interfaces for blacklisting can be virtually the same, with a trivial modification to the hivemind API calls they make. No blockchain-level changes are needed.
And if we don’t make this change, we’ll need to come up with some other way to speed up hivemind using some form of caching of the existing centralized blacklists, because the performance impact using the current method is just too severe.
