I am glad you are working on this. Thanks! It is critical for mass onboarding without creating thousands of spam accounts.

It makes sense to me that all three slots should be able to be changed, but if it is going to add a bunch of work and delay things maybe that should be saved as a future update. Something now is better than nothing at this point in my opinion.

Since you mentioned this would not be in the next hardfork ... what is planned to be included in the next hardfork? I assume we don’t want to include RC delegations because there is a higher likelihood of it causing fork issues and we want our first Hive hardfork to go smooth for PR purposes?

As another note .... If the community had issues explaining HBD, Hive, and HP to newcomers, just wait until we get to explain RC delegations to them!! 🤯

Thanks for your feedback !

I wouldn't add too much work to let all three slots be changeable so that's fine.

In the next hard fork we'll likely have :
- Chain id change (to truly set us appart from the steem chain)
- Delayed voting (to avoid having exchanges powering up everything at once and then voting like they did before)
- Some fixes on apis here and there
- Changes on the sps to make it go from steem.dao to another account (@hive.fund)

On the complexity, the whole point of the way RC delegations are implemented where other people can set their slots, is to make it in order to offload the complexity to power users (aka the account creator / top witnesses)

Oh that's right! I forgot some of those changes, like the vote delay, have not gone into affect yet. It has seemed like Hive has been around for a long time, but it really hasn't. The quarantine has made me lose track of time and my mind.

Haha been there.

Can authors have their ten percent back now that the dev fund has ~90m hive?

> button to "ask for rc delegation" that would make the user set his personal slot to the game and then the app would delegate to it.

Does this mean that RC pool can not delegate RC to any account they wish to? First the user would have to set the right slot, yes?

I think this is worth clarifying.

As I understand it, due to the slots arrangement, it wouldn't be possible to delegate RC's to accounts without them confirming this was OK for a slot to be used?

Think I need to read a few more times :)

That's exactly it.

Right. Sounds like it's best to get the RC's delegated from the off then with the new account creation, likely as you say in the post with button.

Will be interesting to see how it's worded by the dapps, I don't think we want 'agree to resource credit allocation' - 'allow to power your account'? :)

As a dapp owner myself, I would probably just tell them "want more rc ? click here" and everything would be done under the hood. Even better I could just delegate a lot to each users knowing some will use more rc than others and overrall the use will be okay.

Fair enough. I'm just not sure resource allocation or RC's are what new users need to hear/read. So the terms to say, 'let us kick-start your account with the ability to post, comment, vote' etc, would make more sense.

I've recently on-boarded a technical new user, and they are still blown away by the terms we pass around like everyone should know what they mean.

I tried to look for your proposal on peakd but couldn't see it? Would like to support, cheers.

Oh I think the actual flow for an account getting created would be

create account -> delegate rc to it -> if everything goes well user never feels restricted by rc.

And yeah complexity is a big problem, Before steempress with @fredrikaa we were thinking of building an onboarding tool that basically explains everything to you step by step and then creates an account for you and help you make your first introduceyourself post.

Thanks ! You can find links to vote here: https://hivedao.com/proposal/97 and on peakd I can't give you a direct link, but I am near the 12m mark

yep an rc pool cannot delegate to any account they want.

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.

That actually made a lot of sense, but there are a few issues with the system you are describing not taking into account the fact that it would require to rework the rc system to its core.

First there are currently no way of tracking some transactions and linking them to an app, there is actually a task for it somewhere. But it would be something like the "app" tag that we sometimes put in the post metadata, it's something that's useful for some UI changes here and there but shouldn't be used for important things like RC, because anyone can say "oh I am doing this post via actifit" even though it's not, and then steal RC from that pool, that could be solved by letting apps do some kind of signing on the transactions, but it complicates quite a bit the process.

And I disagree that it should be linked to transactions, because then nothing stops one spammer from using up all the RC and leaving the pool dry.

Without a doubt the biggest problem is that a system like I'm describing is ground up different than what's already in the works!

As long as pools can set automated rules on how their resources are allocated, I don't see the spam factor being problematic. Limiting accounts to (x) transactions or (x) RC per day would be sensible. It's a shame that transaction tracking isn't more robust, but it would certainly take a power user to tag their posts in such a way as to just siphon some RCs off an unrelated application. If you do consider that a serious concern, then that just speaks to the issue that primary front end applications are going to bear the brunt of RC costs, even when not used directly on their platform.

My main concerns are that it be pretty much seamless for new users to acquire an RC delegation, they shouldn't have to hunt for a frontend, application or user to provide it, request it, and wait for approval, and that applications can effectively manage their RC delegations. The pool as a "slush fund" of sorts with an attached ruleset is simpler than direct management of potentially millions of outgoing delegations, even if employing scripts and bots to help manage the task.

Side question:

