You are viewing a single comment's thread from:

RE: Steem 0.17 Change Proposal Introduction

in #steem8 years ago (edited)

All in all, thank you for your hard work and most of all, thank you for being transparent and bringing this out to the community as a proposal and open discussion.

I am personally good with most of them and a bit so an so (might need more time to think on) about:
Switch to 7 day payout instead of 24h
The simplest and most logical way to reward everyone imho would be indefinite, with a 24h payout cycle.

Removing the 4 posts limit, comment nesting limits and separation of posts and comments rewards plus multiple beneficiaries etc.
I think this adds a lot of complexity to the operations and might turn out to be very heavy computationally wise especially as we scale. Also opens the door to spamming by overflowing the blockchain with data.

What I didn't see mentioned in the proposal. maybe it will be in the roadmap

  • the faith of SBD (will it stay, will it be removed as it's outdated etc.)
  • more blockchain based operations/more development on blockchain based operations (like surveys.polls for ex.)

Reading through all the items mentioned, i think that a more streamlined (TL'DR-ish), layman description of the suggestions would be welcomed by the less tech savvy.

Sort:  

Ideally, I would love indefinite payout potential.
Perhaps 7 day initially, then 30 days periods indefinitely ..

I think it would incentivize content creators more to have the possibility for recurring income for those rare gem's of articles years into the future - especially considering future steemians signing up and finding classic posts from long before they joined..

Hey, @ausbitbank, I have had very similar thoughts, but my thinking has progressed a little...

If the reality of blockchain durability matches the promise, then the mere long-term availability of a creator's content is a strong incentive to blog on Steemit. As good or better than ongoing payouts for old articles would be easier access to those articles by new readers. I think that's more of a UI issue.

In other words, the lasting value of my "old gems" would be to attract new readers to want to keep coming back.

I want readers, not bots. ;) People that actually read and benefit from my content, and I think that a loyal and appreciative following will benefit me as an author even more than residual/royalty income from older articles.

It is important to not attempt to be all things. Multiple payout periods force all content to be kept "active" in consensus nodes which impacts technical scalability. It also requires all content to be kept active for review purposes.

Each day you are paid in STEEM, your long-term income comes from appreciation of STEEM. Employees don't go back to their employer asking to receive income from the work they did last year, last month, or even last week. Each day you are paid for that days contribution.

When the platform grows then you receive the compounding return on investment that will far outpace any residual revenue you would get from a post.

Don't all comment_objects need to exist in memory (at least with minimal data of author and permlink) anyway? The blockchain needs to check whether a post operation has a unique author/permlink so that it knows whether it is creating a new post/comment with a payout period, or just doing an edit.

So, we are talking about keeping maybe a couple more fields in comment_objects for validating nodes. And if you compare that to the amount of memory full nodes need to keep (whether the post is archived or not), that additional memory overhead is very small.

Memory access patterns for validating nodes are more of a concern, but I doubt most old posts will continue to remain active. And isn't this one of the advantages the ChainBase upgrade provided? That the database can support a much larger amount of infrequently accessed memory (since they remain on disk rather than in R AM)?

Also, I supposed it doesn't have to be indefinite. But archiving a post/comment after just 1 week is really short. (By the way, does archiving a post/comment mean that no new child comments are allowed? Because otherwise you still have the limited attention problem since new comments with active payouts can exist nested in the discussion thread of a months old post.) So what about up to 52 1-week long payout periods (which are only activated after the first payout if there is a new vote), and then a year after the post/comment was created, no new payout periods can be started?

You can compress comment objects down to HASH( author + permlink ) and check for existence, potentially using a bloom filter to detect non-existence. Memory access patterns can also be optimized.

The reality is that a single vote normally results in 0 payout and incurs a cost both at the time it is voted and later when it is rejected for insufficient payout.

We know that 99.85% of all votes (by rshares) are cost within 7 days. We also know that 99.5% of all votes (counted equally) are cast within 7 days. Actual usage shows that old posts don't get votes. In fact, we could get 99% of all votes within 3 days based upon actual data since HF 16.

We know that 99.85% of all votes (by rshares) are cost within 7 days. We also know that 99.5% of all votes (counted equally) are cast within 7 days.

This is a circular argument based on the current rule set (and UI). It can't be used to evaluate a different proposed rule set.

A similar (bogus) argument would be that comments only get 1% of rewards therefore rewarding comments isn't needed.

If it would be easier to find/filter "old" contend, then they would get MUCH more votes... The same would be true if the system would give more rewards to curators of posts older than 24 hours... So many gems not "mined" yet! Why throwing cement above our rich property ?

Old posts don't get votes because they don't feature. They are hard to find.

UI needs an advanced search page, by the way :)

