The obvious benefits of the pool was not having to have inneficiencies in calculating the RC you want to delegate to someone. Not everyone is active every day so less RC would be needed to support more users. The second benefit was it could end up being less blockchain transactions than the alternative which I'll describe below... but the point is it does seem like there are alternatives which is a good thing.
questions
- Is there a cool down for undelegating RC?
- How much is the relative RC cost of doing a direct RC delegation to a user? Like what kind of transaction do you envision it to be?
- If we take the old steemit example and delegated 15hp worth of RC what percentage comparison would delegating and undelegating take? Tiny fraction or something like 1-2%?
- Continuing that example if we can delegate to a new user the moment they login to our site then maybe we can undelegate after x amount of hours or days away to free up that RC for the next new user. This example is the alternative that keeps limited RC more efficiently distributed but as you see it is a lot more hive blockchain transactions in order to manage it.
- Trailing delegations is of course awesome together with posting authority to piggy back on those who want to help the cause. This does of course double the transaction overhead for each case.
5b. So the sub question is do you see this being overwhelming at a certain point of daily users? At what point would it be problematic?
Cc @asgarth
Yes I agree with your points, I actually think it's possible to build a mix of both where you don't have pools but you still delegate "right to use rc" of the delegator similar to how pools work. Would be like a compromise between the simplest implementation and the most complex one.
5b. This is the whole thing we have to figure out in weighting rc pools vs direct rc delegations. The object of a delegation itself is relatively small , so we could have millions of delegations on chain without it impacting the memory usage that much. Then there's the performance impact which is something I'm not sure.
1-3. If there is no cooldown + it's a json with a very low RC cost... then i suppose it would be pretty easy for us to have an efficient allocation of our RC. Specially if people offer access to use some of their RC if we get low.
4-5. And yes you are correct we would look at the new users starting RC so it really would only apply to new users. And yes we would likely not have to undelegate RC quickly (thus creating another transaction) unless we ran into RC constraints. Also we can avoid the double transactions of 3rd party RC delegations through authority until there is a need... doing 2 each time such as a trailing seems like a spam ... better to just have one account handle it to be honest.