Thank you for this excellently written article @cryptoctopus!
And of course I surely am happy to respond to any questions and comments! :-)
Updated to bundle some questions and answers:
Q, by @curtiscolwell:
An attacking user creates one hundred accounts. These accounts all follow each other giving them a neutral UA. Then all of these accounts follow the attacking user to transfer their UA to the attacking user. Wouldn't this be a way to undermine the UA system?
A: First of all, the creation of 100 bot accounts only following each other surely is not "neutral" but an "account swarm". The way the UA formula works, is that in this precise example each of those 100 bot accounts receives a low UA and they all also transfer a low UA. Give or take it adds up to the equivalent of 1 bot account following the one user. So this example type of abuse would be futile.
Second, the minimal UA score can be "set" by a number of factors (variables) including the "damping factor". In case of serious abuse efforts (such as the above, and with "abuse" I mean the construction of networks for the sole purpose of trying to game UA), then the minimum UA score via that damping factor could be set to zero, at any time.
Third, UA consists of several implementation layers. The base layer is the blockchain with all its chronological follow operations (currently ~ 150 million since its inception). The second layer is the UA algorithm, calculating the "influence" of all accounts relatively to each other as a probability function where the combined UA of all accounts equals 100% (ergo, by randomly clicking "a follow" somewhere, the chance is 100% you end up at another account). The third layer are the "services" implementing UA by reading each account's UA score from the API: how each "service" (SMT, community, dAPP, bidbot, etc.) wants to set the rules for its own platform, is up to the platform.
In the example case you mentioned, a service could for example choose to exclude account swarms and its owner(s) from participating. That's not dictated by the UA characteristics, but how the services individually would choose to use them
Q, by @tobixen
So in the end of the day it's you who decides who should get a good UA and who shouldn't?
A: Absolutely not, UA is as democratic as it gets! It doesn't require being rich to build up a high UA-score: any minnow publishing really interesting content can grow their own account into a "whale" (= very high) UA-account! Every account can decide for themselves who they like to follow and unfollow, at any given time.All that UA does, is calculate the relative influence between each and every account on Steem.
As answered above, UA consists of multiple layers. The data is the data and the formula is the formula.
But most importantly, it is the services reading UA that decide themselves how they interpret each account's UA score and what to do with it. One "possible service's rule" could be "in order to participate on our service, your UA needs to be higher than X". Another possible "rule" could be "among your top 10%
UA-score contributors there must be at least 3 UA accounts with an UA score of at least Y".
Concluding, it's up to all accounts to decide who to follow. It's up to each individual Steem app to decide which rules they apply to their own service by reading UA scores. And feel free to run your own UA computation service & API and change the settings as you like 'em!
Q, by @muksihs:
Is UA an actual feature to be deployed or a proposal that needs to go through approval?
A: @holger80 and yours truly (@scipio) took the liberty of actually developing UA already. That took quite some time and is extremely computation-heavy. There were lots of technical solutions to be "invented", part of which is that the follower matrix is so large, it doesn't fit into RAM to perform Gauss-Jordan Row Reduction (= linear algebra) on it. So we implemented another algorithm in order to linearly scale the computational requirements, and we succeeded. (Just to name one technical obstacle we had to overcome).
Also, we will run UA-as-a-Service, very shortly. Stay tuned! :-)
But would high UA accounts start selling their follows then? Can the system be gamed with that? Tbh I haven't really understood UA yet. Will really take the 2 hours (or more) once I have some free time to do so. xD
Follow selling is possible, but presumably counter-productive to both buyers and sellers:
After paying, the buyer can be unfollowed, and the other way around, if a buyer only pays the seller after a certain time period, how does the seller know he gets paid at all? Of course "smart contracts" could be a way to make sure the buyer pays and the seller follows, but that would be public and therefore risky to lose followers.
So "thinking practical" makes sense a lot in order to guess what could happen.
PS: did you already take the time needed to read up about, and understand UA, as you wrote above?
What you ask is answered by the tremendous high cost of SEO: tremendously high because obtaining one link does not do that much long term, thus the whole strategy has to be longer in approach and keep targeting only the highest scores. These can be “poor minnows” even btw.
Just like PR UA always has always more data (if I understand it correctly) and thus becomes always fairer in output value with each new data input.
Nope, it is possible to attack UA, so to state that "more data always becomes fairer" is a bridge too far. However, we're virtually simulating severe attack scenarios to UA, and harden UA against it.
The first time I read about your idea to implement UA in Steem, I was very glad to read about a system that makes sense, and in theory is much more scalable than communities verifying each account.
I have taken quite the time to try to understand it, and I think it's a brilliant system! My question is are SMT communities able to use UA to determine people's voting weight on posts?
Very good question! And the answer is yes! That's actually the way I want to use UA for ourselves, to begin with: by upvoting content based on its author's UA score.
I will keep an eye out on the release! :)
Amazing work! The trending feed has been so bad that I've been trying to implement my own frontend to fix the issue but it has solely relied on simple filters, that's why I'm asking the following; through your api, will devs be able to query trending content just like they do now with steem.js? That would make integration take just few minutes max if you keep the data structure same and that would be a huge driver for adoption.
Thanks to cryptoctopus for sharing
Nice idea, and inline with our own plans. But as every nice idea comes with a cost, we have to see exactly when and how to make such a service available.
We already have public MySql databases of Steem blockchain that can be tapped into, in a sense, wouldn't you just need someone to do the same but with ordering from User Authority? I actually don't know what the costs of upkeep are so there might be better options.
Could User Authority run on client side perhaps?
UA is a derived metric: all follow broadcasts (currently ~ 150 million, on average currently every second about 2 follow transactions are added to that total) are available to fetch from the blockchain, but computation results of every account's UA score are not. Please keep in mind that with every (un-)follow transaction from user A to B, all UA scores of every account change (slightly).
Base message: UA is highly dynamic and extremely computation-heavy. As to running client-side, the question is what actually would run on the client. The fetching of JSON-i-fied UA end result scores from our API is possible. Calculating UA scores done live and client-side from raw blockchain data and/or a follow DB is not feasible at the moment.
If you like to tinker around with UA yourself, you might want to have a look at my original UA article which includes UA's core algorithm (more sub-algos are included currently, to properly deal with dangling nodes and sybils), an example graph (of 6 nodes, 13 follows), and the computation results of that example graph. It's a fun exercise!
Hey, I would love to talk with you on Discord about implementing UA into the 1UP platform.
Thanks for answering my question! Like the rest of everyone here, I need to look into it more. When I first analyzed it, it looked like that attack was possible. A test net type implementation for select users would be really cool to see and clear up a lot of the confusion.