The Cadence team is excited to share a first preview release of two new features:
Attachments. This feature has been accepted as a FLIP. The Cadence team hopes to
release it in the next Flow spork and is looking for feedback on the
current implementation. Please report bugs if you encounter them!
Note that this preview release does not imply the features will be released in production – the Cadence team is working with the wider community to address the feedback received so far and will make the decision aligned with community consensus. To learn more about potential changes discussed the the AuthAccount capabilities feature see this forum post: http://forum.flow.com/t/super-user-account/4088
Preview release installation
You can install this CLI preview release using the following update command:
sh -ci "$(curl -fsSL https://raw.githubusercontent.com/onflow/flow-cli/master/install.sh)" -- v0.45.1-cadence-attachments-3
Please start evaluating the features using this preview release. The Cadence team is eager to receive your feedback!
Hi! Thank you bastian for all the work you’ve put in to these updates
Few comments from me:
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?
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?
Thanks again, and hope my feedback is somewhat helpful
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.
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.
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.
What access is required to attach or remove an attachment from a resource?
Also, is there a way to restrict removal even from the owner of the resource. If you think of an NFT where you “drink a potion” to transform the NFT and do so with an attachment, can the attachment contract prevent users from later removing the attachment?
Only the owner of a resource (i.e. the person who has the actual resource value as opposed to a reference to it) is able to add or remove attachments from it. Anybody who possesses a reference (with the proper type) can access the attachments on a resource however.
Also, is there a way to restrict removal even from the owner of the resource.
This was a feature that was discussed but was not included in the initial release of the attachments feature. If there’s a compelling use case for restricting removal we can consider adding it though.
Attachments are now available on Testnet. There is still a design blocker for releasing it to Mainnet which we are working on to resolve. We hope to release it to Mainnet latest with the Stable Cadence release.
