While running Hive Archaeology on your NAS or other system as your private bot, normally the bot only responds to your up-votes of old high quality posts. While manual personal up-votes are always better, when your VP is at 100% or just below, you don't want your voting power to go to waste.

This proposed feature we want the user to be able to run the Hive Archaeology Bot in a mode where at VP of 99.5% or more, the bot will start 25% (default) auto up-voting in-window posts curated by peer curators.

We define three flags:

• --peer-curation : Auto up-vote posts up-voted by peer curators with 25% when VP reaches 99.5% or higher.
• --peer-curation-pct [PCT] : Auto up-vote posts up-voted by peer curators with PCT% when VP reaches 99.5% or higher.
• --peer-curation-list [LST]: Set the whitelist to use for identifying peer curators.

By default all tags curated by peer curators in the list could end up getting up-voted, unless the following flag is specified:

• --peer-curation-tags [TAGS] : Comma separated list of tags

While running Hive Archaeology on your NAS or other system as your private bot, normally the bot only responds to your up-votes of old high quality posts. While manual personal up-votes are always better, when your VP is at 100% or just below, you don't want your voting power to go to waste.

This proposed feature we want the user to be able to run the Hive Archaeology Bot in a mode where at VP of 99.5% or more, the bot will start 25% (default) auto up-voting proxy comments created by other Hive Archaeology Bot users.

We define two flags:

• --community : Auto up-vote new Hive Archaeology proxy comments with 25% whren VP reaches 99.5% or higher.
• --community-pct [PCT] : Auto up-vote new Hive Archaeology proxy comments with PCT% when VP reaches 99.5% or higher.

When using one of these flags, by default all Hive Archaeology users are trusted but we need a way to blacklist.

For this you can set your own list:

• --community-blacklist [LISTNAME] : Set a blacklist of accounts whose proxy posts never to upvote
• --community-tag-blacklist [LISTNAME] : Set a blacklist of post tags for what proxy posts never should get upvoted

In the distance past, the author of Hive Archaeology ran the Croupierbot on HIVE as a public service for verifiable random draws.
The idea was that anyone can invoke the bot to ask for a random draw that is based on the blockchain.

This proposed feature aims to ressurect the Croupierbot functionality in a distributed way. It is proposed that every Hive Archaeology bot is always a CroupierBot validator, and running the public service is optional using the following flag:

• --enable-croupierbot

When the croupierbot is running enabled, everyone can ask it one of a number of commands by starting a comment with a mention of the account running the croupierbot followed by a command with command specific arguments. The initial verstion will only support the following command:

• @owner LOTTERY [account]<:[tickets]> [account]<:[tickets]> [account]<:[tickets]>

The first response to this will be the bot creating a custom JSON post meant for itself and peer validators. This custom JSON contains a structured version of the command and a near future block number and a link to the comment for responses.

When the block is published, the all the bots determine the winner of the lottery and post a response with the winner according to the custom JSON and the block used for entropy.

While running Hive Archaeology on your NAS or other system as your private bot, normally the bot only responds to your up-votes of old high quality posts. While manual personal up-votes are always better, when your VP is at 100% or just below, you don't want your voting power to go to waste.

This proposed feature we want the user to be able to run the Hive Archaeology Bot in a mode where at VP of 99.5% or more, the bot will start 25% (default) auto up-voting in-window posts created by peer post authors.

We define three flags:

• --peer-authors : Auto up-vote posts created by peer authors with 25% when VP reaches 99.5% or higher.
• --peer-author-pct [PCT] : Auto up-vote posts created by peer authors with PCT% when VP reaches 99.5% or higher.
• --peer-author-list [LST]: Set the whitelist to use for identifying peer authors.

By default all tags created by peer authors in the list could end up getting up-voted, unless the following flag is specified:

• --peer-author-tags [TAGS] : Comma separated list of tags

Currently the Hive Archaeology based up-voting of old and timeless high quality content is a lonely task. This feature will only be usefull for users that run the bot 24/7, for example on their NAS. The idea of this feature is that we can let the bot generate a HIVE post once a day (at most) with a list of posts that were up-voted by the bot. This post will be done using a #hivearchaeology tag, so other Hive Archaeology users, but also just HIVE users willing o up-vote the proxy post can use it.

This feature will introduce the following flag:

• --daily-report : Enable daily report

As described in this tweet by @dexterdev, there are HIVE communities that consist of both a Discord server and a HIVE community.

It might be interesting as a feature for Hive Archaeology personal bot users to bridge Discord content to comments on a daily community post.

To not collide with HIVE proof of brain ethics, these posts and comments will have to be declined payout posts.

For this feature we define the following flags:

• --bridge-community [community] :

Next to this, other flags and env variables are going to be needed but we will first need to explore the discord API for figuring out ecactly which ones we need.

As described in this HIVE comment, it might be desireable to not vote for posts if the author's account has been inactive for a really long time.

In this issue we want to implement two commandline flags:

• --max-inactive-time : Maximum number of months the account of the post voted for may be inactive (defaults to 12)
• --use-precise-inactive-time: Use a more involved way to determine inactive time of the account.

The standard way to determine the last active time will simply take the latest of the following account parameters:

• last_vote_time : Last time the account voted on a post or comment
• last_post_time : Last time the acount created a post or comment

It is remotely possible that an account has stoped being actively used for posting and voting, but is still for example used as a stake holding account that delegates and receives and claims beneficiary rewards. Or the account is now only used for trading between HIVE and HBD. In the standard check these accounts will be falsely marked as inactive.

When the --use-precise-inactive-time flag is set (default it is not), the bot should do a deeper check if the first check indicates that the account might be inactive. This check will check the most recent 100 actions from the account history. If it finds an action that matches the following, the account will be considered active after all:

• The action timestamp is later than the maximum number of months ago.
• The action is of a type expected by the script.
• The action was done by the account.

Important actions the precise inactive check should check for:

• account_update
• account_update2
• account_witness_vote
• change_recovery_account
• claim-account
• claim_reward_balance
• custom_json
• delegate_vesting_shares
• feed_publish
• fill_order
• fill_vesting_withdraw
• limit_order_create
• transfer
• transfer_to_vesting
• withdraw_vesting