SIP-29 Improvements

[GuillaumeRx]

This PR tries to add a permission and handlers definition to the SIP-29 (#154). It also propose to use asset rather than the token denomination.

[danroc]

I wasn't sure whether to use asset or token in the method names, as asset is more generic and could include NFTs, for instance, where the details payload would differ significantly from that of tokens.

[GuillaumeRx]

I wasn't sure whether to use asset or token in the method names, as asset is more generic and could include NFTs, for instance, where the details payload would differ significantly from that of tokens.

I wonder if this API couldn't be versatile enough that we could add the support for NFT down the road rather than having multiple endpoints. It should just be a return type change

[FrederikBolding]

I wasn't sure whether to use asset or token in the method names, as asset is more generic and could include NFTs, for instance, where the details payload would differ significantly from that of tokens.

I wonder if this API couldn't be versatile enough that we could add the support for NFT down the road rather than having multiple endpoints. It should just be a type change

I would strongly prefer this as well.

[FrederikBolding]

I'm guessing this will be covered in another doc, but I'm curious how data is added to this list provided by the caller. How are assets discovered originally?

[GuillaumeRx]

This is covered by the kering API with the listAccountAssets method IIRC @danroc can provide more details about it

[GuillaumeRx]

Then the snap uses any API that provides asset metadata to create its token description

[danroc]

Should we allow namespaces as well? And we should probably name it scopes to be aligned with SIP-26, CAIP-25/27.

[GuillaumeRx]

What's your thinking for allowing namespaces ? I would prefer this to be granular and to have to define reference supported rather than defining namespaces that would probably introduce calls for reference that are not supported

[danroc]

I wasn't sure whether to use asset or token in the method names, as asset is more generic and could include NFTs, for instance, where the details payload would differ significantly from that of tokens.

I wonder if this API couldn't be versatile enough that we could add the support for NFT down the road rather than having multiple endpoints. It should just be a type change

I would strongly prefer this as well.

Me too :)

What we did in the listAccountTransactions was to create a tagged union ({fungible: true; ... } | {fungible: false; ... }), maybe we should apply the same pattern here, since fungible and non-fungible assets have very distinct properties.