Target audience for this post

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.

"follow" API call modified to support blacklisting and following of blacklists

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.

Original behavior of follow call

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:

• blog (tells Hivemind to toggle the following state for the follower)
• ignore (tells Hivemind to toggle the mute state for the follower)

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.

Enhanced version of follow call

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:

• blacklist: adds the “following” account to the follower’s personal blacklist
• unblacklist: removes the “following” account from the follower’s personal blacklist
• follow_blacklist: follows the blacklist of the account “following”
• unfollow_blacklist: unfollows the blacklist of the account “following”

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).

Frontend changes needed to use the new API features

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.