Attachments and AuthAccount capabilities preview release

[bastian]

Thank you for your feedback Jacob!

For this preview release the Cadence team is mostly looking for feedback on the implementation, i.e. if it works as expected, or if there are any problems you encounter.

Feedback regarding the features themselves are best targeted to the FLIPs, as that is where the discussion around them happens and design feedback is incorporated.

@tsnakejake

1. I have read through the AuthAccount capabilities discussion in full, and still do not see any code examples of why this would be used. From what I see, I stand by my point that although this is simply adding “sugar” (this feature is currently possible with contracts), it absolutely makes hacking into accounts easier. Without knowing why someone would want to link their AuthAccount, it’s hard to see the benefit of this. Would it be allowed to be linked to public path? Or only to private path to allow for account delegation? Lots of ideas but not sure what to think

I guess my question is: What is an example (with code) where someone would want to use this feature?

As pointed out in the FLIP for AuthAccount capabilities, the main use case is “walletless onboarding”. The Flow team just published a blog post explaining it: Overcoming barriers to mainstream Web3 adoption with walletless onboarding on Flow. As discussed in the FLIP, the feature is indeed not adding any new functionality: “child accounts” can be implemented today, the proposal is mainly just making it explicit. The proposal is not making anything possible that is not already possible today – it does not make “hacking into accounts” easier. But this concern, that nothing is proposed to make it harder, was raised in the FLIP too, and is the main reason why the community is working on/discussing such improvements, as linked above, in this topic: Super User Account.

@tsnakejake

For attachments, I love that we are exploring the ability to add more data to a type without just slapping a dictionary inside of it to be able to add more stuff in the future. However, although cool, attachments seems to overcomplicate the end goal. If we want to be able to “attach” more data to a type, why not discuss allowing contract updates to add more variables to a resource/struct?

The purpose of the attachments feature is to allow third-parties to extend existing types and values with additional functionality and data, which enables composability: Developers can build on other developers’ code, without needing the original author’s approval – users can freely choose how their data can be used/extended.

Allowing contract authors to update contracts is a related, but separate feature, and is already being discussed in this FLIP: FLIP: Cadence - Enable new fields on existing resource and struct definitions by austinkline · Pull Request #1097 · onflow/flow · GitHub.