Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API suggestion - followers' SP #185

Open
economicstudio opened this issue Jan 28, 2019 · 3 comments
Open

API suggestion - followers' SP #185

economicstudio opened this issue Jan 28, 2019 · 3 comments

Comments

@economicstudio
Copy link

economicstudio commented Jan 28, 2019

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:

  • followers' total MVESTS/SP
  • raw reputation / rep_log10

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

sa.Column('reputation', sa.Float(precision=6), nullable=False, server_default='25'),

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., steemit/steem#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.

@inertia186
Copy link

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
Copy link
Author

economicstudio commented Jan 29, 2019

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
Copy link

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.

@roadscape roadscape changed the title [suggestion] Two small yet mighty information that can be powered by Hivemind - followers' SP / rep & rep_log10: followers' SP / rep & rep_log10 API suggestion - followers' SP Aug 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants