What about post-genesis payouts?
An Arbitrary Seven Days is Hogwash
I've thought for a long time about how the payout window is arbitrary, and ineffective. I've had some discussion about it with @remlaps and I appreciate the content he's put on regularly on the topic:
most recently, Addressing Steem's fundamental social reward challenge: One size fits all - fits nobody
There are some ways to distribute the burden, and manufacture a different payout structure, the way Thoth does. But even that is a side effect of the product, according to the creator.
One of the biggest issues I find with the 7-day window is that arbitrary timing like this is not how social discovery and sharing works.
At all.
How social sharing actually works
Posts go viral spontaneously weeks after they were created. Some giant account shares something from a relatively small account, or the content gets passed around suddenly because of how it relates to a current news cycle, and so on. It's organic.
We need a way to connect organic social actions to payout if we want to address the payout window problem, the daily delegator posts necessary to capture returns, the lost content problem @remlaps mentions in the above post.
I wonder about this:
Payout every seven days after any curation or voting action.
- Published - day 0
- 7-day payout
- Upvoted - day 100
- 107-day payout
- ReSteemed - day 110
- 117-day payout
I don't think you'd want edits to qualify a post for post-genesis payout. So, not all post activity would be considered.
The main thing I like about this is that if a post gets a single upvote 6 months after its genesis, its not like the "old" post is taking undue value from the pool that day. But if a post goes viral 3 months after its initial payout concludes, the author can get rewarded appropriately. And this is how we'd WANT the daily pool to be utilized: on content the community finds worthy of a vote (even if they don't discover it immediately after it's published)!
What do you think?
Just an idea that I think might have a better chance of being implemented formally than some of the others I've come across. So I thought some others might have thoughts on this as well.
How can we make this idea better?
What big considerations am I missing with a proposal like this?
Could you game this? How could that be managed?
I like the idea, but I have a feeling it would be a big challenge for developers. This problem has been known since 2016, and fixing it never got any traction from the core developers - even when Steemit had a big development team. I honestly don't know, though. That's just my guess.
In the long term, I'd love to see them implement something like what you describe here. You're definitely right that viral posts can happen long after 7 days, and this seem likes a good mechanism for recognizing the value when it happens.
In the short-medium term, however, I think decentralized mechanisms that make use of beneficiary reward settings have a much better chance at making an impact. There's a limitless set of possibilities that could be tried, if people would start using their imaginations. (see my post from tonight, for another example).
0.00 SBD,
2.14 STEEM,
2.14 SP
I can't claim to know the mechanisms involved in daily token release, and distribution for payout-qualified posts, etc.
But simplifying that is one reason I suggested additional 7-day windows when activated.
My programmer brain is thinking, "just plug it in as new content for the following 7 days after any additional activity".
Any other considerations can be abstracted away, or defaulted to whatever is most functional, at least for v0.1
Certainly, there are elements I haven't considered, and I don't know the capabilities of any Steem devs. But, it's not seeming like an unsolvable problem to me.
0.00 SBD,
0.33 STEEM,
0.33 SP
Something like this already exists. See eversteem (Introduced here). But, we're back to relying on beneficiary rewards in order to make it work.
The original posting account can't create the new content because the front end and the blockchain don't have access to the original account's keys. So, the new post has to be created by a different account with beneficiary settings pointing back to the original author and the new post would be the one that receives votes.
I never got past the language barrier to really understand how that site works in detail, but a front end could definitely create a new post whenever activity happens and manage the abstraction to make it all look like a single post.
Which relates to your other reply:
Yes and no. I agree that we can't realistically ask users to remember to update their beneficiary settings with every post, but the beneficiary settings can be automated (as-is done by Thoth & EverSteem) so that it doesn't add complexity for the end-user.
A simple example is that the front-end could set all replies so that a certain percentage of rewards go back to the original post's author or the author of the parent post. All the user would have to do is set or accept the default. Another example would be to link the "resteem" and the "comment" operations (like a Twitter quote retweet) and set the beneficiary settings appropriately on the comment.
Front-end developers have soo much flexibility here, and they're just not making use of it. I think this should almost be pri-1 for any/all developers who aren't working on the blockchain's core code (which is why I made Thoth my own pri-1 project).
0.00 SBD,
0.08 STEEM,
0.08 SP
Yes, I agree! This is currently the primary value add over any other social media, and Steem desperately needs an enticing distinction. It needs to be the most polished, dynamic, versatile, and legible feature of the ecosystem's flagship UI!
I'll check out EverSteem.
The problem with automation replacing manual technical configuration is that then the feature is not universal; you're dependent on the interface. That's still too much cognitive load, and not a solid user journey to get to a place where it's a smooth operation.
Best case scenario might look something like Steemit exhibiting some basic version of this, and baking in some additional flexibility that platform builders could utilize to create custom extensions to the idea.
0.00 SBD,
0.38 STEEM,
0.38 SP
I was thinking today that there actually might be a way that the core blockchain could get past the need for keys to the account to create the new posts:
This doesn't change the fact that I'm pretty sure there's nobody who can work on this for the foreseeable future - and it slips away from the "you own your data" model, but it might not be as technically intractable as I had imagined.
I get your point with beneficiary rewards.
I just think that has a high potential to go nowhere. It's too technical to be successful at scale.
I love the photo license suggestion!
One thing to consider, maybe: if an author moves to a derivative chain intentionally, they may want to license sharing to that chain. So, maybe provisions could include sharing on Steem and "authorized derivative chains".
If the author authorizes no derivative chains, then this functions exactly as you have it, so it only changes things for authors who decide to license to other chains.
0.00 SBD,
0.32 STEEM,
0.32 SP
I was thinking this wouldn't be necessary because an author could always share it elsewhere and apply a copycat license that applies to any of the derivative chains. According to my limited understanding, if the photo is shared in multiple places, this license would only apply to people who discover the photo here. (and I suppose they could even specify that copycat license when the photo is shared here, if they really wanted to.)
0.00 SBD,
0.08 STEEM,
0.08 SP
Oh I see. I was thinking about if they wouldn't want to share their entire catalog (or choose which items from it) manually, or invoke a separate license, but still wanted to allow other to use / share it.
0.00 SBD,
0.37 STEEM,
0.37 SP
I suppose there's no compelling reason not to add a provision like that to the license, and it probably makes logical sense from the perspective of a photographer who's using multiple platforms. But, personally I like the compartmentalization of having a separate license for each platform.