Turning Beneficiaries into a More Powerful Feature
Currently if you see something interesting on Steem and want to share it you only have one option in terms of features specifically built for that, which is the "Resteem". A resteem is cool, it can definitely be beneficial to you as an author, but I think there are more powerful options that Steem is capable of doing that we should take advantage of.
Quoting myself from a previous post:
What Steem has now, is a ton of functionality. But it's severely lacking in "features". To define those in the context that I'm using...
- A Functionality is something the blockchain has the capability of doing.
- A Feature is a functionality implemented into something a user engages with that hopefully gives them a positive user experience and solves some problem for them.
For each functionality, you can have several features. ie different ways of doing the same thing.
Some very powerful functionalities of the Steem blockchain are
- Upvotes
- Direct Transfers
- Beneficiary System
- Delegation
One of the ways I've been trying to make my Community OnChainArt a better place is by sharing old, long dead, but very high in quality posts called the #steemartarchives. I set the artists featured in these posts to 100% beneficiaries which of course not only shares this artwork to a new set of eyes, but also rewards these artists for posts that were no longer eligible for rewards.
It hasn't taken long for me to realize that this is extremely powerful and I think worth turning into a feature to incentivise users to share content in this way.
I think one of the issues with Steem is the 7 day payout period. I get that it's necessary, but I've always thought that it doesn't really make sense from the outside looking in. Once someone posts their content on the Steem blockchain, that content is now a blockchain resource FOREVER, not for seven days. If I created my own frontend three years from now, and cherrypicked my favorite posts, then monetized that frontend through ads, that content is still creating value. That's just one example, but the general idea is that content doesn't stop providing value to the blockchain after seven days. I think this can and should be addressed.
So what I'm suggesting is something that would essentially be "Resteem as New Post". So maybe when you click the "Resteem" button you get a modal window with two options.
Resteem this Post or Resteem as New Post with short descriptions of what each one does. This way the user doesn't need to have it explained to them what beneficiaries are. They will be introduced to it without having to understand what it is or how it works.
This would also address the 7 day payout problem, while also incentivising sharing on Steem which I think needs to have a larger push in regards to the UX here. When people have a reason to share the best content, regardless of payout status, there is a better chance that the best content on the blockchain will remain visible forever as well as being rewarded as long as it's creating value.
I think this makes a bit more sense and would make Steem more attractive for creators whose content doesn't "spoil with time". Like if you post about crypto prices, or news, it makes sense that that content have it's moment in the sun then fades away, but if you're an artist, musician, video content creator etc. Only having 7 days to monetize your content is a shitty sell.
This in conjunction with Tips/Donations I think would dramatically improve the user experience on Steem.
What do you all think?
#steempeak
#peakreview
As I think this would be relevant to you all as well.
To listen to the audio version of this article click on the play image.
Brought to you by @tts. If you find it useful please consider upvoting this reply.
I know we’ve talked about similar functions before. I’m still a fan of a “ReSteem with Comment” type feature that leaves the person sharing an opportunity to add additional commentary and thoughts if they choose, and gives a small 10-20% of the author rewards to the person sharing. It opens up a second level of curation and the capability of “evergreen” payouts and viral size payouts for authors!
I don’t see the need for the two different options you describe, I’d rather have one flexible implementation.
I think the system would be largely self policing as those who spam too many shares, particularly of low quality, will be quickly unfollowed, muted, etc.
With any of our proposed systems here, one question is how does it interpret a Resteem of a Resteem? If a new top level post is created by the person sharing, that post would be capable of being shared as well... so there needs to be some sort of data field that always links back to the original author and not just the next link up in the chain.
I’m still a fan of Resteem + Commentary. I think all these options could be elegantly combined into a unified feature. I don’t have much faith in self policing so I thing making resteem + commentary a mandatory like 80/20 split would be the best way. What I think would happen is obvious no effort spam would get shut down, but people would find that bare minimum that others would accept without negative consequences.
But yea, even with that, I’d still want a quick and easy feature that just shares and has a mandatory 100% beneficiary set.
Also get what you’re saying about the technical hurdle of always linking back to the OP’s post but that seems like it can’t be too challenging technically.
A frontend-only implementation suggestion:
Rather then posting a completely new post, post a JSON Obj. as a post (custom JSON cannot be voted on to my knowledge?), structured as such:
{
"ctx": [
[
"post": <STRING: post URL>,
"time": <INT64: timestamp>
] ... // as many as needed
],
"post": <STRING: post URL>,
"time": <INT64: timestamp>,
"com": <STRING: HTML comment || NULL>
}
When sharing a regular post, ctx is null, post is the post's URL, time is sharing time and com is any optional commentary. Beneficiaries e.g. 20% sharer, 80% original author
When sharing a comment, ctx is original post's URL, post is the comment's URL, time is sharing time and com is any optional commentary. Beneficiaries e.g. 20% sharer, 40% comment author, 40% original post author
When sharing a share-post, ctx is a merge of shared post's ctx and post fields, post is shared share-post, time is time of sharing, com is optional commentary. Beneficiaries e.g. 20% sharer, 40% shared share-post author, 40% divided equally between ctx authors
Any other identifier could be also used instead of the URL. (e.g. a partial URI or other identifier)
Each share-post would DISPLAY as ctx at time of sharing (with link to original), post at time of sharing (with link to original), and commentary (HTML).
It's quite a bodge but it's frontend-only.
As always, I'm open to suggestions.
Apologies for brevity, composed on a mobile device.
I definitely think that beneficiary rewards are underutilized. I wrote about that back in September, in Collaboration rewards: An underutilized feature of the Steem blockchain. I've been sharing beneficiary rewards with other Steemizens in my #rsslog series of post for somewhere close to a year now.
I'm in favor of any front-end changes that make it easier and more intuitive to share beneficiary rewards. I think I'd prefer "resteem with comment" instead of "resteem as new post", but either/both could work if they were connected to a rational default for beneficiary settings.
Ive seen that idea that you are deploying and think its cool. Now, in order to actually give the rewards to the author as you claim you should set @likwid as beneficiary, then send the rewards to the author, for as things stand you are keeping half of the author rewards.....
What? How do you mean?
oops, my mistake, mental lapsus, sorry.
I’ve never noticed this behavior using beneficiary splits. Those percentages apply to both the liquid and non liquid portions of author rewards I’m 99% sure. One interesting artifact/glitch that I’ve noticed in Condenser is the author rewards disappearing completely from the displayed value tally post payout. When setting 100% of awards to another beneficiary, when payout concludes you’ll see the post value cut in half and the author rewards displayed as $0.
Yea, just checked to confirm, but when you set a beneficiary it counts both. Thank goodness because that would be so much more of a pain.
I think this is a neat idea, by allowing content creators to have the chance of monetising their content longer. One of my biggest turn-offs about Steem is the 7-day earnings window, and its the reason why I've seen some Steemians migrate their content to other platforms, like Medium, where they can keep monetising for the long-term.
I think having the option to Re-Steem your older posts (with earnings), while also including a Tips/Donations tab for users to want to support creators, even after the content's been published beyond 7 days, will definitely help to get more content creators onto the platform. I hope these changes will be considered for the next additions onto Steem.
Yes please I like this idea. And possible bonus people like me could just new post ourselves when posting something to communities.
And even better if either of those could include the resteemer being able to write something about why they're resteeming (I know some people like to do that and in my case occasionally I just like to make smartarse comments).
I'm wondering why there is a need for a single 7-day payout window for posts. What about multiple 7-day payout windows? So every 7 days the blockchain will pay out any new upvotes a post gets. But each account can upvote any given post only once in the post's lifetime.
I guess the main problem with something like that is potential abuse? Or is there something else?
The problem of your suggestion is purely technical, the computational power required to payout post rewards would linearly grow indefinitely. This way STEEM can "stop thinking" about posts it has already paid out after a week, which means less stress on the Witnesses' servers.
You can't keep increasing the number of posts to pay out forever.
Actually, thinking a bit more, I am not sure that is right. Maybe it's not the number of posts that increases computation but the number of upvotes. And given that a user has about ten upvotes per day (due to voting power decrease), it would seem that the number of upvotes would stay consistent, whether people can vote only on new posts or on new and old.
From the SMT Creation Wizard, I see that there is a parameter called Cashout Window, which I think is the payment period length. As I can see, the maximum value (as per the wizard popup text) is 4294967295 seconds, which by my quick calculation is 136 years. What I am not sure about is whether this is a single-event cashout window, or multiple cashouts can be allowed for SMTs. Maybe @gerbino or @vandeberg can clarify that.
It would be absolutely epic if SMTs can allow for Type II content to become a first-class citizen.