>Another real life example:
Alice delegates 50 rc to her pool
Bob changes it slot 3 to Alice
Alice delegates 30 RC from it's pool to Bob (Bob can now use the RC)
Alice tries to delegate to Eve, but since she didn't set a slot to Alice, Alice cannot delegate RC to it

In this example, are you able to differentiate in advance whether you're delegating to a user directly or their pool?

>Each account got an RC pool in his account, anyone can delegate to any account pool, that RC won't be usable by the account, it's just a pool he can delegate RC from. (he can delegate to himself if he wishes).

For instance, even without Eve setting a slot for Alice to delegate RC to, can't Alice delegate to Eve's pool without Eve's consent, and then Eve can simply route it to herself?

What's the purpose of the extra "whitelisting" step? I'm not seeing the benefit for the added complexity. We don't force people to accept a Hive Power delegation which is more impactful as it conveys RC and voting power in tandem, so why the extra limitation on RC alone?

If I'm understanding the system correctly, my suggestion for the current slot allocations would be to change #2 to the user account directly, and have their personal RC pool potentially feed into that with no approval or as seamlessly as possible, such that when Alice tries to delegate to Eve, Eve will see the benefits immediately without the complexity of needing to reassign a slot.

Here is a direct link for @howo's proposal.

https://hivedao.com/proposal/97

I think that one slot is enough anyway, why would you need delegations on two different slots? If you're a business that needs a lot of RC, then yeah, you might use the three slots but in this case, a business can easily deal with the complexity of that system. There is no need, to change the code too much if it is sound.

I just give an opinion because it was asked but I really think that you would have a better idea regarding what to do (along with other devs).

Thank you for your opinion :)

Well you might want multiple slots to recieve delegations from multiple actors, say 500 rc from the service that created your account and 1000 from that game that you love to play.

Aren't RCs usable across all Dapps? For instance if you delegate to me 1000 RC then I can use them anywhere, whether for PeakD, Splinterlands, or transferring to an exchange.

In that case, one delegation should always cover all needs unless the consumer of RCs is a big Dapp which needs 3 RC delegations from 3 big delegators.

> Aren't RCs usable across all Dapps?

Yep

> In that case, one delegation should always cover all needs

Well depends, let's say steempress has to create a lot of accounts, we probably won't delegate enough for you to post/comment 20 times per day, probably enough for 5-10 posts to get you started. And if you don't get hive power, you may end up needing more RC, and then you could ask another dapp for an rc delegation, because steempress won't have enough rc to give you more.

I see, thanks.

This is litterally the first time Delegation Pools have been attemtped to be explained to most of us so bear with us/me as we ask some questions.

It appears one account can contribute to 40 pools.
But one application can make as many accounts as they want so the number of pools to manage can be pretty infinite and hopefully automated.

So how many users can share from a pool?

Also it appears from the 120RC delegated example with 4 users sharing from the pool that it seems like the limit is proportional? Because you said 30rc per user.

Does the pool limit per user have to be proportional? That sounds like RC was being set up to directly benefit the steemit system of allocating 15sp to each new user.

A non-proportional may lend to the apps (RC delegators) to be more attentive to RC abuse. Just not entirely sure of the reason for proportionality because so many users won't use their proportion allowing for lots more users to have RC but with proportional you kind of have to plan for the worst case user.

> This is litterally the first time Delegation Pools have been attemtped to be explained to most of us so bear with us/me as we ask some questions.

Please feel free to ask anything, I made this post for that exact reason.

On the 40 account limit : the pool is not the end goal, I was confused by this too, basically :

may users can delegate to one pool, and each user can delegate to 40 pools max. The rc in the pool can then be used to be delegated to users, and then you can delegate to infinite accounts if you want.

Here's another example:

A,B,C delegate 30, 40, 60 rc to A's pool. A's pool contain 130 RC, but A can't use that rc to transact, A must delegate RC from that pool to users and then that RC will be usable.

Basically, the act of delegating RC doesn't happen when you contribute to a pool (40 per user), but when you delegate out of that pool (infinite).

Delegated RC out of a pool is not proportional, you can freely delegate 500 RC to one user and 3 to another. It's up to the pool owner to delegate whatever amount he sees fit.

OK putting RC into a pool may be complicated but really that's only a few people doing that. What we want to know is how to get the RC into the hands of users who do not have much RC>

We will see apps like ourselves and splinterlands putting a ton of RC into a pool for our users to use. Which will number into the thousands ... hopefully eventually tens of thousands (or more) users.

So i'm rereading what you wrote and it's not really clicking yet.
How does that part work. PeakD uses 100k SP worth of RCs. How does it go from there? Let's say there are 1000 users that need RC.

You delegate from the pool to each user let's say 100 hp worth of rc . And that's it assuming they have a slot set to steempeak.

In the coming days I'll post an example script, it'll make more sense for everyone if it's a more concrete example :)

Is there a particular reason for the quantity parameter to be 40? What not 50, what not 25? (Kinda seems like an odd number to me)

