RE: The Battle of Upvote Weights - Reviewing the Arguments with Extreme Use Cases
This is an excellent post, and its one of the few on the subject that expresses both sides of the debate clearly and consicely.
If you look at the commentary on the five brothers post, i bring up essentially the same issue that you do
Well, you have to keep in mind that there must be some threashold where we stop rewarding increased participation, otherwise bots will dominate the curation game. Even now, super andy's are "penalized" in the way you describe. And even if we allowed superandys to vote 80 times, there would be super-duper andys casting 160 votes that we would be "penalizing".
I use the word "penalizing" in quotes becasue its not really a penalty. For example, to borrow from the classroom analogy I cited above, when the principal decides to give perfect attendance certificates to children who have missed one day of class, you wouldn't really say the children who actually had perfect attendence had been penalized, except inasmuch as their award was now devalued.
So the question is where do we draw the line? To be honest, I agree that 40 might be a bit high, but 5 is definitely low. At what point are we rewarding bots, or just freakazoids who spend all day on steemit at the expense of average users.
My one issue with this post is that, no, I do not agree that finding 40 posts a day to vote on is a 10hr/day job. Or that it should take an hour to find 5 posts that are worth your upvote, especially if you have a list of authors you follow who you like and tags you generally check. And I think most active steemit users are way closer to 40 than they are to 5. But i don't have numbers to back it up, its just a spitball guess.
actually i take that back, i have one other problem:
No reason was ever given for introducing this change. In fact, it was originally peddled very aggressively as not a change at all and, as you noted, was listed as a bug fix. Afaik even though a lot of users have a problem with whale curation lists (bot lists), thats not really an issue of bots thats an issue of there being a list.
I would challenge you to find me one serious post, prior to the announcement of 14.0, that posed bot inufluence as a major problem
You bring up two good points. I'll need some time to collect my thoughts on them and reply :)
Why have any kind of limits or penalties on number of votes, at all? Doesn't this deter people from reading content once their accounts are beyond a certain threshold of voting power (potential curation reward payout)?
Isn't it better to incentivize people for spending more and more time on the platform, looking over more and more content?
How about this idea:
add a "time spent on post" element to the calculation of voting power and forget about penalizing accounts for using up too much up-votes to content.
Give a time weight element to voting power, such that posts that receive more viewing time get proportionally more weight on the time element of the reward calculation, compared to the other posts, but without removing the account SP factor. Also, provide every post viewing with the option to "take back voting time/ power", such that the account user has the option to only pay out some percentage of the voting power that their "time spent on the post" (TSOP) provided them, making it possible for people to view posts without voting them up. I think that it makes more intuitive sense that users vote by default by simply viewing a post and that they must take a step to remove their vote and/or diminish the weight of their vote(s).
Here's a simple formula that would achieve this:
[time account X spends on post Y (in seconds)] + [(time/ {some factor}) * (account X SP value)] and give X a limit at some arbitrary time (say 30 minutes, or 1,800 seconds)
The beauty of it is that the Steemit developers can control how much weight "time spent on post" (TSOP) has compared to account SP. Make the factor (the denominator of the [time/ {some factor}] fraction) a fractional value to give far more weight to account SP on voting power, make it some high value like 10, 100, 1,000, or 1 million in order to shift a lot more weight toward TSOP.
For instance, with X limited at 1,800s, we may choose 1,800 as our factor. This would make it a requirement for an account to spend at least 30 minutes on a post in order for it to receive the full SP weight of the account ([1,800s / 1,800] * account SP). Whatever the case, the power (or option) to shift more voting power to minnows clearly lies in this suggested calculation.
This makes it possible to shift some of the voting power to where it really should be to begin with - on time spent doing the work of curating/ reading posts. Time is valuable, after all, and people aren't too attracted by the prospect of spending hours curating only to make a few cents for their efforts, high SP or not.
I go into this idea in more breadth, RIGHT HERE.
Feel free to check it out, leave constructive criticism, suggest improvements to my ideas, provide alternative solutions, etc.
It is, up to a point. But the guy who is upvoting 800 things a day isnt doing that.
In a sense, the voting target threshold is an attempt to do exactly as you say -- ensure that the user is spending a certain amount of time reading before upvoting.
To do it directly, the way you propose, would be difficult i think, because it would have to be done on the blockchain level, not on the UI. But even then there would be an effective limit on the number of votes.
So for example, lets say the target reading time in minutes is 30 minutes to cast a max strength vote.
That means I can cast precisely 48 100% votes per day (or 90 50% votes or 180 25% votes)
That is to say, it works exactly like voting strength does now.
In terms of votes per day it's about the same. The big difference is that I can't do all 48 of those votes in the span of two minutes and have the chance to get full rewards - you see? People don't have to read the content in order to up-vote. They are in no way punished for voting on content that they don't actually look at.
If you're willing to up-vote something then you should desire to look at it/ read it, no? But that's not necessarily the case, here on Steemit. People are up-voting content on auto-pilot, trying to get high curation rewards off of popular content/ authors.
With my "vote with your time" suggestion, such people are penalized for voting on content that they actually don't like. In order to give a "full-strength" vote for a post, you'd have to spend X time (let's stick with the 30 minutes for sake of consistency), which means that you'd now have to spend 30 minutes on a post that doesn't really interest you - you're penalized because time is valuable and no one likes wasting 30 minutes, especially for minimal payouts.
If it could somehow be coded into the block-chain such that you only get paid for reading one post at a time, even if you have like 40 posts up on different tabs within the i-browser, making it clear to the user on the UI which post he/she is voting towards (perhaps with an option built-in to change which post the "voting time" goes towards), I'm almost certain that voting patterns would change in a big and positive way.
I think we'd start to see more community members focusing their time (votes) towards content that they actually like, versus those that they perceive as popular...but I could be wrong. I'm just basing it on my time is valuable hypothesis.
The time-vote pay system could work maybe but would be hard to do.
People might also open up multiple browsers to let them wait 30 minutes.
Bots might wait 30 minutes to get the curation.
Yeah, there are definitely some ways to game it, but, I think it's the most resource demanding of all the other alternatives.
I mean, vote in a matter of seconds or be forced to wait out 5 to 10 minutes, the latter definitely requires more "patience".
What I was really after though is getting a more accurate representation of what people actually like. Most people don't want to waste their time sitting on pages that bore them, they're naturally drawn to the blogs that interest them.
@jamesbrown - It is an interesting proposal. It is always good for us to brainstorm and try to think of ways to improve the platform. As far as the limits on voting, the main reason is to prevent people from gaming the system. If people could vote on things as much as they want, and use their full voting power every time - then people could cause the reward pool to be unfairly distributed. The issue with time limits is that there is no way to enforce them while still running Steemit as a distributed blockchain.
Thanks for the reply, @timcliff.
Yeah, I was wondering if the time limit was a true possibility on the coding/ enforcement side of things. Thanks for your input. I really appreciate it :)