A week ago, I wrote an article describing how the upcoming RC delegations could present a no-compromise option of supporting newbies freshly out of RC, without granting them immense voting power at their infant stages. Such a simple concept as this could open up the door to many more sorts of RC-intensive Layer 2 applications to be built atop HIVE.
The model of RC delegations utilized, and the origin of the problem that will sooner or later buoy itself, is that it's peer-to-peer in nature.
This model is self-defeating to the concept of RC delegations as a whole. Because the process of looking for newbies in the wild is an exhaustive one, only a handful would be on active look out for those promising newbies.
Not to mention that newbies are volatile. Of a hundred of them, the ones actually sticking around are going to be much lower. Imagine how many moot RC delegations are going to be there shouldered upon those ones actively looking for newbies, hogging up valuable RCs for the actually promising ones out there.
RC delegations are a fantastic idea, just not in its current model or form. In order to successfully, and meaningfully, delegate RCs to newbies, the one delegating would have to look for a newbie, keep up with a newbie, check on that newbie, whether that newbie ended up leaving HIVE for good for an extended period of time... and so on.
This is an exhaustive process made herculean because no one is going to delegate to just one newbie.
A much more viable model of RC delegation, one that encourages actual use, would be an automated pool of RCs assigned to the origin accounts of tribes and community frontends. A massive number of people, that way, could directly delegate to that pool, functioning as a reserve intended to support newbies.
This is great, because RCs by themselves are a filter in essence: The newbies quickly exhausting their RCs are the ones prolifically posting and commenting. The origin account of the frontend being posted to, could then automatically delegate RCs to that newbie.
Spam is not an issue. The automated RC pool could decide which newbie is posting meaningfully, and which is spamming incessantly. The automated structure could synergize with Spaminator, checking for downvotes on a newbies post, utilizing that as a marker for whether or not to delegate.
Such a model was indeed in the works, and was geared for implementation as well, at the birth of RC delegations. Alas, it didn't pan out favorably at all. Reasons it didn't are confined to UX-simplicity, and the complexity of RC pools involved, code- and transaction load-wise.
RC delegations are cool. They encourage worthy newbies to stay and engage more within the HIVE ecosystem. That, though, is arguably bottlenecked by the overtly complex onboarding process, complicated, ironically, by the simplistic nature of peer-to-peer delegations. What use are RC delegations if we don't open wide the floodgates? I myself almost gave up entirely on that part, and I'm glad I didn't.
Thank you for reading!
