You are viewing a single comment's thread from:

RE: Installing HIVE-archeology bot on your NAS: Your personal bot for transparent up-votes of older posts.

in HiveDevslast year (edited)

One can easily leave a comment under an older post and upvote the response. Money goes to the same place plus there's no middleman skimming profits. And if there's no response, then you know you're not upvoting or supporting a dead account. Even if it took three months to get a response, one can still support that old post by upvoting the author's response when/if it arrives.

Would it be possible to include a feature disallowing the ability to support a "dead account?" Sure the post might be great but if the author is gone for reasons including losing their keys, supporting them is throwing stake into the void. People run into the same issue tipping old work. You don't throw a dollar on the street where a busker once performed because they might be there again tomorrow to pick it up.

Sort:  

Sure, if you can make an issue on github and make description of what constitutes a dead account.

Think there are two ways to make a feature like this:

  1. Use get_account_history to fetch the last N actions on the account.
  2. Use get_accounts to get the last_vote_time and last_post_time

The second one is simplest, but will wrongly mark an account as old if the account for example stopped voting and posting but still claims beneficiary rewards.

The first one is more robust, but might need more than N items of history to work through bacause the result includes both sides of multi-party operations, for example fund transfer to the account or a delegation being retracted.

If you can write a solid spec of which one of these two is more desireable, and in the case of #1, fully specify the desired runthrough of the API response, I'll implement it in the next maintenance round.

Unfortunately I don't do all that fancy shmancy dev stuff so I can't be much help to you in that department. If I could, I would.

PeakD indicates when an account was "last active." Perhaps "dead" is the wrong word to use so I'll replace that with "inactive." If an account is inactive for two years, my guess would be supporting it could be wasteful. Even one year there's a strong chance they're not coming back, but they might. There are thousands of posts published by accounts that have not been active on Hive.

If one wanted to be really fancy, the vote could be processed once the inactive account becomes active.

Again, I can't help come up with a working solution. I'm sure you can see how it could be a problem. I suppose those voting should be paying attention to a little more than just the post when they decide to support older work.

Created an issue, could you check if it looks OK like this/

https://github.com/pibara/hive-archeology/issues/1

Looks fine to me.

If this method of earning beyond 7 days becomes popular, perhaps people will hear about it, and return. Especially encouraged to return if signs of activity help one qualify for a chance at those added rewards.

I agree with another commentator here recommending something like this system come standard with frontends. There's a shortage of actual paying consumers but providing them with more variety of products (content) to support could help encourage them to show up as well, if everything is straightforward and easy to accomplish.

We'll see.

Thanks for your time.

To illustrate, if I look at @nonameslefttouse with #1, and look at the last 1000 operations, apart from votes by you and posts/comments by you (and matching rewards and claims), I get:

  • account_witness_vote
  • custom_json
  • delete_comment
  • transfer
  • transfer_to_savings
  • transfer_to_vesting
  • update_proposal_votes