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.
- No
- It's a custom_json, so very small (although price could increase with usage)
- far less than 1%
- That's an interesting use case, not sure it's that interesting in practice though due to the inherent spam to the chain. Also most users will have enough rc to do things on their own, so you could just look if he has fewer than x RC and if so, delegate some to him. I like that you think proactively so that the user doesn't even have to worry about "I ran out what do I do" but maybe it could be done in ways so that you don't have to spam the chain something where if the user runs into an rc problem the error message say "you're out of rc, get some more by clicking here".
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.