Of course 99% occur in that time window.... who wants to waste today's voting power on something that will get paid out in 27 days at probably .001 SP?

if the technical stability is greatly affected then balancing the two (stability and a more streamlined reward approach) , 7 days would make more sense then 24h.
Still, some categories of users fall out of the employee range and fit into a more continual reward expectation: writers, musicians etc. and we might need to respond to their needs too.

On the downside, Trending posts algorithms need to be well thought and will bring their own downsides and benefits.

Edited to remove the 30 days reference which is proposed to be removed.

how will the 7 day payout scheme affect the daily trending page?

Not sure but I think the 2 would be independent.

ok thanks, that's what I think Ned said...
btw, get well soon!

Thank you! I already feel way better now that I slept all day.

KISS it, straight with indefinite and 24h cycle :):) That way it's simple for everyone and since 24h might be considered universally acceptable nobody considers it a downside as with the other timeframes.

It's true that I sometimes run into articles that are very valuable and were written a few months ago. We have writers around posting their stories. They can't be denied an effort reward after 30 days I think.

Long term rewards can be done via tips. Any individual vote has almost no ability to pay someone unless it works with many other users. This means that with the exception of a few whales, the long-term payouts would only apply to content that goes viral on steemit after more than a week delay. Possible, but unlikely.

This is a good approach. I think the calls for long term payouts would greatly subside with an effective tipping system.

A blockchain feature that makes sense for tipping is a change purse (with a user-defined max balance) that can be used to receive and send tips with only the posting key. Or alternately some sort of rate-limited tipping ability from the regular balance with posting key.

Perhaps with an automated aspect: if the payout is already made, you can assign a certain amount to be tipped by your simple upvote.

Then after the one week payment, let unlimited 30days payout cycles active...After mass adoption it would be very likely some gem-posts to attract several votes in couple of 30 days periods... Even not many votes would add up the rewards after months, years of the post existent.... After all the posts will be on the blockchain for eternity...

PS I guess it is vulnerable to abuse the reward pool, right?

Advertising could be a better source of long term revenue. Something for the future though, I don't think we're ready for it yet.

i think that a more streamlined (TL'DR-ish), layman description of the suggestions would be welcomed by the less tech savvy.

agreed.

Also opens the door to spamming by overflowing the blockchain with data.

This is a common misconception. The 4 post limit is per account. However, nothing prevents people from creating an arbitrary number of additional accounts (potentially thousands, and there are already people with thousands of accounts) to spam. Spam control is already handled by other mechanisms which are more effective than this one.

Also, even the 4 post limit doesn't prevent spamming with a single account, it just reduces rewards. Someone who wants to be malicious or annoying can still spam.

Also, even the 4 post limit doesn't prevent spamming with a single account, it just reduces rewards. Someone who wants to be malicious or annoying can still spam.

true

This post was about blockchain features, not website features.

true and thank you for pointing it out. I removed the Adds part which was exclusively website related. Other than that I consider all other items blockchain related.

  • Escrow is fully functional at a blockchain level.
  • SBD can also be heavily managed at the website level by controlling which payout options we expose.

duly noted.

I like it how you are making a distinct and clean space between blockchain (database / protocol) possibilities and presentation / UI features. This way you are making it possible for multiple interfaces to coexist over the same blockchain. Or even over the separate / side blockchains....

It shows vision :)