Please note that this post is not of general interest: the target audience is Hive software developers (especially those creating Hive API documentation), so it will probably be pretty much gibberish to anyone else.
This post is describing new and not-yet-released API features, to allow developers to prepare for new capabilities that will be available for testing on the testnet in the coming week.
To add support for decentralized blacklists, we only needed to extend the capability of the existing "follow" API call (a custom-json call used to communicate with Hivemind servers) and add some new fields to the hive_follows database table in Hivemind.
Here’s an example of a follow call:
[“follow”,{"follower":"jes2850","following":"netuoso","what":["blog"]}]
This call tells Hivemind that Hive account jes2850 wants to follow the blog of account netuoso. The what parameter tells Hivemind the nature of the follow call. Previously, the what parameter could only be set to two values:
These states are mutually exclusive, so Hivemind internally used a single value to represent whether a user was not following/not muting (default state, stored in Hivemind database as integer value of 0), following (integer value of 1), or muted (integer value of 2). Since the states are exclusive, if a user has muted someone, then follows them, the muting is overwritten. Similarly, if a user was following someone, then mutes them, the following is overwritten.
As mentioned above, these commands are toggle commands. So assuming a user is initially not following another user, if the follow call is made twice, with what set to blog, the first call causes the user to begin following the following account, and the second call causes the user to stop following the account.
All the above behavior is unchanged in the new version of the follow call, so existing API consumers do not need to make changes unless they want to support the new capabilities for creating and following decentralized blacklists.
The enhanced API allows the what parameter to be set to the following new values:
It’s important to note that these new states are not mutually exclusive with the following/mute state, so two new boolean fields had to be added to the hive_follows table to store the blacklist and follow_blacklist states.
This means it is possible, for instance, to simultaneously mute someone, blacklist them, and still follow their blacklist. Probably more usefully, a user can follow someone and follow their blacklist (or they can just follow either their blog or follow their blacklist).
At a minimum, a frontend will need to allow users to mark the accounts they want to blacklist and the accounts they want to follow for blacklisting.
But current UIs for doing this are probably insufficient for creating large blacklists (this is feedback from one of the maintainers of the current global blacklists). So it will be useful to have a new UI feature that supports rapid entry of many account names (e.g. cut-and-paste of a large number of comma or space-separated account names).
Fortunately, the new blacklist command is not a toggle command, so this new UI feature won’t need to distinguish between accounts that have already been blacklisted: it can just make blacklist calls on all the accounts specified.
It’s also likely that most users won’t need such a feature, so it may be confined to being a special purpose tool, instead of building the capability into the frontends intended for non-power-users.
