Timestamps
0:00 - Intro Slide
4:48 - Meeting Starts / Dev Updates
10:45 - Owner's Key Discussion -- Does Key Do Too Much?
12:00 - What about the master password?
14:20 - Account Recovery Settings
15:40 - Beem Mirror
22:40 - Python Unit Tests vs. Node Unit Tests
27:08 - RC Delegations on Hard Fork 25
30:20 - Miscellaneous End Talk
If you're listening to the whole thing, please post timestamps as a comment, the first one to do so (and correctly) will get a 100% upvote from me :)
meeting tl;dr:
Dev sync
as usual it's better to listen to this part
Limiting owner key's role to only changing keys
The owner key can basically do everything, that's a problem because it really only should be used for updating the other keys, we are thinking to drastically reduce it's capabilities in hf26 so that you can only use the owner key/authority to update your keys. It's basically security by design, if you can't use your owner key, there are less chances of you losing your owner key because you entered it on the wrong website.
Then the discussion went on the master password which can be used to derive all the other keys, which is obviously an even bigger security risk. We are thinking of just removing the capacity from libraries to generate keys from a master password so that front ends won't feel enclined to offer a "login with a master password" feature. But there are UX tradeoff where now the user has to juggle with multiple keys, although that's less relevant now that we have great key management systems in place like keychain.
set_reset_account_operation doesn't prevent you from setting yourself as a recovery account
Response from @gtg: "it's a feature not a bug" 😄
basically setting yourself as a recovery disables the recovery (which is intended) and you can't set @null because then witnesses would still be able to recover your account.
beem mirror
@holger80 will be happy, this whole discussion is about how we are mirroring the github beem instead of using our own version. There are still a few things the @blocktrades team need to do but we should soon have a great setup.
python unit tests vs node unit tests
I recommend that you listen to this one, it's hard to summarize (and not that interesting)
Rc delegations on hf25
It's still a question mark whether we include it in hf25 or not. I will test it for a week with others (@good-karma has shown interest). And we will then see if it's stable enough to be included or not.
Support what I'm doing
If you like what I'm doing, please consider voting on my new proposal:
https://peakd.com/proposals/167
hivesigner
Timestamps
0:00 - Intro Slide
4:48 - Meeting Starts / Dev Updates
10:45 - Owner's Key Discussion -- Does Key Do Too Much?
12:00 - What about the master password?
14:20 - Account Recovery Settings
15:40 - Beem Mirror
22:40 - Python Unit Tests vs. Node Unit Tests
27:08 - RC Delegations on Hard Fork 25
30:20 - Miscellaneous End Talk
Thank you !
These are super helpful I love seeing them
What happens to the people who have the same key set for everything? A quick hivesql query(
SELECT * FROM Accounts WHERE owner=posting AND owner=active;) shows that there are 18080 accounts like that. A lot of them were threespeak related, and changing the query to skip those(SELECT * FROM Accounts WHERE owner=posting AND owner=active AND owner NOT LIKE '%threespeak%';) still results in 15606 accounts like that. Will they be forced to change their keys? I'm sure that some people are actively doing that to use the same key. Checking accounts created in the last year(SELECT * FROM Accounts WHERE owner=posting AND owner=active AND owner NOT LIKE '%threespeak%' AND created > '2020-04-01';) results in 24 accounts. While thats not a lot(less than 2 per month on average), leaving the option for advanced users(I saw that marky and deathwing made a few of the accounts that have the same keys) to have more control over their keys would be best would it not?They can use their owner key to generate new keys and continue on.
afaik the threespeak accounts actually don't have keys, everything is done via authorities, and they generate the keys only if the user asks for it.
That's a good point though ! I'll bring it up when we start working on it.
Yes and if peakd jumps into simplified custodial accounts for users who want a simple experience we would do the same thing and not even generate keys for those accounts until the user is ready to take on responsibilities themselves
I think the best solution here would be just UI changes. Just don't let users use the owner key to sign in and that should solve it. If they aren't used to using it, they might think twice about putting it in new places.
Good to hear the dead witness vote is done, still one year later and still finding dead code, you guys certainly had your work cut out for you.
At about 9:50 - The two system approach, c and sql, sounds like a bit of extra work, but also sounds like a good safety approach. It shows how safety is a priority to the folks at blocktrades. Two approaches and find the most effective one to use.
One to two weeks to test and hopefully include the RC work in the code freeze would be great, also good to hear not long before the code freeze and testing to begin for the hard fork, it has been a good year, here's hoping for a solid second year also.
thank you for the post and vid link.
I expect that we'll continue finding some for many years, hive is a very big codebase with a LOT of legacy code.
on the two approaches well as bt puts it, there is no way to know which is best until we try them out so :shrug:
Second year will be much better for sure :D The first year was a lot of cleaning up, now we are starting taking off with tangible new features.
Getting rid of the master key and limiting the owner key to only key generation is a great idea.
It cuts down on key complexity and prevents use of the owner key in everyday use.
yeah exactly, the drawbacks are very minimal imho
Limiting what the owner key can do does help and seems better for security so people can't use it except to rewrite their keys.
Did they say they would get rid of the master password?
Also why is it called a password and not a key... never quite understood that.
As far as I understand, getting rid of the master password is at least on the table. That's why I'm making a case for it.
Owner key and master password might just be remnants of early ideas. Ideas that never came to fruition.
There are probably people better versed in Hive lore than me ;)
It looks like this is something where front ends cooperation is expected as well. From the summary:
Hello @bluerobo
This is my own !BEER
Have fun with it!:)
You need to stake more BEER (24 staked BEER allows you to call BEER one time per day)
great suggestions. Hope that RC delegation can bee included!
Doing my best for it to be !
Nice review
Like others have said, I'm also hoping RC delegations can be included. If it means delaying the hardfork for a couple of weeks so more testing can be done, then no big deal.
Yet one more person hoping for RC delegations to be included. I would see to it that Peakd quickly create some UI for that new tool set... I'm hoping even during the testing period.
Maybe we don't NEED rc delegations right this moment or within the next 2 months. But we are very certain we are going to need it before the following HF which sounds like could be 4-6months after this next one which is 1-2? Months away.
We would like to launch or pretty big marketing project we are saving up to do and we think RC pools will be a huge win.
It seems Rc pools helps to avoid the abuse inherent in creating delegation bots that give accounts voting power.
Also can you break down what the proposed changes to the keys may be? I think I get it but want to be clear
I also believe RC pools make sense this year. And there won't be another HF in 2021, most likely. But I also think it should be pushed to the HF if it's stable, it would be far worse for Hive if we have major issues after the HF and before the end of the bull run.