It's overall a step in the right direction, but when I'd first heard of RC Pools I guess I was envisioning something a bit more automated and elegant. I'd imagine RC Pools tied to certain transaction types as opposed to individual user accounts, if such a thing is even possible.

I know that most (all?) posts contain some form of metadata that defines where the activity originated, as far as application, front end, tool, etc. I don't know if that's also true of voting activities. I feel that RC Pools should be tied to that information, instead of linked between each individual user account, which seems to still be a nightmare when scaling to tens and hundreds of thousands of users or more.

As an example, if Bob is posting his daily Actifit update, the system first draws from his own personal RC as is the case in what you describe above, if his balance is insufficient, it then draws from the Actifit RC Pool instead. Then Bob swings over to PeakD and makes a comment on a piece of art he really likes in the OnChain Art community. This RC cost is then auto picked up by either PeakD or OnChain Art. As a new user, Bob's experience is seamless, no requests need to be made for RC delegations, and the RC costs are being levied on the applications he's actually using. Otherwise, Bob may sign up through eSteem, get an RC delegation, discover SplinterLands, and spend his allotment of eSteem's RC on playing SplinterLands.

In the sort of system I describe, the three pools would essentially be relegated to different hierarchies of user, application, and community... quite possibly in that order of fallback. Applications and communities would ideally be able to set their own "rate limiting," blacklist certain users, etc. to control spamming and abuse of their RC. Applications could feasibly set a limit on both individual users and communities. In the example given above, PeakD may allow only 1% of their RC pool to be used toward any one community, ensuring a single popular community can't drain all their resources and harm the user experience. Then it's the responsibility of the community to power up HIVE and backstop with their own RC Pool to keep their members active and happy.

Communities are already tied to a singular account at creation that could serve as the RC Pool, Applications would have to have an account designated as their RC resource.

Whew. Hope that made some sort of logical sense.

Summation: Users should individually delegate into RC Pools of communities and applications that they want to support, but expenditure of RC Pools should be tied to transactions, not users, thereby removing the need to manage individual delegations across potentially millions of accounts. The minimal RC amount that all accounts are credited with at creation should be enough to ensure any new account can still make limited needed wallet transactions and other behaviors, while the heavy lifting of content creation and interactivity is automated on the backend and charged to the services being utilized.