I brought that up during recent discussions as well - I think having unlimited, repeating payout cycles for posts makes a lot of sense. If I write a technical article about how to build a website, the first week it might earn $10, but it remains valuable and should be able to start a new payout cycle whenever more people start voting on it weeks or months into the future.
An additional idea thrown out by someone (sorry, don't remember who) would also include that the account has to have enough weight for a payout (0.02) to start a new payout cycle.
There may be some avenues for abuse with this approach - but nothing you can't do already just by creating new posts everyday. If anything, by having a single payout window, we're encouraging people to repost the same content over and over on the blockchain.
THIS ^^^
It really deserves more attention!It deserves a dedicated post ! Please make a post about it @jesta
This exemplifies the reason why design-by-committee is doomed to languishing failure.
Engineering is trade-offs, and the best trade-off based on the current engineering constraints is a single payout window. Everything else (two payout windows, unlimited repeating payout windows, et c) impacts scalability significantly.
There are regular, deep discussions in our engineering organizations about these tradeoffs, and it would be a full-time job for several people just to communicate the minutiae adequately (to people who mostly haven't read the code).
At some point, unless you want to come and sit in our office full time (or understand the c++ consensus code in full), changes like this are going to have to boil down to "trust us, we do this for a living". I think there about 6-8 people in total on all of Steemit that have qualified opinions about the "how" and the "why" of the engineering decisions of the actual implementation of these changes.
Alternately, go and read the code, and you won't have to trust us. It's open source for a reason. :)
We are gearing up to support a lot more users and posts, and have identified the scalability chokepoints and have a plan to eliminate most of them. This is crucial to that plan, at the expense of a tiny dent in UX (it would be lovely to keep 24h payouts, and payout indefinitely, but those implementations simply will not scale as we grow).
This is an important comment. Frankly, I don't believe in decentralized design-by-committee. It is painfully obvious that a small team with a singular vision is a much more efficient at a creative pursuit of any kind, including software development. Open source allows contributors to fill in the gaps, point out the bugs, but there needs to be a focused vision. Steemit Inc. got the platform running rapidly within a couple of months, while competitors are yet to show up with a usable product after years. That was obviously a result of a small team working in a focused manner. Since then, progress has been far too slow.
I have read through your comments in this thread and you make compelling arguments for each. This is enough detail to let us trust you - we don't need to know the exact code, though of course it helps that it's up for examination.
Here's the significant blunder on your part - much of this communication should have happened in January, and not one day after the hardfork was due. Or at worst, last week when witnesses weren't able to reach consensus. I look back to the original proposal post from early January with considerably concern from the community, yet there's little to no feedback from anyone at Steemit, Inc. Worse still, you went ahead and coded features that the community was clearly against, and no one bothered to argue otherwise... until it's too late (now). Had clear communication like ones you have provided above been done then, we would have saved weeks in time we can't afford.
My recommendation would be to clarify and communicate every detail with the community when you make your initial announcement proposal for the next Hardfork, and make sure there is consensus, before you get down to serious coding. This way, the hardfork will go through smoothly once the code is ready. It's fair to say we have lost months overall due to miscommunication.
I hope all of this will be part of the new Steem development procedure that you have teased. Eagerly awaiting your post for the same.
Keep up the good work, and hope to see a faster development pace in the future!
I agree 100%. All I can say on the matter is that I wasn't managing the backend development team then. I am now. People who know me know that I don't work like that. :)
A-fucking-men.
That is exactly the plan, and we're already revising the drafts of the announcement post for the new process. To do it any other way wastes your time and ours. There will be a schedule, so you will know what happens and when, well in advance.
[Nesting limit, can't wait for that to go away!]
It's very encouraging to hear all of this. Thank you for replying - awaiting details on your announcement post. All the best, I'm now optimistic about the future development pace.
Beginning with getting Hardfork 17 pass, of course. It can only be done with clear communication with the witnesses.
My only concern with this feature is that if there is unlimited payout cycles then the daily reward will be shared between more and more posts as time goes by which will reduce payouts for newly created post, not sure if a valid concern but something to think about...@jesta I like the idea of having unlimited payout cycles . Like you said it make sense, if people on youtube were paid only for 7 days's views they would post a lot of clickbait stuff,repost a lot of video too and would not put the same amount of effort in creating content which will result in lower quality.
When the quality of an old post drive users to vote it then it deserves it .... so why not.
I prefer rewards go to good quality posts instead of new "crap" posts... That would also give the motivation to write much better!
I like it. Couldnt that feature be an arbitrary variable depending in the platform its been created on?
It could be - but regardless of the platform, all of the posts still draw from the same rewards pool. Any platform not using the "unlimited payout cycles" variable would likely not see as much activity as those who did.
But it would be great to see some platform independent variables being set :)
I like the idea but I have a hard time thinking of the ramification when the network scales.
rewards balance change also helps improve how the network will scale with more users.@cryptoctopus - There's still a finite rewards pool no matter how large the network scales, and the
I don't have all the answers, and I also have a hard time thinking of the ramifications. But it would be a good problem to have :)
There are two problems with this:
I would prefer to add some form of 'easy tipping' to the UI. I feel that this would be an acceptable way of providing rewards to old content. On traditional websites, I would argue that most users would not tip - but on a site like Steemit where there are already lots of rewards "flying around" - there is a lot less of a burden to send a few STEEM/SBD coins someone's way if you like their content.
I don't know that either of those are actually problems in my mind.
Both of these situations can already occur in the current system by simply reposting the same content in a new post. These wouldn't be new problems, it would just prevent bloat in the blockchain by encouraging repeat behavior on the same content, as opposed to reposting :)
Another reason to vote again on the same content is that it may be updated, expanded or otherwise edited. A good part of the the idea of allowing edits forever is to encourage maintaining/improving existing and reducing the need to repost it.
[nested]
That isn't possible. The decision to "activate" a post would be a consensus decision so the voting that led to that happening would have to be part of the consensus state.
Interesting view.
Another part that I've heard though (don't know that it still applies) is that there is a cost to keep all of the active posts active as part of the voting consensus.
@timcliff Yeah I've heard that as well, though I imagine posts wouldn't be considered "active" unless they received enough votes to "activate" the post itself. I hope with some of the recent optimizations (moving out of ram to disk, the payout to rewards balances, etc) that a hit like this wouldn't be a reason to deny the change.
There are definitely some potential hurdles/problems, but I think the pros would outweigh the cons and shift the overall dynamic in a positive direction. The life cycle of a blog post is much different than what our payout cycles currently allow and we should try to do something to encourage long term content.
Infinite payouts causes bloat in the memory size of
steemd. RAM is several orders of magnitude more expensive than disk, as you know.