I don't know why they picked that specific number, but I know the number of delegations is limited because of performance issues, so I assume they did their math and that number came out.

It's because I'm wondering if a max count is the best solution or a min size is a better solution.

A big account (1 million HP) might want to lend to 100 accounts. This account would have its HP into three accounts to do so. A small account could also do 40 delegations (let's say a 400 HP account) each 10 HP and tax the system too.

Ah I must have confused people with my explainer, see my reply to jarvie above, delegating to a pool is different from delegating rc to a user.

I'll add something to the post itself.

Sorry, my terminology was equally confusing. I meant delegating to pools not accounts. Like to a bunch of different communities for example.

Yeah I realize that now haha. Well I think 40 is a lot already, I don't think there will be that many dapps/account creation services. And even if there are, and the whale insists on delegating to all of them, the whale can make another account delegate hive power to it and then delegate rc to 40 more pools

What is the benefit to the account delegating the RC's ? Will it be just to support projects out of Goodwill or is there a Return on Investment? I's be happy to delegate either way, I'm just curious what the motivations would be.

This is a good proposal to say the fact but the issue I have here is that of the account creator that is still linked to Steem Blockchain that would be affected at the long run. I thought Hive is hard fork of Steem, why can't we create code to deal with that, although I know this would be tedious. But it's a good idea, because any idea to make Hive Blockchain a better chain is a welcoming idea to me.👍

hey bro you share a good info i will support you

Congratulations @howo! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :

You made more than 1500 comments. Your next target is to reach 2000 comments.

You can view your badges on your board and compare to others on the Ranking
If you no longer want to receive notifications, reply to this comment with the word STOP

Do not miss the last post from @hivebuzz:

HiveBuzz - Hive Gamification Experience

Vote for us as a witness to get one more badge and upvotes from us with more power!

I know I'm a little late to the party, but I'm wondering why this very complex system is necessary. I think a much simpler system would suffice for the majority of use-cases.

I can see why the current system doesn't suffice. If you delegate HP, you delegate RC and voting power. This is a way of saying that you approve the actions of the user you delegated to. A large account creator can't check all actions of all their created accounts, so they can't trust them with their voting power. They do want to give the users enough ability to interact with the blockchain so they can start earning their power. That's where RC delegation comes in.

A probably much simpler way of implementing RC delegation would be to make it similar to HP delegations. You delegate a portion of your max RC to a single user. That user can use that RC to interact with the blockchain. Most required code can probably be reused from the HP delegation codebase. 1

This simplistic version indeed doesn't cover all use-cases that RC pools cover. As a dapp who provides accounts, you can't use community delegations to proxy to your new users. There's also no 'oversubscription', so the max RC delegated to the dapp users will be a lot lower, possibly low enough to run out. 2

On the other hand, this simpler system would allow every user to support any other user they want to support, without them spending an 'RC slot'. I have a mere 78 HP at the time of writing. That's not much voting power, but I never get below 80% RC. If I encounter a new user who brings great value to the blockchain, I am not in the position to delegate HP, but I would be willing to delegate some RC to them.

I believe that if we make it easy enough to delegate RC to others, there will be much less pressure on the account creator to provide the required kickstart RC. Instead, the community will be able to take care of most of it. The only problem that remains is blockchain games. Those systems usually don't promote new players to write posts and earn rewards before playing. That would require too much effort, so a dapp delegation is required. But I highly doubt that this single use-case justifies the complexity of this system.

Conclusion: I think this system is implemented to ease the life of large, singular entities, onboarding massive amounts of users while being irrelevant for small-medium accounts with sufficient RC. I believe that if we build a system that empowers everyone, small to large, to help out brand new users who make quality content, we can solve most problems those singular entities have while increasing decentralization, and decreasing complexity.

1 I can't say with certainty that this is a simpler system to implement. I only assume it is because of its similarities to HP delegation. Please tell me if I'm wrong here.
2 It is likely that I miss some use-cases. Some of them are not covered by the simpler system.

Direct peer to peer delegations have been thought of, and while it does bring a lot of simplicity, it also lacks a lot of the flexibility that pools bring (oversubscription), and when you think about it how often do you find yourself in a position where you want to delegate rc to people ? That happens very rarely for me as an user, as a dapp owner though that happens quite often when I create accounts (which is handled by design).

I think rc delegations will be something very few users will actually do. And if you want to contribute yourself to someone else, I bet there will be front ends to do it to hide some of the complexity.

And finally I envision that pools will be smart and always overdelegate because nobody uses all of their rc. So if you want to contribute to an user, you could just delegate that pool. Because in the long run, pretty much everyone will either have hp or be fed RC by a pool until they have hp.

My point is, I think there is a use case for direct delegations but it's a very niche one, and I don't think it's worth the added complexity of supporting both at the same time, or the time spent to undo the current system and make it a direct peer to peer one.