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

in utopian-io •  21 days ago



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 The percentage of voting is determined by the sum of followers' MVESTS/SP, roughly 1 million SP ~= 1%.

busy-bot is using for vote weight.

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

However, is operated by @jesta (many thanks for managing steemdb), i.e., an individual witness. Considering the jesta's recent post, the stability of 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, 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'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.

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

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.


  • 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

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

Hello, @blockchainstudio. This is another wonderful idea contribution and I am going to staff pick it. Well done!
I appreciate the effort you put into explaining the technical aspect and the point of benefits which you have provided. This is indeed a well thought-out idea contribution. One thing I would like to suggest is that you should consider creating an issue on the GitHub repository for your idea contribution. If you already created one, you could as well reference it on your utopian post. It may sound trivial but this would allow the PO or one of the project maintainers keep track of the issue easily.

Your contribution has been evaluated according to Utopian policies and guidelines, as well as a predefined set of questions pertaining to the category.

To view those questions and the relevant answers related to your post, click here.

Need help? Chat with us on Discord.



Hi @knowledges, thanks a lot for picking mine!! I really appreciate that. Unfortunately, steemdb is still down :( and that's why this proposal is important. Of course, I'll post this on the github too. Thanks again!

ps. I've just posted this suggestion on Hivemind github: Thanks again!


Thank you for your review, @knowledges! Keep up the good work!

In Korean: steemdb가 잠시 2시간 정도 살아났다가 다시 죽었군요. 사실상 busy의 모든 스파를 스팀잇에서 임대해준 것이나 다를바 없을정도로 중요한 busy보팅을 증인한명에 제공하는 서비스에 의존하는 현 구조는 아닌 것 같습니다. 과거에는 이것이 해결하기 어려웠다면 현재는 블록체인이 아닌 일반데이터베이스인 Hivemind를 통해 이 작업을 매우 효율적으로 할 수 있다는 제안입니다.

또 하는김에 명성도 정보가 현재 hivemind에서 어이없게 정돈된 값(즉 65같은)만 제공하는데 실제 이전에는 엄청 큰 숫자의 raw reputation값만 제공되다보니 각 클라이언트들이 알아서 변화해서 쓰곤 했습니다. 그러다보니 하위호환성을 위해 다시 raw reputation을 재계산해서 넘겨주는 삽질을 하고 있더군요. 이 역시 hivemind를 이용해 둘다 제공하고 사용자가 알아서 선택하게끔 하자는 제안입니다.

ps. staff pick에 들어 보너스 보팅을 받았습니다 :)

Great write-up. I agree that the reputation should be stored raw instead of the normalized value. That way it also loses precision (db stores 2 decimal points if I recall it correct.(.


Thanks a lot for your comment. Yes, it should be stored as raw unless both are stored. Moreover, using the same field name reputation can be quite confusing. As far as I know, it's used only internally now in Hivemind, so this should be fixed before it's too late.

By the way, the current precision is actually 6
but it still loses the precision due to the conversion. You can actually see that inconsistency on Busy (user info vs feed/blog).

짱짱맨 호출에 응답하여 보팅하였습니다.

@blockchainstudio, thank you for supporting @steemitboard as a witness.

Here is a small present to show our gratitude
Click on the badge to view your Board of Honor.

Once again, thanks for your support!

Hi @blockchainstudio!

Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation!
Your post is eligible for our upvote, thanks to our collaboration with @utopian-io!
Feel free to join our @steem-ua Discord server

Hey, @blockchainstudio!

Thanks for contributing on Utopian.
Congratulations! Your contribution was Staff Picked to receive a maximum vote for the ideas category on Utopian for being of significant value to the project and the open source community.

We’re already looking forward to your next contribution!

Get higher incentives and support!
Simply set as a 5% (or higher) payout beneficiary on your contribution post (via SteemPlus or Steeditor).

Want to chat? Join us on Discord

Vote for Utopian Witness!