-
Notifications
You must be signed in to change notification settings - Fork 48
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
Permissioned Accounts #594
base: sub-accounts
Are you sure you want to change the base?
Conversation
], | ||
typeArguments: [], | ||
}); | ||
case PermissionType.NFT: { |
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.
returning an array here breaks
export type RevokeNFTPermission = Pick<NFTPermission, "type" | "assetAddress">; | ||
|
||
// factories -- on second thought, i think these are dumb | ||
export function FungibleAssetPermission(args: Omit<FungibleAssetPermission, "type">): FungibleAssetPermission { |
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.
remove these?
export enum MoveVMPermissionType { | ||
FungibleAsset = "0x1::fungible_asset::WithdrawPermission", | ||
|
||
} |
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.
I think this would technically be a Capability
not a permission. Maybe we have the capability types here and for nfts be the actual move vm string so we can re-use them? Need to think on that a moment.
export interface GenericPermission { | ||
type: Exclude<string, PermissionType | `${PermissionType}`>; | ||
[key: string]: string | Exclude<string, PermissionType | `${PermissionType}`>; | ||
} |
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.
Placeholder: Is this needed?
export function GenericPermission(args: GenericPermission): GenericPermission { | ||
return {...args} | ||
} |
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.
Maybe move to the test file then.
src/internal/permissions.ts
Outdated
export interface PermissionTemp{ | ||
asset: string; | ||
type: string; | ||
remaining: string; | ||
} |
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.
Remove?
// factories -- on second thought, i think these are dumb | ||
export function FungibleAssetPermission(args: Omit<FungibleAssetPermission, "type">): FungibleAssetPermission { | ||
return { type: PermissionType.FungibleAsset, ...args }; | ||
} | ||
export function GasPermission(args: Omit<GasPermission, "type">): GasPermission { | ||
return { type: PermissionType.Gas, ...args }; | ||
} | ||
export function NFTPermission(args: Omit<NFTPermission, "type">): NFTPermission { | ||
return { type: PermissionType.NFT, ...args }; | ||
} | ||
export function NFTCollectionPermission(args: Omit<NFTCollectionPermission, "type">): NFTCollectionPermission { | ||
return { type: PermissionType.NFTCollection, ...args }; | ||
} | ||
|
||
// revoke factories | ||
export function RevokeFungibleAssetPermission(args: Omit<RevokeFungibleAssetPermission, "type">): RevokeFungibleAssetPermission { | ||
return { type: PermissionType.FungibleAsset, ...args }; | ||
} | ||
export function RevokeNFTPermission(args: Omit<RevokeNFTPermission, "type">): RevokeNFTPermission { | ||
return { type: PermissionType.NFT, ...args }; | ||
} |
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.
The main draw here is improved type inference. To get a feel for how it would work without the factories, try consuming requestPermissions
without using factories. You open a new object and are left without guidance on what the first step is. A brand new consumer of the API might not find it readily apparent that all the properties are defined based on what type
is specified.
Might be good to brainstorm other possible DX around this.
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.
should factories be moved to api file?
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.
but good point actually
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.
Since they share the same name as the interface, I think having them both be here is fine.
// txn.push(builder.add_batched_calls({ | ||
// function: "0x1::object::grant_permission", | ||
// functionArguments: [ | ||
// BatchArgument.new_signer(0), |
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.
bruh
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.
I think the types are getting messed up here due to GenericPermission
. The type
field of GenericPermission
is string
which also matches at the type level.
aptosConfig: AptosConfig; | ||
primaryAccount: SingleKeyAccount; | ||
subAccount: AbstractedEd25519Account; | ||
permissions: RevokePermission[]; |
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.
Without putting any thought into this, something feels off here. Need to dig a little.
const { aptosConfig, primaryAccount, subAccount, permissions } = args; | ||
|
||
const aptos = new Aptos(aptosConfig); | ||
const transaction = await aptos.transaction.build.batched_intents({ |
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.
We need to change this to be the public key as well.
primaryAccount: SingleKeyAccount; | ||
subAccount: AbstractedEd25519Account; | ||
}) { | ||
const aptos = new Aptos(aptosConfig); |
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.
And here.
|
||
} | ||
|
||
export interface FungibleAssetPermission { | ||
type: PermissionType.FungibleAsset; | ||
asset: string; |
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.
Let's discuss about the two types of fungible permissions (primary store vs fixed amount)
Description
big thanks to @kaw2k for the help + stubs
Best Practice Questions:
Currently types are living under
internal/Permissions.ts
, should they be moved toapi/...ts
?Should we remove the factories for each permissions or keep both types and factories?
Points of Interest:
grantPermission
:Architecture Changes @kaw2k:
Permission Types:
FungibleAssetPermission
Gas Permission
NFT Permission
NFT Collection Permission
Core Features:
Request Permission
FungibleAsset
✅NFT
🟠mutate
❌Gas
❌NFTCollection
❌Revoke Permission
FungibleAsset
✅NFT
✅Gas
❌NFTCollection
❌View Permission
FungibleAsset
✅NFT
🟠-
mutate
❌-
transfer
✅Gas
❌NFTCollection
❌TODO:
Test Plan
Related Links
Checklist
pnpm fmt
?CHANGELOG.md
?