-
Notifications
You must be signed in to change notification settings - Fork 61
feat(examples): cherry pick AA examples from alpha #9593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: vm-lang/aa-auth/8805-beta-feature-branch
Are you sure you want to change the base?
feat(examples): cherry pick AA examples from alpha #9593
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 6 Skipped Deployments
|
f5588d1 to
08e1ee9
Compare
| members_addresses: vector<address>, | ||
| members_weights: vector<u64>, | ||
| threshold: u64, | ||
| authenticator: AuthenticatorInfoV1<DynamicMultisigAccount>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have to pass the packageMetadata instead of authenticator directly?
(Also related to example below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It shouldn't be a part of this PR; technically, it is not necessary because it is possible to create an AuthenticatorInfoV1 instance in a dedicated MoveCall in a PTB.
We can consider adding this in the following PR related to the examples. We need to discuss this and determine what the examples should look like before making any changes to them(not to waste time and not to create more mess than we already have).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think it'd be better to keep it "simpler", but yes we could consider adding it later on.
Dkwcs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, left one comment.
theiari
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, replied to that question on dynamic_multisig_account::create function
Description of change
All the examples in this PR are fixed and ready to be merged.
There are a couple of approaches that were used when the examples were created:
Stand-alone accounts. A package contains the account struct itself as well as the related authentication logic.IOTAccount. An example where an account is implemented to be extended with data and the related authentication logic from 3rd-party packages. This example is not finished yet; it requires security rules to be implemented to control access to the internal state.Extension packages. Packages where data(a public key, etc.) and the related authenticator logic are implemented in a dedicated module; It makes it possible to reuse such utilities when a new account type is implemented.We need to define an approach(es) that we want to demonstrate to users and categorize the examples in a separate pull request.