I think the motivation of supporting developers is sound, but I'm not a fan of this idea. The "lots of small accounts sacrifice for the benefit of a few accounts" pattern is kind of the opposite of what the ecosystem needs. That dynamic is also bad from a relative cost/benefit perspective: the smaller your account the bigger sacrifice delegating away 5 of your SP will be, but the bigger your account the smaller the benefit of receiving a 5 SP delegation will seem. From a utilitarian POV, lots of people making painful sacrifices so that one person can get a few extra drops in their bucket is a bad dynamic. Also, if developers have SP delegations with the expectation that they're supposed to use them for their own benefit it incentivizes them to use their votes to get the best curation rewards, which are those posts which are most likely to have high rewards after 7 days which contributes to both a rich-get-richer dynamic in the ecosystem and an internal conflict between authentic and financially-motivated voting in the person who received the delegation.
RE: Introducing Developer Delegation Day (DDD) on the Steem Blockchain
You are viewing a single comment's thread from:
Introducing Developer Delegation Day (DDD) on the Steem Blockchain
IMO, it's not a sacrifice. It's a trade. A small delegation in return for use of some developed product that the delegator values. Without some sort of exchange in value, the existing development landscape is smothered by a free-rider problem.
Some people subscribe to multiple Substack creators, and there's no reason that delegators with larger accounts can't do the same (or increase the delegation to a single account). For the first round, I think there are 3 or 4 accounts that I'll probably delegate to if this gets any interest. And, of course, there's no one saying that anyone needs to delegate anything at all. It's no different than asking for contributions on an Open Source github site or wikipedia. Lots of people use the products without donating, but valuable products manage to stay afloat from the voluntary contributions that they receive. The only difference is that this "gift" is revocable if the developer doesn't live up to expectations.
And yeah, 5 SP is a small marginal increase for a high-value account, just like a dollar a month is small for a Substack operator with hundreds of thousands or millions in marketing, staffing, and operating expenses. That's just how subscriptions work. I don't see it as a problem.
I also thought about this, but I concluded that developers who abuse the delegation will be less likely to receive new delegations in the future, and they might even lose whatever delegations they receive. I think there's some natural oversight that will happen here.
After sleeping on it, my main worry is technical. What if one developer delegates to another one month and the second delegates to the first in a subsequent month? Are delegation loops allowed, and if so, did the blockchain developers test out what happens with multiple layers of looping delegations? Does Steemit have a team that can clean-up the mess if it tickles a bug and halts the blockchain? It might be good practice to delegate from one account and receive delegations on another.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
When you're framing this as a mass movement you should look at it from the perspective of where the masses are, i.e. small accounts. The implication of the way you've framed the whole endeavor is that this is a way for people to positively participate in the community.
Seems unlikely to me, like with witness votes I think people are unlikely to actively monitor what the people on the receiving end are doing. Without any kind of reset or decay I would expect most people to do a set-it-and-forget-it kind of thing.
I haven't looked at the code, but my first guess would be that delegations are limited by actually-owned SP, so there would be no loops, what has been delegated to you has no impact on what you can delegate to others.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
And I think it is, but I also recognize that there's no such thing as "one size fits all". The choice of 5 SP was to come up with a least-common-denominator that is possible for most of the community. Sort of an 80/20 rule...
Another point that I neglected to mention is that - as with SPUD - if the initiative were to catch on, I'm sure we'd see people posting about their delegation decisions. And this would give crucial feedback to developers about what ideas are valuable to the community, and it would also turn into a way that people could collect rewards for their delegation decision-making.
I was never a fan of those posts with the SPUD initiative because I thought they were valueless, but in this case I think they would provide useful information.
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit