Two small yet mighty information that can be powered by Hivemind - followers' SP / rep & rep_log10

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

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

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, 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

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?

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://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