Open economicstudio opened 5 years ago
inertia186
commented
5 years ago 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.
I know that "STINC" has entered the community vernacular, but many people consider it derogatory.
economicstudio
commented
5 years ago Hi @inertia186 Oh, I didn't know that. Now I realize that it might be due the its sound, right? Since I know it now, I'll not use it, I'll also change it in this proposal. Thanks a log for pointing out that. As I as I know, you are or were also an employee.
But I'd also like to give you some background. I'm native in Korean, and kr community doesn't know such a nuance, and actually my impression is people actually think STINC looks cool, or professional, like a jargon. It may look cool because it's english and acronym! I guess you know what I mean. Thanks.
inertia186
commented
5 years ago Personally, I think adding rep_log10 as a column seems reasonable.
However, I don't understand the get_followers_mvest and get_followers_sp request. Hivemind doesn't track account value.
I can see a solution where Hivemind is a component of determining account value. Since follower/following is currently indexed by Hivemind, applications don't need to rely on steemd to build that list. But after that, I think it's going to have to ask steemd for the account values, 1000 at a time.
This is adapted from my Utopian post: Two small yet mighty information that can be powered by Hivemind - followers' SP / rep & rep_log10
It'd be great if Hivemind could provide the following account information:
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%.
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 Steemit, Inc (@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.
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)orget_followers_sp(account)As the name suggests, the API provides either the sum of followers' MVESTS or SP of the given account.account.reputationandaccount.rep_log10Account 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.