The behavior of recursive authority has always existed in Hive. Your link to the recent code is a red herring: it's just a refactor of previously existing code. You can easily see that by looking at earlier code in the repo where you can see that the constant HIVE_MAX_SIG_CHECK_DEPTH has long existed. Nonetheless, I briefly reviewed the code with the guy who wrote the code you mentioned and we confirmed to a reasonable level of certainty that the original code behaved the same way.
It's an intended behavior, and it existed in BitShares as well. I wasn't personally involved in the design of hierarchical authorities, but I vaguely remember discussions about it back in the day. The ability to indirectly delegate authority was considered an important function, since BitShares was designed to support organizations. I suppose these features aren't so important for Hive, since Hive accounts are generally just owned by individuals. But I don't think it is a good idea to change this behavior now: it is not a minor change and could have unintended consequences.
If you've given your authority to anyone else, they can always indirectly delegate your authority anyways by setting up a bot. In the end, I think the most important lesson should be that anyone who is accepting authority from a lot of other people should be very careful who they then delegate authority to.
Ah yeah I assumed it would be a minor change.
Like changing
HIVE_MAX_SIG_CHECK_DEPTHto 0 or 1.But I certainly know what it's like to rock the boat and realize you just broke a dozen other things that need fixing.
Thanks for the clarity!
It's surprising how many people on Hive don't realize this is a thing.
Yes, I meant it is not a minor change in terms of potential consequences, not in coding effort. For example, someone may be relying on this behavior (it is an intended behavior, after all) or at least planning on using it in the future. At minimum, it would require a hardfork, since we know that such transactions have already been added to the blockchain. On balance, I don't think it is worth changing.
That's fair.
I'm just over here doing my thing being overdramatic as always.
I always appreciate you coming in here to set the record straight...
And apologize for being an annoyance while producing potentially sensationalist content.
Cheers. 🍻
Is it time to introduce custom authorities? I really love that feature of EOS :o)
While it adds complexity, it also gives a lot more control over what type of permissions you are giving to others, so over time we could get rid of current dangerous "all or nothing" permission chain practices.
As I recall, I proposed the idea a long time back to other devs (at least BT ones and maybe others as well), and I don't recall there was much interest at the time. If apps devs come up with some good use cases, I don't see why not, but I think we should wait for that.
I've seen it mentioned couple of times on Mattermost, last time a year ago. The only problem I have with the idea is that I think it will be very popular (I know I'd immediately create separate authorities for each application I use), which would result in sudden increase of memory consumption, so I'd prefer we do it only after some aggressive optimizations around accounts that I've described in one of articles. Since introduction of state provider moved those optimizations from realm of "if" to "when" (with strong inclination for "soon"), I'm much more optimistic on the possibility to implement custom authorities in not too distant future. The use cases are already present - treat each application as a separate contract and only give them authority to perform actions that you want them to have. Apps would also most likely move away from attaching themselves to one of main authorities in favour of creating separate authorities for themselves. Now we have another reason - reduce depth of redirection to one. We can't do that on existing authorities, but we can on new.