RE: UserAuthority (UA): explanations, applications and implications
Hey @scipio, I wanted to comment on your first post but things got in the way 😅 so I'll comment here as my thoughts still seem relevant.
Firstly this is a really interesting idea and it's very similar to something that I looked into with @rycharde and @andybets a few months ago. We looked at a research paper called SybilDefender, it's really interesting and readable, I recommend you check it out.
It's sort of similar. SybilDefender uses specialized random walks over the network topology to find groupings of nodes (accounts) and isolate sybil nodes which are assumed to have a "small cut", i.e. limited interaction, with honest nodes. The network topology model I would use for Steemit would be the connections implied by outward votes I think, or in other words a vote is a small endorsement from the voter to the votee. I think this is better than the follower model you propose, although perhaps both could be used, where following is a very strong endorsement.
Anyway, the problem with adopting either of these at scale is that it is essentially bot work, done by a kind of sentinel program (got to get that The Matrix reference in!). It's not something that can be added to the blockchain code, as (1) it would be a large computational burden for witnesses and (2) it is a maintenance job which is outside the "call and response" role that witnesses have, unnecessarily complexifying the witness code.
I don't think the idea should be shot down at all though, it's a problem that needs to be solved in some way, but your proposal needs to be more realistic. This work costs do to, both in development and code maintenance costs and the running of the service itself. There are hundreds of thousands of Steemit accounts, and many more made every day, we're already way way behind on getting on top of this.
Recently @ned made a call for people to get involved in the SMT whitepaper in which he listened to a good idea from @inertia who had the idea that there should be an additional role for people to be watchdogs on the new Oracle role, or in his words "second levels of Oracles whose jobs are Quality Assurance".
I imagine your UserAuthority idea as that, QA on accounts. And there should be some formalized way to do this, not just ad hoc as you propose for the Utopian.io bot. It seems to be that the idea is to create a Quality Assurance role on the blockchain, like the way there will be Oracles and Oracle QA roles, where one keeps an eye on the other. We have account creators (now anyone) and we should have account creator QA. Or perhaps a general blockchain account QA role that is voted on like a witness.
There will always be some that say that any move against accounts or posts is an attack on free speech but it has to be clearly stated that some accounts are bad actors and work against the network. In other words, we accept the existence of sybil and other attacks, so we have to accept this. So as a wise person said to me recently, "The difficulty in such determination does not negate the distinction the determination provides.". Though it was in reference to something else, it applies in this case too.
Hi @personz
a) develop the UA MVP (via Utopian), test-drive temp results, alter the damping factor in case needed. Since UA is a game-changer (who you follow and who follows you becomes important), users will change their follows accordingly after deployment. "New rules lead to different behavior**. That anticipated behavior needs to be factored into the MVP test-results
b) evaluate and discuss MVP results Steem-wide, propose and vote for HFs
c) deploy Steem-wide.
Let's begin with -a- I suggest
Thanks for your detailed response. I should say right off the bat, because I didn't say this before and it's relevant, that I do not agree with the usage of a "honestly" metric to factor into payouts or vote weighting, as you suggested in your first post. I see it's usefulness in providing facts (i.e. a score) for a human led action (such as a witness could do) to divest a user of their SP (not including delegated SP of course) and prevent social media operations (voting, posting, etc.), while allowing the wallet to exist.
Your proposed algorithm is a good indicator of dishonest accounts but it would not be good to enforce this view on the populous. I don't believe the view is comprehensive enough for that. So I would very much oppose the two hard forks you suggest, as you suggest them. And I can tell you that in it's current form it will certainly not be adopted.
On the technical aspects, your calculations only hold up (if they do hold up, I didn't check) for follow information, not when including the much more voluminous vote information. I think votes are a better indicator of "the network", i.e. the topology, than follows.
The reason why it would work well for the Utopian bot is that Utopian is very heavily moderated and has high and restrictive standards on it's members / users. This is not the approach for the Steemit social network in general, so I assume you would prefer to go towards that. I don't think that will fly.
Looking forward to the MVP and updates on how the algorithm plays out, especially profiler / benchmark information.
Indeed, that was one of my thoughts. In real-time, at current technical levels, it would be improbable that it could be done.
If the payout window stays 7 days, then I guess even every a 5 days recalc could be reasonable. With more users coming to Steem the amount of needed calculations would go up very fast. It would be a quite impressive piece of work I guess.
And if you never try, you'll never know.
I am scipio
?
;-)
As it seems you were thinking a lot already about how to improve the platform, I would be curios to read your opinion concerning the idea of diminishing returns to make it less attractive to upvote the same accounts (including ones own ones) again and again ("circle jerking") and also to make repeated flags on the same account less effective (downvotes should be used to decrease the reward of low quality content but not to 'hunt' users because of their different opinions or any argument in the past).
In the linked post I described the idea like that:
"How about if after each vote on a specific account (including ones own account) each further vote on the same account would lead to significantly less curation reward for the voter and less profit for the upvoted account? Thus, when upvoting an account which I had already upvoted before, my voting power would be smaller than in case I upvote an account which I didn't upvote before."
The diminishing returns implementation is something I've supported from the first time I heard of it suggested by @rycharde some months back, in this post. On point 13 I'll quote it
Pretty much the same thing, though we can quibble on the details. I'm currently looking at ways to implement it in a new SMT I'm thinking of because it's extremely unlikely Steemit will implement this even though it's a great idea. It's also an anti-spam measure, increasing the number of accounts needed to take advantage of the free SP delegation by orders of magnitude.
Maybe you have a better insight into internal Steemit discussions than I have, and I would be curious why actually probability is so low that this idea will be considered one day? Do they just don't like the idea or would it be very complicated (respectively needed too many system resources - one had to save the information who upvoted whom for a while ...) to implement it?
I ran it by several witnesses at the time the post was published and it just didn't sit well with them. Most of them didn't agree with the idea that clique voting should be disincentivized in the first place. And the others thought it would be too complicated and processor intensive. And they have a point.
But really Steemit Inc. are very relucant to change anything so fundamental and their eyes are fixed on SMTs really, there's no political or engineering will for anything like this. I think a parameter change is as much as is likely to happen. Don't forget that for any hardfork, even if it is crafted over months, it's up to the witnesses to agree to adopt it in the end.
Still I think it would be a good thing to do to spread things out more. The rewards are heavily going back to the top guys so it's not great for the platform as a whole, in my opinion. People disagree with me on that, usually saying that the large investors deserve the "return". Well their return is so massive that I think they should be economically encouraged to curate with a wider net.
This. It's easy to like rewards when they're pouring in, but every reward attained comes at the cost of an other's rewards, and at this stage Steemit should be investing in growth, which depriving new accounts of rewards definitely doesn't do.
It's not that people able to game the system are somehow nefarious, but that they're gaming the platform out of utility for many, and this shoots themselves in the foot.
Your diminishing returns mechanism can be tricked, has some unforeseen side-effects, and is very computationally-heavy because it would require a running timer function and the complete vote-history of voters and votees, all in real-time:
My HF22 proposal
upvote_reward = UA * SPworks far more effectively and efficiently to honor the intended use of your own proposal, because the only thing needed to successfully combat the upvote/downvote actions of said very wealthy (high-SP) account it to let the community collectively** unfollow** that account.PS: I'm not trying to "shoot down" alternative proposals, like you have proposed via diminishing returns , but by design the UserAuthority simply outperforms other mechanisms.
I am not really convinced yet, that to 'honor' the amount of (weighted) followers would solve the problems, even if it is a really interesting idea.
For example whales wouldn't unfollow each other because of the mutual consequences, but if a minnow decided not to follow anyone anymore it wouldn't have much impact.
I wonder why 'honest' content could not be properly rewarded anymore in case of diminishing returns? Everybody still could upvote every other account with full strength, but just not so often anymore per day (he still could do it but then would earn less).
And concerning delegations you know my opinion already: I see no real reason for that - the positive effects of delegating Steem power are overestimated, the negative effects (vote buying as a consequence) underestimated. I would reduce it respectively make the conditions harder (for example extend the timescale in which one could use delegated Steem power again).
I've yet to test it, but I'm pretty sure the combined UA-weight of all minnows exceeds the combined UA-weight of all whales. One minnow follow more or less indeed doesn't matter much.
What about honestly liking and upvoting 30 well-thought of comments from the same user? Or what about liking and upvoting a lot of jokes from the same user found at the @traf account (including user @traf as well)? Diminishing returns in that case also makes no sense, those exist already btw, via the voting power "battery" mechanism!
PS: once again, I don't want to "shoot down" your proposal, but UA (if/once hardforked anyway) solves the exact problem you are addressing, it really does! And if you're not sure, just try to think of scenarios, of anticipated user behavior on that scenario, in case UA would be deployed system-wide.
No problem, I like that there are many different ideas, the more, the better. Keep me informed about the progress of your idea ... for example about some testing (in case that's possible).
I am somewhat stubborn, though, too. :) I don't think it is really necessary to upvote 30 articles/comments of one and the same author per day. You can upvote a few and if that is still not enough you can write something nice instead. :) Can you really write so many good articles in such a short timescale? I can't. @trafs short posts are a matter of taste, but in case you like them you may agree that the work load to produce them is not really high - so if you upvote only 2 or 3 per day that may be OK (of course that's only one possible opinion).
BTW, you said:
As I've explained in my previous response to you ...
... I argue my proposal is indeed very realistic. UA is currently being developed into an MVP by said helper-dev and myself. Stay tuned for updates! ;-)
Yes, I'll wait for the MVP for confirmation but it looks like you're right, my mistake. However as I also said, you need the vote information too for it to be a true reflection of the network which complicates matters slightly.