Agree with that. One thing I will say is that RC prices are dynamic. If there is more usage from pools then the prices will go up. So you will need to delegate more per user to the pool than you might expect from average usage. The more apps/games do this the more prices will go up. This will also hurt low-HP users who aren't getting a delegation from an app/pool. It's also a negative for the price of HIVE if apps can get away with needing less HP to support their users (within reason; if the cost becomes too high then it becomes non-viable and they fail or leave, but there is a range).
Anyway, the points I just made are true but that wasn't really my intention in mentioning it here. My bigger concern is that the more complex solution becomes an obstacle in terms of completion and reliability (the later includes ongoing maintenance; once people start using it, it will need to be maintained if problems crop up, and this can be a future burden) if it takes resources away from other development. No question, as I said, the pool model is more powerful and useful, but the utility gap between no RC delegations at all and simple ones is much, much bigger than between simple ones and pools IMO.
We'll have to micro-manage thousands of small delegations and keep doing minor adjustment to the delegate amount according to how much each user is using.
Sounds very easily automated to me.
Mostly agree on all points. Just a few considerations:
I understand the concern, but having more users or more interactions should be a greater benefit for the chain. I mean it can be an healthy thing if the cost goes up because there are so many users that want to interact on the chain.
I agree on this, but we waited 6 months for the HF and it's good to have some solid improvements when it take so long for a new release. From my understanding most of the development is already done and hopefully we'll be able to test it properly :D
Fair point :)
Of course that is true. I imagine you will get more usage (perhaps a lot more), and at lower cost too, either way, certainly compared to no RC delegations at all. Needing to delegate or buy HP along with RC just to enable usage is a much higher cost.
The point I'm making here is that the biggest part of the savings comes from being able to delegate RC at all. There is some savings from pooling, because users can share delegated RC, but with sharing comes a higher usage factor, and higher costs, all else being equal. So the benefit from the latter will be muted, and also comes with the tradeoff of increased cost to users not part of a pool.
None of that is necessarily a bad tradeoff. As you say a lot of it comes down to enabling more usage, which is a good thing overall.