You are viewing a single comment's thread from:

RE: Make Steemit Great Again: Fork This Place!

in #steemit8 years ago
  1. I think there is a tradeoff that we should accept for the early hardforks: it's better to do them now, when the number of users is (still) low and move fast, than to wait until we will have (hopefully) hundreds of thousands of users. The more we wait to implement a feature (a hardfork-related one, obviously) the longer it will take for the feature to spread out in a bigger audience. From that point of view, I think hardfork fast, hardfork often is a good mantra (reminds me of a good old days of Linux: release fast, release often). Once we will have a smoother experience, we could stop playing at such a deep level and keep hardforks at a more superficial level of the steemit engine.

  2. I support all the features implemented in the HF17, except the separate reward pool for comments. I already wrote about that a few weeks ago.

  3. Related to your article, I think a lot of the proposals, if not all, could be mitigated by the most important change in HF17, which is "Multiple Arbitrary Beneficiaries to Reward Payouts". Basically, everybody can start a social media platform (or whatever content production service you want) and set up your own numbers. At that moment you will realize that the real bottleneck is not the distribution reward ratio, but the ability to create, engage, maintain and grow a community. That's something very, very different and much more difficult than coding. I've been doing this, at various levels, for the last 18 years. I'm still learning.

Other than that, I appreciate your contribution to the platform.

Sort:  

Basically, everybody can start a social media platform (or whatever content production service you want) and set up your own numbers. At that moment you will realize that the real bottleneck is not the distribution reward ratio

Who is going to rewards posts on that social media you speak of? what numbers are you refering to?

As I understand from the proposed implementation, other apps could participate in the reward pool and subsequently draw a part of it towards their own ecosystem, by using their own splitting schema. Think busy.org, with a different reward schema.

That's what I understand from Multiple Arbitrary Split of the Rewards Pool.

The Multiple arbitrary payout feature is a way for website like busy.org to receive a percentage of rewards earned on their platform but the distribution ratio issue will still be there.

In my understanding all content will compete for the entire reward pool, regardless of its source (steemit.com, busy.org), and the rewards are split differently according to each source/site algorithm. The distribution ratio may continue to be a problem in Steemit.com, but busy.org will have a different algorithm. That's what I understand, but I might be wrong.