You are viewing a single comment's thread from:

RE: [Poll] Your Opinions on Hardfork 17 Features

in #poll8 years ago

5. All comments are paid out 7 days after creation and there is no longer a second payout window

Sort:  

I think to make this vote, more details about this point need to be made. Specifically, the description should be extended to read: "and the payout extension period to prevent voting abuse will be removed". AFAIK, this is the main objection to this point, not the part mentioned above.

Payout every day is what makes it fun to post every day. I think this 7 days needs to be split up into day1 payout and day7 payout - it can still use the same curve - just delete the difference that has already been paid out on day 1 when the day 7 payout comes and we will have a brilliant solution.

Posts should always be eligible for payout. Window really doesn't seem to matter much. Most posts are voted on withing the first hour with the exception of really active ones or ones that have made it to the front of trending There is no reason new people coming in and voting on old content should not be allowed or even discouraged.

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!

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.

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. :)

Had clear communication like ones you have provided above been done then, we would have saved weeks in time we can't afford.

A-fucking-men.

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.

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!]

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.

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:

  1. With a limited rewards pool, less and less will be available for 'active' content as more and more starts to go to 'historic' content.
  2. It allows users to keep re-voting on the same content over and over by powering down, and then powering up a new account.

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.

  1. If during that payout cycle, the 'historical' content is getting more traffic/votes from users, then why would it matter? The community itself should be deciding where the allocation of the rewards pool is driven.
  2. I actually think we should go one step further and let user's vote on a single post multiple times, but only during different payout cycles. If I upvoted a blog post a month ago that somehow makes it to the front page of trending again, maybe I want to vote on it again, and give the author another little boost. I may also want to flag it in it's second cycle, which this would also allow me to do.

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]

posts wouldn't be considered "active" unless they received enough votes to "activate" the post itself

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.

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

Infinite payouts causes bloat in the memory size of steemd. RAM is several orders of magnitude more expensive than disk, as you know.

Spot on here, I couldn't have said it better myself!

This should be an arbitrary variable depending on the app. This feature may box STEEM into a certain type of platform. The current behavior is only gathered from 1 UIX.

I agree what I would like to see is a short default lifetime with the ability of the poster or app to extend the time by paying a fee or using more bandwidth allowance. If you can post one every seven days for a month, you should be able to make one post and have it stay active for a month. The cost to the system for the latter is actually lower yet the current (and proposed) rules only allow the former.

I think the devs should take @jesta's suggestion into consideration. Having a continuous payout cycle is a powerful idea. That being said, I think the shorter term payout is a "sticky" feature that brings people back to the site. 24 hours is closer to "instant" gratification than 7 days. In 7 days, someone might not even remember to come back and check out how their post is doing. But if you are providing a shorter term payment window (24 hours), I think it is more likely to stay on their mind.

Having a continuous payout cycle is also a good way to require an unbounded amount of memory to run steemd. There are engineering trade-offs here which we dive deeply on.

24 hour payout window makes Steemit much more exciting

is this applied to just comments as stated or posts too?

It applies to posts and comments.

thank you... Just comments I'd be okay with as discussions can carry on for a few days but the post, not so much in agreement

I would vote yes to this if the period was still extendable to avoid last minute whale (or bot) votes. I also think it could be shorter, perhaps from 5-7 days.

Bloggers don't expect all their readers to read in the first 2 days, so I agree that the window for receiving rewards should be wider.

Not my favorite feature, but I support this because I think it will make external promotion possible. People will promote their posts outside of Steemit and that should help bring more people here. We need to look beyond Steemit's details and see the larger picture.

How about this idea: OP gets a fraction of the payout of the comments. Then starting a huge discussion would be profitable.

The Op of every comment also from their child comments!

This was actually how it was designed in the whitepaper :)

I'd have to think about it and discuss this more, but offhand it sounds like a really good idea. You even could consider giving community moderators some cut to stimulate engagement also.

Another way to make external promotion (and longer term) would be repeatable payout cycles on a single post. You're right, this does help it, but making content viable forever would have a much larger impact.

Yes, it also would enable FAQ content, Wikipedia stuff, timeless writing or photos, and so forth.

It absolutely would :)

I agree .. It should be possible to reward those who bring out Steem. Have you thought about this thing ??

Does not bother or effect me at the moment.

I think it would be better that the current
24h.+1month gets >>>> 24h.+1week
(2 payout windows just 1month>>>1week)

I like it to find great somewhat older articles sometimes and are still able to reward the author ... But maybe the long time span has some disadvantages I am just not aware of?