You are viewing a single comment's thread from:

RE: What about post-genesis payouts?

in Open for Product4 days ago

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.

Sort:  

My programmer brain is thinking, "just plug it in as new content for the following 7 days after any additional activity".

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:

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.

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

I think this should almost be pri-1

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.

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:

  1. Create a new "special account" like @null or @steem.dao
  2. Use that account to create new posts when an account receives votes after 7 days with 100% beneficiary set to the original author.
  3. Create something like a "pass through vote" operation that forwards votes from the original post to the new one.
    • The potential stumbling block in this step is that it might be difficult to find the new post from the old one - without scanning the entire blockchain or adding a reply to the original post. I suppose the new post could even be the reply, but that starts to look kludgy.
  4. Provide updated API calls that deliver merged information from the original posts and all follow-on 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 like the direction. My brain is too sleepy right now to think through it, but I'll put this on the backburner. We should keep brainstorming.