#### Repository
- https://github.com/steemit/steem
- https://github.com/steemit/hivemind

#### Components

Account information
- followers' total MVESTS/SP 
- raw reputation / rep_log10


Note: this is a technical idea, i.e., the information is already provided a different (inefficient and unstable) way. I believe this technical change is important for stability and extensibility, as Hivemind is important although it's serving the information that was provided by others. 

#### Proposal Description
https://steemitimages.com/640x0/https://cdn.steemitimages.com/DQmZvBkuJePehh9pphd9JyH1VjvyoKv5Hjswd7o7JnwgRHF/Hivemind%20Live.jpg

##### Follower's MVESTS/SP powered by Hivemind

**Nobody wants no voting from Busy :)**


Many Steemians are using Busy probably due to the voting from @busy.pay. The percentage of voting is determined by the sum of followers' MVESTS/SP, roughly 1 million SP ~= 1%.

![](https://cdn.steemitimages.com/DQmSXmwrPnPgpVETkE7u6xNcsCebr7N9YCxisgBxXwRnecX/Screen%20Shot%202019-01-27%20at%2010.10.18%20PM.png)
> busy-bot is using steemdb.com for vote weight. https://github.com/busyorg/busy-bot/blob/master/src/upvoter/index.js#L16-L18

Obviously, this information cannot be calculated instantly (think about @ned who has so many followers), so Busy relies on https://steemdb.com which basically logs the snapshot of account information including the followers' mvests from time to time.

However, steemdb.com is operated by @jesta (many thanks for managing steemdb), i.e., an individual witness. Considering the jesta's recent [post](https://steemit.com/steem/@jesta/the-recent-controversy-between-steemit-inc-and-the-community-the-premine-control-and-where-it-leads-this-blockchain), the stability of steemdb.com may be uncertain in the future. It was **down for more than one day yesterday**, and was down from time to time in the past. **Actually, it's currently down again after  short resurrection :( And that's why I'm writing this suggestion!**

Most of Busy's SP is delegated from STINC (@misterdelegation), so busy voting isn't just a Busy's problem but an important part of the Steemit life.

**Reward your influence**

The reason why Busy chose follower's SP as the criteria is to reward **influence**: [Introducing @busy.org, the bot that rewards your influence](https://steemit.com/busy/@busy.org/introducing-busy-org-the-bot-that-rewards-your-influence)

While there is no single perfect measure of influence, follower's SP seems a quite decent one. At least it should be used as a factor for any other measure of influence, e.g., [The implication of reputation score has been somewhat reduced. How about combining new indicators?](https://steemit.com/utopian-io/@lostmine27/the-implications-of-reputation-indicators-have-faded-how-about-combining-the-new-indicators-1547129297601)

**Thus, the follower's SP should be provided more officially** than by individual witness.

Previously, providing the follower's SP was quite costly. However, now we have Hivemind! which is a usual DB not a blockchain. That is, **Hivemind is very fast, efficient, and cost-effective.**

That's why Hivemind is now providing much **information that need not be absolutely exact (or real-time)**. And follower's SP is such information. It need not be absolutely exact and some delay is fine.

In fact, the steemdb.com's update isn't frequent, and its updating algorithm seems to have a bug, i.e., it sometimes keeps restarting form the account starting with 'a', i.e., alphabetically. 

Now let me explain the second part of the proposal.

##### Reputation and rep_log10 powered by Hivemind
While what users normally see as reputation is some number like 65.5, internally it's a huge number like 31423161386996. All API calls actually return this raw reputation. Let rep_log10 denote the normalized rep like 65.5.

However, the current implementation of Hivemind actually only stores rep_log10.

![](https://files.steempeak.com/file/steempeak/blockchainstudio/TyA1BuEz-Screen20Shot202019-01-2720at2010.21.1520PM.png)
> https://github.com/steemit/hivemind/blob/f7a467921678d928a0d94928c811442b8ab80bce/hive/db/schema.py#L40

While it's good for Hivemind to calculate rep_log10 on behalf of clients, but ironically, all existing clients expect raw repuation, so Hivemind actually re-convert rep_log10 to raw reputation **where some precision is lost, which leads to reputation inconsistency bug**, e.g., https://github.com/steemit/steem/issues/3241

#### Mockups / Examples
- `get_followers_mvest(account)` or `get_followers_sp(account)`
As the name suggests, the API provides either the sum of followers' MVESTS or SP of the given account.
- `account.reputation` and `account.rep_log10`
Account information should provide both raw reputation and human readable, normalized reputation. Then clients can choose which one they use depending on purposes.

#### Benefits
- Fast, cost-effective information update
Hivemind isn't a blockchain, so the information desired can be very effectively updated.

- Busy voting stability
Again, busy voting is more than unofficial. If it's down for a while, user experience hurts. If follower's SP information can be provided more officially, the stability can be improved dramatically.

- Extensibility for "better" reputation score.
Current reputation, @steem-ua score, there can be many kinds of reputation scores that have pros and cons. But follower's SP must be a meaningful factor. To design a better reputation score, clients should be able to use it without too much cost and instability.

- Reduce client's burden
If both raw reputation and rep_log10 are provided, clients can choose among them depending on the purpose without additional calculation cost.


#### GitHub Account
https://github.com/economicstudio