You are viewing a single comment's thread from:

RE: Introducing UserAuthority (UA), @steem-ua and UA-API !

in #ua6 years ago (edited)

No you're dead wrong actually on those assumptions:

-1- don't confuse UA (the influence / rep metric) with @steem-ua (the algorithmic curation program using the UA metric). Our UA-API broadcasts all accounts' UA data, to be eligible for a @steem-ua upvote we need to limit access (we'd need 100 million SP to upvote all content on the Steem blockchain!), and delegating SP is that delimiter. BTW, a @steem-ua upvote is completely independent from the amount being delegated.

-2- UA is *not a "black box", our algo is open source, our code is open source, we just haven't published the repos yet because we need to document it properly first and do some more unit testing. Also don't confuse UA-API data access with a "black box", we merely need to control server access to avoid system overloads.

(edit, upvoted for visibility & clarity)

Sort:  

a @steem-ua upvote is completely independent from the amount being delegated.

The amount of the delegation buys the frequency of the steem-ua vote. If that's not counting as buying upvotes then I don't know what it is.

UA is *not a "black box", our algo is open source, our code is open source, we just haven't published the repos yet ...

Well, as soon as the code is out and thus accessible for review and independent testing I'll be happy to not label the UA metric a black-box anymore.

The amount of the delegation buys the frequency of the steem-ua vote.

Well no! :-)
The more SP delegators there are, the more contributions we'll curate algorithmically, and the higher the UA_Vote threshold will be to get an upvote at all.

I clearly said max. 1/2/3/7 upvotes per week, not guaranteed "bids" or anything