diff --git a/meetings/2022-07-22.md b/meetings/2022-07-22.md deleted file mode 100644 index 85e76f7dd2..0000000000 --- a/meetings/2022-07-22.md +++ /dev/null @@ -1,106 +0,0 @@ - -# July 22, 2022 - -## External Mutability - -- FLIP that prevents external mutation was approved, implemented, and released in Secure Cadence: - [/~https://github.com/onflow/flow/pull/703](/~https://github.com/onflow/flow/pull/703) -- Open problems: - - Composites were not covered by the FLIP, only arrays and dictionaries - - Externally taking a reference to a field can circumvent the external mutability restriction -- New FLIP: [/~https://github.com/onflow/flow/pull/1056](/~https://github.com/onflow/flow/pull/1056) - - Purity/mutability modifier for functions - - Automatic analysis to determine if function has side-effects - -## Condition can currently have side effects -- /~https://github.com/onflow/cadence/issues/1805 -- Might be used for underhanded code: Post-condition might perform mutation. Example: FT withdrawal -- Might be solved by purity FLIP -- Can a pure function emit events? - - Does affect on-chain state, but is not observable -- Are other side-effecting functons like debugging logging allowed? -- "Pure" vs "no side-effects" - - "Pure" usually means no side-effects at all - - Have to be pragmatic -- Alternatives: - - Prevent calls in general - - Run-time errors if there are side-effects - -## Remove deprecated key API -- We currently have two key management APIs: - - `AuthAccount.addPublicKey`/`AuthAccount.removePublicKey`: - - Low-level, accepts encoded key as byte array - - Deprecated a year ago - - [`AuthAccount.keys.add`](https://docs.onflow.org/cadence/language/accounts/#add-account-keys)/`AuthAccount.keys.remove` - - High-level, accepts key as object (`PublicKey`) - - Added a year ago -- We attempted to remove the deprecated in the Secure Cadence release - - Rolled back, as it will break client applications if they use SDK which uses deprecated API -- Also: Events that are emitted when a key is added is inconsistent, depends on which API is used: /~https://github.com/onflow/cadence/issues/1796 -- Do we have metrics on how many SDKs are still using the deprecated API? -- Actionables: - - Add deprecation annotation to developer tooling - - Pragma, e.g. `#deprecated` - - Comment, e.g. `@deprecated` - - Add support in VS Code, render as ~~addPublicKey~~ - -## Interface default methods -- /~https://github.com/onflow/cadence/pull/1076 -- Proposed for NFT metadata standard -- Helps with preventing breakage in ecosystem -- Avoid copy/paste and boilerplate, making code reusable -- Does not help with FT/NFT rewrite proposal -- Useful for utility/convenience functions, reducing boilerplate -- Open Questions: - - Security implications? - - Related: - - Post-conditions with side-effects - - Mutability - - Restrict to pure functions? Potentially too restrictive, e.g. couldn’t provide - - Maybe allow opt out of mutating functions. But could also be used to opt-out of a fix - - Examples? - - Trust relationship problem - - Already have this problem with contract updates - - Modification of default implementation - - Would be useful to provide utility functions, like FT transfer - - It should not be possible to perform malicious code, as the same could be done in a non-default function -- Not a breaking change, could merge and ship before Stable Cadence -- When there is a conflict, e.g multiple interfaces provide default implementation: - - No "winner" is selected by default - - Instead, the user is required to provide an implementation -- Follow up feature: Interface requirements - - Declaration site: `CI1: CI2` - - Use-site would still have to explicitly declare conformance for all interfaces: `C: CI1, CI2` - -## Storage Querying/Iteration API -- /~https://github.com/onflow/cadence/issues/208 -- Finally added technical foundation a couple months ago: - Account storage data is now stored in [atree](/~https://github.com/onflow/atree) values - (atree is Cadence's storage layer) -- Issue lays out proposal for adding API to iterate over account paths/values -- Outstanding issues: - - Accounts may store a lot of data. Pagination iteration? Iterator, cursor, enumerator - - Concrete API proposal -- First use-case: Developer tools like the Emulator and Playground -- Need to show wallet developers how they can render information to users -- Mutability not necessarily a problem: Run script against block. - - Problem: data availability - - Might be solved in future by "historic" data node -- Storage Layer: - - Iteration over dictionary changes when mutated - - Keys are hashed -- Start with MVP -- Stages: - - 1. Even useful if pagination problem is not solved yet - - 2. Pagination for larger accounts - - 3. Support for handling mutation -- Also useful for e.g. dictionary, keys. Might be too large - - Keys on demand - - E.g. useful to pick a random key - -## Organisational - -- Should we move this meeting so it is not on a Friday evening for folks in Europe? - - Not Friday, not Monday - - Tuesday is best - - Same time (8am PT) diff --git a/meetings/2022-08-30.md b/meetings/2022-08-30.md deleted file mode 100644 index 1a4f9e22e2..0000000000 --- a/meetings/2022-08-30.md +++ /dev/null @@ -1,93 +0,0 @@ -# August 30, 2022 - -* We discussed the currently open FLIPs - -* **Remove public resource fields:** - * /~https://github.com/onflow/flow/pull/739 - * Status: - - No consensus - * Open problems: - - None - * Next steps: - - Ask author (Dete) - -* **Capability Controllers:** - * /~https://github.com/onflow/flow/pull/798 - * Status: - * More API discussions (delegation, revocation) - * Exploring how to make APIs/use-casess simpler to use/understand - * Sentiment: proposal OK, but also want to cover more use-cases - * Maybe split proposal? At least gather use-cases, maybe propose functionality in separate FLIP(s) - * Next steps: - * Meeting - * Finish use-case gathering - * Open problems: - * Should capabilities be resources? Agreement they should be values - * Relation to extensibility proposal → some use-cases could be covered by extensibility ([FLIP 1101](/~https://github.com/onflow/flow/pull/1101)) - * It would be great to have account identity (-> [FLIP 945](/~https://github.com/onflow/flow/pull/945)), do not have to be storable, only needs to prove - * Cons: tied to identity, not transferable between accounts owned by same person - * Alternative (?): wrapping/unwrapping (pattern instead of new language feature) - * Alternative (?): sharing using account - -* **Add identity to AuthAccount:** - * /~https://github.com/onflow/flow/pull/945 - * Status: - * Maybe not needed if capability controllers proposal gets added (?) - * Missing use-case / documentation - * Many cons, alternatives exist → need to be added to FLIP - * Next steps: - * Add cons to proposal - * Extend article with why identity resource is not a good alternative - * Promote safe patterns for identity/access control - * Open problems: - * "Too easy" to use instead of capabilities introduces a footgun. -But: just another tool for access control, useful for certain use-cases, still recommend capabilities - * Possible to pass on identity, potentially a malicious program pretends it has access - * But also *not* providing identity will cause developers to create their own potential unsafe. Cannot prevent it - * Alternative: instead of passing identity around, code wraps value for target, target has secret unwrapper - -* **Purity/mutability analysis:** - * /~https://github.com/onflow/flow/pull/1056 - * Status: - * Simplified original proposal - * Consensus - * Next steps: - * Merge PRs into feature branch, let people try it out - * Make decision on FLIP - * Notes: - * `pure` was changed to `view`, like in Solidity - * Open problems: - * None - -* **Extensibility:** - * /~https://github.com/onflow/flow/pull/1101 - * Status: - * Many open problems - * Unclear definition of problem - * Next steps: - * Meeting - * Clearly defining use-case / features - * Open problems: - * Current proposal has many open questions / edge cases - * Unclear what features should be provided by proposal - -* **Add fields during contract update:** - * /~https://github.com/onflow/flow/pull/1097 - * Status: - * Good start - * Need to answer outstanding questions - * Overall agreement, probably gets approved/implemented once details figured out - * Next steps: - * Meeting - * Open problems: - * Migration - * Field removal - * Syntax - -* **Invalidate references to transferred resources:** - * /~https://github.com/onflow/flow/pull/1043 - * Status: - * Paused discussion on this, hoped to have [FLIP 1056](/~https://github.com/onflow/flow/pull/1056) solve this - * Need to increase priority - * Open problems: - * ? diff --git a/meetings/2022-09-13.md b/meetings/2022-09-13.md deleted file mode 100644 index 6eb70b6fc4..0000000000 --- a/meetings/2022-09-13.md +++ /dev/null @@ -1,214 +0,0 @@ - -# Sept 13, 2022 - -## FLIPs - -* **Capability Controllers:** - * [/~https://github.com/onflow/flow/pull/798](/~https://github.com/onflow/flow/pull/798) - * Status: Scoping - * Open problems: - * What parts should be part of this FLIP? - * What should rather go in follow-up proposal(s)? - * How to provide better and easier to understand API? - * Next steps: - * At least define replacement for current API - * Solve bootstrapping problem in separate FLIP - * Meeting - -* **Add identity to AuthAccount:** - * [/~https://github.com/onflow/flow/pull/945](/~https://github.com/onflow/flow/pull/945) - * Status: Closed, replaced by capability publish/claim FLIP 1122 - -* **Publish and Claim Capabilities** - * [/~https://github.com/onflow/flow/pull/1122](/~https://github.com/onflow/flow/pull/1122) - * Purpose: Capability bootstrapping. Replacement for FLIP 945 - * Status: New, just published - * Open problems: - * Only for capabilities or anything? - * Off-chain or on-chain inspection? - * Next steps: Clarify/resolve open problems - -* **Extensibility**(see below) - * [/~https://github.com/onflow/flow/pull/1101](/~https://github.com/onflow/flow/pull/1101) - * Status: Impass, unclear scope/direction - * Open problems: - * Two different proposals with different pros/cons -(boxing/wrapping vs containment) - * Next steps: - * Meeting - -* **Add fields during contract update:** - * [/~https://github.com/onflow/flow/pull/1097](/~https://github.com/onflow/flow/pull/1097) - * Status: No update - * Open problems: - * Implementation details for migration (not impossible, just needs to be laid out) - * Next steps: - * Meeting - -* **Invalidate references to transferred resources:** - * [/~https://github.com/onflow/flow/pull/1043](/~https://github.com/onflow/flow/pull/1043) - * Status: - * Agreement for need - * Prototype implementation in progress - * Open problems: - * Concerns - * Next steps: - * Complete prototype - * Analyze impact - -* **Borrow Contract** - * [/~https://github.com/onflow/flow/pull/1071](/~https://github.com/onflow/flow/pull/1071) - * Status: - * Complete - * Needs minor edits - * Reference implementation in progress - * Open problems: - * Concern that static analysis is not possible anymore resolved: - * Already have run-time imports of contracts - * Concern for program cache invalidation: - * Implementation detail, not a concern, functionality basically already available - * Next steps: - * Needs approval/rejection - -* **Remove public resource fields:** - * [/~https://github.com/onflow/flow/pull/739](/~https://github.com/onflow/flow/pull/739) - * Status: No progress - * Open problems: None - * Next steps: Dete - -* **Purity/mutability analysis:** - * [/~https://github.com/onflow/flow/pull/1056](/~https://github.com/onflow/flow/pull/1056) - * Status: Accepted 🎉 - -## Extensions - -* [/~https://github.com/onflow/cadence/issues/357](/~https://github.com/onflow/cadence/issues/357) -* Context - * Long-requested feature: Add functionality and data to existing types, after the fact, without work from author of type. Controlled by user - * Prior community effort: [https://forum.onflow.org/t/extensibility/622](https://forum.onflow.org/t/extensibility/622) -* Open Questions: - * What are the use-cases that should be covered? - * Do we need to add support for extending fields? - * This significantly complicates extensions by requiring them to define new (or partial) initializers for their new data - * How limiting would it be to restrict extensions to be used only one at a time? - * Otherwise we need to consider how to handle extensions with overlapping data/methods. In other languages this is simple but in Cadence two extensions that define the same type but use it differently would be a security issue - * How can the same type interact with differently extended versions of itself? Can a CryptoKitty with a hat be used in places where only a CryptoKitty is expected? Can a CryptoKitty with a hat and a scarf be used as if it only had a scarf? - -## Account Storage Delta (hash) - -* [/~https://github.com/onflow/cadence/issues/1777](/~https://github.com/onflow/cadence/issues/1777) - -* Determine change on-chain was as expected - -* Accessible on-chain - -* Dry run: run transaction as script, get hash - -* Run transaction, ensure hash in post-condition - -* Related to iteration: detect invalidation due to mutation - -* Hash should be cheap, needs to be cheaper than comparison - -* Feedback: - - * Storage changes are not immediately effective, serialization is lazy -(end of transaction) - - * But: storageUsed materializes cache - - * Potential problem: more modifications after transaction end - - * Hash of what? Full account? All accounts? Just part of an account’s storage? - - * Can we use state proofs? - -* Next steps: - - * Ping FVM team - - * Atree/State trie additions? Ask Ramtin, Faye - - * Keep discussion in Github issue, determine details - - * → propose FLIP once clear how to implement - -## Prevent re-entrancy attacks - -* [/~https://github.com/onflow/cadence/issues/1543](/~https://github.com/onflow/cadence/issues/1543) - -* Large topic, low priority relative to other issues - -* Many different options - * Explicit vs implicit - * Granularity: whole type vs individual fields - * Static vs dynamic guarantees - -* Problems: - * Learning curve - * Ideally no-brainer or very easy to use - -* Ideas: - * Rust/Ocaml ref-cells - * Make cross-contract calls promises / asynchronous - * Async prepares for sharding in future - * Examples: Swift’s new actor system, Agoric, etc. - * JS developers still try to understand promises - * Does not handle all cases - * Implicit / hidden - -## Extend character set of identifier part in paths - -* [/~https://github.com/onflow/cadence/issues/419](/~https://github.com/onflow/cadence/issues/419) -* Allowing dots is parsing problems (conflict with field access) - -## Alternative to paths: Resolver functions - -* Not addressing by path, but by type (used to have this early on) -* What if multiple elements for one type? Array? Identifier? -* Resolver function for a type/name pair. E.g. FT + "default" -* For / instead of public domain -* Relation to capability controllers: - * Gets rid of private paths, not paths in general - * Could make use of this feature - -* Next steps: - * What use-cases/problems does this solve? - * Comparison to existing system - * Pros/cons - -## Initialization problem - -* Context - * How to ensure proper setup? e.g. linking, initialization of storage - * Lost+Found - -* Problem: - * Have bits and pieces - * No concrete full solution - -* Related: - * New FT + NFT standards have built-in info, collection data metadata - * Specific to FT/NFT, not a general solution - * Assumes collection is already stored - * "Transaction/interaction templates" proposal - * Setup (e.g. FT vault) + interactions (e.g. FT transfer) - -* Cadence-specific ideas: - * Scoped access to storage (e.g. by path) - * Related to granular capabilities for AuthAccount - -* Next steps: - * Create issue, not a FLIP yet - -## Error messages of assert/pre/post are eagerly evaulated - -* [/~https://github.com/onflow/cadence/issues/1838](/~https://github.com/onflow/cadence/issues/1838) - -* Should go into Stable Cadence - -* Encourage error messages - -* Workaround create custom wrapper: -assert(true, message: lazyMessage: ((): String)?) - diff --git a/meetings/2022-09-20-Extensions.md b/meetings/2022-09-20-Extensions.md deleted file mode 100644 index 9e3fed4df9..0000000000 --- a/meetings/2022-09-20-Extensions.md +++ /dev/null @@ -1,57 +0,0 @@ -# Extensions Meeting Notes - -FLIP: /~https://github.com/onflow/flow/pull/1101 - -## Two Paradigms -### Statically Checked -* Multiple different people could have the same extensions that do the same thing -* What if someone deletes the contract defining an extension? -### Dynamically Enforced -* Extensions would function like a “sub-resource”, method lookup would first happen on the extension, then fall back to the parent - - -# Discussion -* Microplatforms that can be extended - * Allow people to add features/functionality to their code without changing it, as this is the primary paradigm of smart contract development - * Better for composability - * People who add functionality should not be able to break the rules originally encoded into the base object - * This paradigm benefits from thinking about extensions as an attachment rather than a wrapper; this is independent of whether or not we have a static representation - * Owner of the resource **must** have control over what extensions are attached to the resource - -* Are these two proposals even that different? - * Static version may be the same as the dynamic version just with added static typing -* Should it be possible to override the behavior of the base resource? - * Potential to be dangerous, but also potential to be very powerful - * E.g. Vault that does automatic currency conversion - * This could also be done by just creating a different type that wraps a Vault (e.g. implementing Provider and Receiver), rather than extending the Vault type - * Assumption up to this point has been: extension can add new functionality but cannot change any old functionality - * Extended version of a type is no longer an instance of the old type, which makes overriding the old type safe - * Explicit casting -* Metadata - * Metadata should reflect the extensions that are present on the type, rather than only showing the base resource -* Extension adds method that is later added by the base resource - * What happens here? - * In static model, the extension’s method would need to be removed - * Could also require users to be explicit about which type (base or extension) they wish to use the method from (static dispatch) - * Type.foo(instance) - * Cadence’s flavor is more Pythonic than this very C++/Rust solution? Syntax is fundamentally different to what Cadence currently uses - * Could also have the composed version default to the extension’s method and must be casted to the base type to use the base type’s method - * Including the self pointer inside the definition of the extension itself - * Or super keyword for extensions to refer to its base type -* Benefit of extensions over a purely compositional model is extensions have information about what base type an extension is attached to (e.g. via a self pointer) -* Signature extensions should not be removable and attachable to another resource - * But it would make sense for a hat to be removable and given to another kitty - * Need to allow extensions to decide whether they can be transferable or not -* Having extensions be their own resources/NFTs that can be traded is a nice feature if it’s easy, but is not necessary - * Extension could just be a manager for a resource type, rather than the extension being the resource itself -* Object and its extensions should be independent types that can define conflicting methods - * E.g. metadata case - * Need some method to go from extension to base and vice versa - * While you have the extension, you only have access to those methods, and while you have the base you only have access to its methods - * Extension has a reference to its parent? - * Like trait objects in Rust -* Is this still extensions? Current proposal feels more like “attachments” rather than an extension of the base type -* Not the same as a dictionary of owned resources on the parent type - * Must have a backpointer from attachment to parent - * Use cases where the attachment should not be transferable - * For transferable cases, the attachment can be a manager that handles the resources, rather than the resource itself diff --git a/meetings/2022-09-26 Capabilities.md b/meetings/2022-09-26 Capabilities.md deleted file mode 100644 index 1babde82b0..0000000000 --- a/meetings/2022-09-26 Capabilities.md +++ /dev/null @@ -1,151 +0,0 @@ - -# Capabilities Meeting Notes - -## Capability bootstrapping proposal - -* FLIP: /~https://github.com/onflow/flow/pull/1122 - -* Publishing capabilities - -* Last problem: Spam - - * Off-chain or on-chain (events, iteration API) - - * Quantity - - * Message could be harassment - - * Ideas: - - * Maybe no default/built-in/system event, but a custom event? - - * Not concern of protocol, but level above: - - * Allow/Ignore-list in user agent (e.g wallet software) - - * User agent could default to everything, but have harassment/filtering feature - - * Events are for making systems aware of on-chain state changes - - * Warning in documentation: - - * Events should not be presented as-is to user - - * Having no events will result in user agents to repeatedly pull - - * Block explorer shows everything (today; could be extended, just like a user agent like a wallet) - - * Capabilities only? - - * Arbitrary publishing will result in avoiding capabilities - - * Should only be used to bridge to capabilities world - - * → design API so it can be extended to allow resources in the future in a backwards-compatible way - - * → only publish / claim / unpublish - - * Claim: - - * Event? - - * → Emit: - - * Not much harm - - * Useful in typical user agent (dashboard) - - * Need for reacting stays - - * Don’t emit: - - * Why? - - * Removal/unpublish? - - * Don’t remove: - - * No harm in staying - - * Removing seems implicit - - * Receiver may rely on cap existing in publisher - - * → Remove: - - * Optimize for standard case - - * No need to constantly clean up - - * Mailbox analogy: someone shows up and claims → gone, no further action required by publisher - - * Forces receiver to "move" the capability to their account - - * → Need good documentation with examples - - * E.g. Claim cap, get resource, store resource, throw away cap - - * Related: event API needs filtering and pagination - - * Concern: Capabilities can be copied - -## Capability Controllers - -* FLIP: /~https://github.com/onflow/flow/pull/798 - -* Revocation problem example (admin interface) - -* Capability creation only in publisher’s account? - -* Admins should be able to undo, even each others’ decisions - -* Not a problem of the language / API (should make it possible, something else can make it easier); capabilities API should be as simple (basic?) as possible - -* Problems can mostly be solved with (better) attenuation - -* Need delegation without changing type - -* Attenuation allows custom code → security issues? - -* Use cases for both concrete type and interface - -* Tags? - -* Mapping of names to IDs in contract? - -* Use own name for capability. Does it require re-lookup based on ID? - -* Keep reference count? - -* Remove retarget? - - * Security issue: retarget after check - - * Can only retarget to same type - - * Safety footgun - - * Problematic in two-step process - - * But always a problem - - * Examples: - - * Caps on interfaces, don’t care about concrete type, care about functionality - - * Concrete vault vs e.g pooling/split abstraction - -* Remove restore? - -* Struct, but non-storable - -* Don’t return status flags. Either idempotent or panic - -* → Attenuation out of scope - -* → Example for delegation - -* → Example for cap petnames - -* → Default function petname should be default → easy to add later, move ahead without - diff --git a/meetings/2022-09-27.md b/meetings/2022-09-27.md deleted file mode 100644 index 3cd8d2c2f4..0000000000 --- a/meetings/2022-09-27.md +++ /dev/null @@ -1,118 +0,0 @@ -# Sept 27, 2022 - -## FLIPs - -* **Capability Controllers:** - * /~https://github.com/onflow/flow/pull/798 - * Status: had meeting; scope clear, API design - * Open problems: - * None, mainly just API design - * Next steps: - * Move forward with API details - -* **Publish and Claim Capabilities** - * /~https://github.com/onflow/flow/pull/1122 - * Status: meeting resolved outstanding questions - * Open problems: - * None for FLIP, but related: might need improve event API - * Next steps: - * Have a final look - -* **Extensibility** - * /~https://github.com/onflow/flow/pull/1101 - * Status: Had meeting, still unclear what approach is best - * Open problems: - * Problem with extensions approach: changes in extension and extended type break code - * Use case: metadata - * Alternative: attachment-style proposal; requires iteration - * Next steps: - * Alternative FLIP for attachments - * Compare with existing extensions FLIP - * Pick one or find compromise - -* **Add fields during contract update** - * /~https://github.com/onflow/flow/pull/1097 - * Status: No update - * Open problems: - * Implementation details for migration (not impossible, just needs to be laid out) - * Next steps: - * Call? - -* **Invalidate references to transferred resources:** - * /~https://github.com/onflow/flow/pull/1043 - * Status: - * Agreement for need - * Prototype implementation: /~https://github.com/onflow/cadence/pull/1999 - * Agreement that any transfer (even stack-to-stack) invalidates - * Open problems: - * /~https://github.com/onflow/flow/pull/1043#issuecomment-1258742270 - * Maybe use stack depth check? - * Next steps: - * Analyze impact: analysis pass (also useful for breaking change analysis; hard to check) - * Note: this is about ephemeral references (lifetime of a transaction/script), not capabilities - -* **Borrow Contract** - * /~https://github.com/onflow/flow/pull/1071 - * Status: - * Complete - * Needs minor edits - * Have reference implementation: /~https://github.com/onflow/cadence/pull/1934 - * Open problems: - * Concern that static analysis is not possible anymore resolved, already have run-time imports of contracts - * Concern for cache invalidation - implementation detail, not a concern, functionality basically already available - * Next steps: - * Needs approval/rejection - -## Contract removal -* Was available until Secure Cadence release -* Problem: Removal + addition allows circumventing updatability checks - * E.g. change field type, change type kind, etc. -* Currently disabled, as it is unclear how to implement this safely -* Options: - * Don't have removal - * Revocation / tombstoning - * Keep old contract information and treat addition as update -* Unavailability of removal - * Hinders development of utility contracts - * Unable to clean up account storage -* Removal of contracts/types might leads to breakage -* Removal useful for "temporary" types, e.g. for capability attenuation - * Idea: Marking contracts as "public"/"internal"/"beta", cannot be shared/stored/etc -* It would be nice to have and expose instance count for types, allow removal if no instances - -## Scoped AuthAccounts / Account initialization -* /~https://github.com/onflow/flow/issues/1131 -* Solve the account initialization problem -* E.g. marketplace needs to know how to prepare user account -* Responsibility of initialization should be on dapp, not user agent - * However, power user might want to control where e.g. collection is stored, might have multiple - * Normally user does not care, wants "default". Still, user agent (wallet software) should take care, not contract -* Actors: user, asset creator, application developer - * Asset creator and application developer often tied together - * However, application developer might not be asset creator (e.g. marketplace) -* User should be in control, not asset creator or application developer. Might use user agent. Asset creator might propose requirements so it can function -* Analogy: User data vs system files (Installer asks where program should be installed) -* Scoped AuthAccount is basically attenuated AuthAccount -* Related (alternatives?): - * Bjarte's FLIP: /~https://github.com/onflow/flow/pull/748 - * Transaction interaction templates - * NFT catalog - * Return initialization information - * NFT Metadata: [/~https://github.com/onflow/flow-nft/blob/9877dccbd884e06bbd754a4f693b7169dd6dd62b/contracts/MetadataViews.cdc#L480-L537](/~https://github.com/onflow/flow-nft/blob/9877dccbd884e06bbd754a4f693b7169dd6dd62b/contracts/MetadataViews.cdc#L480-L537) - * New NFT feature: [/~https://github.com/onflow/flow-nft/pull/126#discussion_r981328645](/~https://github.com/onflow/flow-nft/pull/126#discussion_r981328645) - * Declaration in prepare block (?) - * Pass box which captures initialization - * Enforce limitation in type system (e.g. AuthAccount restricted to just storage, only certain path, only write, etc.) -* Approach axes: - * Limiting vs checking after the fact - * Imperative vs declarative -* Next steps: - * Agreement on responsibility, formalize - * Find solution that aligns - * Meeting with people involved with existing solutions - * Who? Dete, Austin (after 7th), Bjarte (other FLIP), Amit (NFT catalog, NFT Collection Metadata), Jeff (interaction templates) -* Additional discussion points from Amit: - * Fixing existing account links that have it wrong (and gracefully with an account that has it wrong). Currently its unlink -> link - * [Metadata views] aren't very useful on-chain because you have to make custom templated transactions regardless in order to make these links because we lack a way to link at runtime (see /~https://github.com/onflow/cadence/issues/1617) - * Having a way to allow a contract owner to be more prescriptive about what setup should be done (maybe past a single public link like the view provides). - diff --git a/meetings/2022-10-11.md b/meetings/2022-10-11.md deleted file mode 100644 index 278cb1e919..0000000000 --- a/meetings/2022-10-11.md +++ /dev/null @@ -1,170 +0,0 @@ -# Oct 11, 2022 - -## FLIPs - -### Capability Controllers - -* [/~https://github.com/onflow/flow/pull/798](/~https://github.com/onflow/flow/pull/798) -* Status: - * Ready for approval - * Hardest problem was bootstrapping, solved by publish/claim - * Want to potentially explore backward compatibility -* Open problems: - * Could emulate proposal / or existing API - * How to have both at the same time -* Next steps: - * Determine backward compatibility - * Other than that, ready to move to decision, mostly agreement - * Could maybe consider adjust proposal to allow for backward-compatibility - -### Extensibility - -* [/~https://github.com/onflow/flow/pull/1101](/~https://github.com/onflow/flow/pull/1101) -* [https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2](https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2) -* Status: - * Alternatively: [Attachments FLIP](/~https://github.com/onflow/flips/pull/11) - * FLIP discussions now in forum: [https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645](https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645) - * More dynamic, little static typing - * Benefits: - * Not prone to breakage on contract updates - * Disadvantages: - * Less ergonomic, less powerful -* Open problems: - * None (?) in both -* Next steps: - * Review/compare two FLIPs, make decisions on what matters - * Both doable, static slightly more work - * Most important is UX/use-cases for developers - * Attachments proposal matches more closely use-cases (?) - * Static guarantees / implicitness better - * Extensions proposal provides more static guarantees - * Extension can statically state requirements (type) - * Often more, dynamic requirements - * Can restrict which code can create instances - * Usually instantiation is unrestricted, it’s acceptance which is limited - * Openness VS security foot-gun - * Prefer openness - * Extensions more powerful, but also more complex - * Attachments simpler, covers less use-cases, but more common one - -### Add fields during contract update - -* [/~https://github.com/onflow/flow/pull/1097](/~https://github.com/onflow/flow/pull/1097) -* Status: No update -* Open problems: - * Implementation details for migration (not impossible, just needs to be laid out) -* Next steps: - * Call? - -### Invalidate references to transferred resources - -* [/~https://github.com/onflow/flow/pull/1043](/~https://github.com/onflow/flow/pull/1043) -* Status: - * Ready for decision - * Implementation mostly ready ([/~https://github.com/onflow/cadence/pull/1999](/~https://github.com/onflow/cadence/pull/1999)) - * Initially only planned dynamic checks - * Also added static checks to prevent bugs/problems early - * Static checks cover most use-cases discovered during analysis of Mainnet contracts -* Open problems: - * None -* Next steps: - * Make a decision, mostly agreement - -### Borrow Contract - -* [/~https://github.com/onflow/flow/pull/1071](/~https://github.com/onflow/flow/pull/1071) -* Status: - * Complete - * Have reference implementation ([/~https://github.com/onflow/cadence/pull/1934](/~https://github.com/onflow/cadence/pull/1934)) - * Needs some assistance on e.g. tests - * FLIP is up-to-date -* Open problems: - * Concern that static analysis is not possible anymore resolved, already have run-time imports of contracts - * Concern for cache invalidation – implementation detail, not a concern, functionality basically already available -* Next steps: - * Needs approval/rejection - -### Enforcing events / nested type requirements - -* We would like to remove the nested type requirements feature from Cadence -* However, the new FT/NFT standards plan to keep using the feature for enforcing the declaration of event -* Can we find an alternative to enforcing events without using nested type requirements? - * Events as nested type requirements are mostly just boilerplate - * Concrete type "needs" separate events, cannot emit events from interface - * Definitions in concrete type are not "useful" right now, cannot enforce they are emitted in a certain way - * Maybe just "inherit" event types from interface - * Feedback: Too implicit - * Contract-level events -> requires type field - * Maybe move events to resource-level, i.e. FT/NFT itself? - * Changing events significantly will affect existing off-chain systems - * Emit event always in post-condition of interface - * Currently (potentially unnecessarily) limited by new view-functions feature (conditions are view contexts) - * Requires allowing definition of concrete events in interfaces - * Might be easier to have "universal" event types with type field, instead of separate ones - * Related: filtering on API -* If we can't remove nested type requirements, can we maybe at least reduce the feature to just events? Only using the feature for events addresses at least some of the concerns we have with the feature, and we can still simplify the codebase a bit -* Next steps: - * Write example standard and derive required language changes (Deniz and Bjarte will look into it) - -### Additional Storage API functions - -* `clear`: [/~https://github.com/onflow/cadence/pull/1253](/~https://github.com/onflow/cadence/pull/1253) - * `fun clear(_ path: Path): Bool` - * Reason: sugar/helper - * This function deletes whatever is present at the specified path, destroying any resources, and returns whether anything was present originally. - * Concerns: implicitness, destruction without destroy - * Maybe name "destroyAt" -* `forceSave`: [/~https://github.com/onflow/cadence/pull/1252](/~https://github.com/onflow/cadence/pull/1252) - * `fun forceSave(_ value: T, to path: Path): Bool` - * This will save a value to the specified path, overwriting any data present (and destroying it if it is a resource). Returns whether or not any data was overwritten - * Reason: save fails when value exists - * Concerns: destruction without destroy - * Maybe name "destroyAndSave" -* Functionality exists already -* Prefer explicitness / keyword (enforce one way) -* Main use-case: avoiding path collisions -* Related: Removal of storage paths (replace with type + name pair) -* Concern: streamlining pattern we do not want to encourage -* → Put on pause until we discussed path changes - -### Alternative to paths - -* FLIP draft: [/~https://github.com/onflow/flow/pull/1130](/~https://github.com/onflow/flow/pull/1130) -* Cap Cons: - * Remove private (no longer needed, were only used for caps) - * Public for capabilities -* Problems with paths: - * Collisions - * Most common use-case: one value per type -* Type + name pair -* Problem: - * borrow can be for interface -* Idea/goal for paths: - * User’s account is controlled by user, UA mediates - * Dapp/contracts should not dictate - * Common user just has one value (e.g. default FT vault, NFT collection) - * Power users might have multiple (e.g. multiple FT vaults, NFT collections, for different purposes. Cf. checking vs savings account) - * Not (yet) a reality today, didn’t have necessary functionality - * Efforts: - * Interaction template library: Allow UA to inject path - * New proposal does not hinder the goal (right?) - * Goal requires introspection -* Path/name choosing, mediated by UA -* Related: account initialization (call on 2022-10-18) -* Application "state" in user account VS user data stored in user account - * Analogies: - * Windows Programs directory vs documents directory - * Mac/*nix /home vs /lib -* Interoperability easier with user-managed/stored data -* Next steps: continue discussion - * How does the proposal solve the problems? - * ? - -### Publish/claim capability use-cases? - -* Bootstrapping -* Outline ideal use-case -* Existing pattern of private push-inbox, in our case pull - * Example: n email inbox where emails are pushed through the inbox and handled according to rules (rate limiting, requiring payment or anti-sybil proof)[ https://petmail.lothar.com/design.html](https://petmail.lothar.com/design.html) -* Update best practices page -* Next step: Write up, discuss (Kate) diff --git a/meetings/2022-11-02.md b/meetings/2022-11-02.md deleted file mode 100644 index 342daba752..0000000000 --- a/meetings/2022-11-02.md +++ /dev/null @@ -1,227 +0,0 @@ -# Nov 2, 2022 - -## **Mainnet spork / Cadence release** - -We've achieved another big milestone! 🎉 - -https://forum.onflow.org/t/cadence-updates-for-the-nov-2022-mainnet-spork/3748 - -## FLIPs - -### Invalidate references to transferred resources - -* /~https://github.com/onflow/flow/pull/1043 -* Status: Accepted 🎉 - -### Capability Controllers - -* /~https://github.com/onflow/flow/pull/798 - -* Status: - * Figured out how to add API in backward-compatible way. - * Will allow deprecation instead of replacement - -* Open problems: - * None - -* Next steps: - * Vote! - -### Attachments - -* /~https://github.com/onflow/flips/pull/11 - -* Forum discussion: https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2 - -* Status: - * No feedback if extensions or attachments are preferred. Assume extensions subsumed by attachments. - * Updated attachment proposal with feedback - -* Open problems: - * attach expression evaluation order: right-to-left. Would be nice to have natural language - * Currently: `attach A() to <-r` - * Probably won't matter practically - * Require it to be view? - * attach as postfix operator / function? - * Functions would not require separate handling - * Naming: attachments are managers/glue vs first-class values like fields - * Deniz: Attachment is a Manager ( Costume Manager vs Hat ), So maybe using the attachment proposal but naming it an extension can be a better choice. Attachment gives me a different feeling to me - * Access control / reference kind (auth) - * Not in the proposal - * Currently non-auth reference, for owned and non-owned case - * Iterating has this problem: &AnyAttachment + reflection - -* Next steps: - * Address expression order - * Address naming - * Address access control - -### Add fields during contract update - -* /~https://github.com/onflow/flow/pull/1097 - -* Status: No update - -* Open problems: - * Implementation details for migration (not impossible, just needs to be laid out) - -* Next steps: - * Call? - * Anyone else interested? - -### Borrow Contract - -* /~https://github.com/onflow/flow/pull/1071 - -* Status: - * Waiting for assistance on Tests on the Cadence implementation side - -* Open problems: - * None - -* Next steps: - * Assist with implementation - -### Change semantics of for-loops - -* /~https://github.com/onflow/flips/blob/main/cadence/2022-10-11-for-loop-semantics.md - -* Status: - * Ready for review - -* Open problems: - * None - -* Next steps: - * Vote! - - -### Change the syntax for function types - -* /~https://github.com/onflow/flips/pull/43 - -* Status: - * FLIP open, ready for review - -* Open problems: - * None - -* Next steps: - * Vote! - -### Interface Inheritance - -* /~https://github.com/onflow/flips/pull/40 - -* Forum discussion: https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750 - -* Status: - * FLIP opened - * Implementation in progress - * Sentiment is positive for need - * Blocker is details - -* Open questions: - * How to resolve/handle conflicting default implementations? - * Do implementations of an interface also have to explicitly specify all inherited interfaces as well? - * Implicit or explicit conformance - * Definitely require implementation of all interfaces, inherited or not - * Maybe require explicit list, as acknowledgement - * Can conflict with default method resolution - * Related to first problem - * Should be consistent - * Multiple inheritance, lineralization - * E.g. Python: C3 - * Scala, Rust: explicit order, allow disambiguation - * Go? Struct embedding - * Kotlin: https://kotlinlang.org/docs/interfaces.html#resolving-overriding-conflicts - * Unique to Cadence, not in other languages: contract updatability - * Related: Condition ordering. Basically: order of execution for code in interfaces - * Conditions are view functions, so order "doesn't matter", but still needs to be deterministic (for reads, errors) - -* Next steps: - * Resolve open problems - * Document behaviour for current interface default functions => separate discussion - * Maybe have breakout session to speed up - * Who wants to join the discussion? - * Josh, Satyam, Austin, Bjarte - - -### Extend transaction format - -* /~https://github.com/onflow/flips/pull/41 - -* TLDR: - * Use-case: UA should allow users to choose e.g. storage location, etc. - * Broad scope / far-reaching (Cadence, UA, SDKs, etc.) - * Cadence: Multiple prepare blocks, field annotations ("roles"), multiple post blocks - * Benefits: Composition, safety - -* Status: - * FLIP open, looking for initial feedback - -* Open problems: - * Not attached to particular solution - * Complexity (many additions in multiple areas) - * Code generation functionality - -* Notes: - * Related to account initialization - * Austin will reach out to Jeff to align both efforts - -* Next steps: - * Needs more eyes, eventually have breakout session later - -## Behaviour of `Account.keys.forEach` - -* [/~https://github.com/onflow/cadence/pull/2038](/~https://github.com/onflow/cadence/pull/2038) - -* All keys or only revoked keys? -* Maybe indicate through naming? -* `AccountKey` has index -* User has the ability to filter revoked keys -* Currently: includes revoked keys, just like keys field -* Additional function for filtering revoked? - * Ideally index of all non-revoked keys in FVM -* Ordering? - * Maybe active first, revoked last - * Would ideally also be based on index in FVM -* Concern: feels like an array, so user/dev might assume certain ordering -* Documentation should (already does?) mention order -* Signal consideration of isRevoked by making it an additional parameter of the callback function? What about weight, that too (e.g. 0 weight)? -* (Keys are immutable, other than revocation; e.g. can't change weight) -* Next steps: - * Leave as-is - * Improve documentation - -## Removal/reduction of nested type requirements - -* Several options: - * Reduction to just events - * Removal; requires alternative - * Deniz' issue: /~https://github.com/onflow/cadence/issues/2069 - * "Global" events - * Could add additional information (originating contract) to global events - * /~https://github.com/onflow/cadence/issues/2081 - * /~https://github.com/onflow/cadence/issues/1161 - * Use interface default function implementation -* Related: additional feature to enforcing events are emitted -* Need to guarantee that only FTs emit events, and only "concrete" events -* Next steps: - * Session on new standards, then have better understanding about events - * e.g. separate vs shared event types - * Discussion in next Smart Contract Engineering Open House - * Evaluate options above, pros/cons - -## Resolving external mutation - -* /~https://github.com/dapperlabs/cadence-private-issues/issues/59 - -* Any solutions beyond the reference exploit may impact usability too negatively to be worth implementing? - -* Next step: - * Fill gap for references: dynamic check - * Does not need FLIP - * Maybe consider follow-up, address arbitrary mutating functions - * Remove public fields FLIP, was rejected - * Reconsider? Need to address outstanding problems diff --git a/meetings/2022-11-16-Interface-Inheritance.md b/meetings/2022-11-16-Interface-Inheritance.md deleted file mode 100644 index 8dc40689d4..0000000000 --- a/meetings/2022-11-16-Interface-Inheritance.md +++ /dev/null @@ -1,32 +0,0 @@ -# Nov 16, 2022 - -## Interface Inheritance Meeting Notes - -* FLIP: /~https://github.com/onflow/flips/pull/40 - -* Forum discussion: https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750 - -* Open Questions: - * Functions with conditions: - * FLIP proposes to order them in a pre-determined order and run them all. - * No overriding is supported (because of security concerns). - * Is overriding needed? Potentially unsafe to do so. - - * Default functions: Two main concerns. - * Should allow overriding of default functions? - * Can be a security/safety concern. - * Someone in a middle of an inheritance chain can override a default function, which would change the behavior for downstream contracts. - * One solution is to make default functions to be 'view' only. - * Reduce the depth/impact of security concerns of overriding. - * Still going to need a way to resolve ambiguity. e.g: Two ‘getId()’ view functions are available; which of the two should be called? - * How to resolve ambiguity, when two or more default implementations are available for functions? - * Two potential solutions: - * Ask the user to solve it by overriding the method inside the concrete-type/interface which faces ambiguity - (This is what is proposed in the FLIP). - * Ambiguity resolution of default functions in concrete types also uses the same approach. - See: /~https://github.com/onflow/cadence/pull/1076#discussion_r675861413 - * Order/linearize the default functions and pick the one that is 'closest' to the current interface/concrete type. - * It is 'safe' only if the default functions are view only. - * Might be surprising to the user. - * Already disregarded this option for default functions ambiguity resolution in concrete implementations. - * Need to resolve ambiguity regardless of whether default function overriding is supported or not. diff --git a/meetings/2023-01-10.md b/meetings/2023-01-10.md deleted file mode 100644 index 558369152f..0000000000 --- a/meetings/2023-01-10.md +++ /dev/null @@ -1,169 +0,0 @@ -# Jan 10, 2023 - -## FLIPs - -### Capability Controllers - -[/~https://github.com/onflow/flow/pull/798](/~https://github.com/onflow/flow/pull/798) - -* Status: - * Final API discussions - * TODO: - * Compatibility with AuthAccount capabilities and Inbox API - * Emit events -* Open problems: - * None -* Next steps: - * Vote! - -### Auth fields and Safe Downcasting - -[/~https://github.com/onflow/flips/pull/54](/~https://github.com/onflow/flips/pull/54) - -* Status: - * New - * Spearheaded by Daniel, Dete, and Kate - * Discuss proposal -* Open problems: - * Migration is complex and widespread - -### Attachments - -[/~https://github.com/onflow/flips/pull/11](/~https://github.com/onflow/flips/pull/11) - -[https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2](https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2) - -* Status: - * Approved and implemented - * Preview release available to try out the new feature -* Next steps: - * Implement iteration - * This depends on whether we have safe downcasting as an alternative for reflection (see above, [/~https://github.com/onflow/flips/pull/54](/~https://github.com/onflow/flips/pull/54)) - * Allow declaring an attachment for restricted types ("set of interfaces") [/~https://github.com/onflow/cadence/issues/2224](/~https://github.com/onflow/cadence/issues/2224) - * Attachment access control based on base resource access - * Depends on [/~https://github.com/onflow/flips/pull/54](/~https://github.com/onflow/flips/pull/54) - -### Interface Inheritance - -[/~https://github.com/onflow/flips/pull/40](/~https://github.com/onflow/flips/pull/40) - -[https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750](https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750) - -* Status: - * Had separate break-out sessions, will need another one - * Implementation complete for the proposal. Would need changes for the parts of the proposal that would change. - * Sentiment is positive for need - * Blocker is details (default functions, in particular) - * Ideas currently being discussed: - * Forbid interface changes - * Change default function - -* Open questions: - * Meeting notes: [https://docs.google.com/document/d/1LUvRg0T09mdE2Ndgti6xI1AY_KPYGJr2ZRLVuqzGxFg/edit#heading=h.d4wc1pr484vi](https://docs.google.com/document/d/1LUvRg0T09mdE2Ndgti6xI1AY_KPYGJr2ZRLVuqzGxFg/edit#heading=h.d4wc1pr484vi) - -* Next steps: - * Schedule another session - * Is this still a blocker for NFT/FT v2? - -### Extend transaction format -[/~https://github.com/onflow/flips/pull/41](/~https://github.com/onflow/flips/pull/41) - -* Status: - * Got some feedback, needs more - * Large proposal affecting many components - * Small change, big (good) implications - * Had break-out sessions, resolved some open questions - * Need to resolve remaining open questions - -* Open problems: - * No concrete solution, many possibilities, proposal has just one incomplete solution - * Solution a bit more concrete (e.g. block syntax) - * Unclear how wallets code-gen and insert parts into transaction - -* Next steps: - * Get more feedback - * Another Breakout session - * Prioritize over e.g. reentrancy and external mutability improvements - * Start with prototyping in Cadence (parsing and type checking) - -### AuthAccount capabilities - -* [/~https://github.com/onflow/flips/pull/53](/~https://github.com/onflow/flips/pull/53) - -* Status - * Had break-out session - * Child account model is really useful - * However, should make it "harder" to perform such administrative tasks (linking account capability), also other operations like adding keys - * At the same time: add safe-guards, require "sudo" signature - -* Open problems: - * Safe guards - * Once available, wallets need to support for safe guards (e.g. flag "sudo" transaction to user) - -* Next steps: - * Wait with approval of FLIP until safe-guards are available - * Start on discussion for "sudo" operations in forum, evtl. have FLIP - * Enable on Testnet to enable demo/development of ecosystem - -## Other items for Stable Cadence? - -[https://forum.onflow.org/t/the-path-to-stable-cadence/2702](https://forum.onflow.org/t/the-path-to-stable-cadence/2702) - -We're mainly looking for changes, especially breaking ones. -We'll prioritize additional features after Stable Cadence. - -* Type aliases - -* Enable non-facade capability patterns, e.g. attenuation "building blocks" - * Currently possible, but heavy-weight (e.g. defining new type) - * Sugar for e.g. adding pre and post conditions, wrapping, filtering, etc. around methods for an object - * → auth modifier FLIP - * → CapCon FLIP - -* Consumption of `self` - * Currently: `resource R { fun foo() { … } }` - * Implicitly: `resource R { fun foo(self: auth &R) { … } }` - * Could be explicit: `resource R { fun foo(self: @R) { … } }` - -* Cannot return/export certain types, cannot emit events - * Used to be a problem for function types, references, etc. - * Should be resolved now, please report non-exportable issues - * Maybe add ability to override serialization, e.g. allow export of function call value - -* Related: Allow import of any value in script (e.g. resource, capability) - -* Import just deserialize - * `struct Foo { let bar: Int; init(bar: Int) { pre { self.bar > 0 } { … } }` - * Currently allow e.g. `{"type": “Foo”, “bar”: 0}` - * Call initializer instead? - * Maybe allow either/or - -* Block access to certain read-only functions? - * Data is assumed to be public - * Minimize EN’s exclusive access/knowledge - -* Broken contracts - * Skip in storage iteration - * Might just be partially broken - * → General problem/idea: Catch panics and resume - * Issues: - * Implementation complexity (snapshotting/rollback in storage system, in-memory objects, etc.) - * Security problems (assumption of rollback) - * Could allow in scripts - * Maybe nested transactions? - * Currently only have nested transactions, no rollback/resumption - * Recovery: - * Would be case-by-case (parsing, type checking, conformance, casting failure, etc.) - * Could e.g. allow reading of fields of stored data, disallow function calls. Useful? - -## Nested type requirements → emit events in interfaces? - -* FT/NFT standards v2 -* [/~https://github.com/onflow/cadence/issues/1283](/~https://github.com/onflow/cadence/issues/1283) -* [/~https://github.com/onflow/cadence/issues/2081](/~https://github.com/onflow/cadence/issues/2081) -* [/~https://github.com/onflow/cadence/issues/2069](/~https://github.com/onflow/cadence/issues/2069) - -## Allow deletion of storage values with broken types? - -- [/~https://github.com/onflow/cadence/issues/2170](/~https://github.com/onflow/cadence/issues/2170) - diff --git a/meetings/2023-02-23.md b/meetings/2023-02-23.md deleted file mode 100644 index c114c438ee..0000000000 --- a/meetings/2023-02-23.md +++ /dev/null @@ -1,171 +0,0 @@ - -# Feb 23, 2023 - -## FLIPs - -### Capability Controllers -[/~https://github.com/onflow/flow/pull/798](/~https://github.com/onflow/flow/pull/798) - -* Status: - * Had many breakout sessions - * Final API discussions - * TODO: - * Compatibility with AuthAccount capabilities - * Backwards compatibility / migration of existing data - * Emit events - * Pet names - -* Open problems: - * Backwards compatibility / migration of existing data - -* Next steps: - * Update proposal - * One more breakout session - * Vote! - -### Entitlements and Safe Downcasting -[/~https://github.com/onflow/flips/pull/54](/~https://github.com/onflow/flips/pull/54) - -* Status: - * Zeroing in on entitlements concept - * Getting close to final design - * Related: [account entitlements](https://forum.onflow.org/t/super-user-account/4088) - -* Open problems: - * How do nested composite fields work? - * Declaration syntax (resource-typed members) - -* Next steps: - * Breakout session for nested composite fields - * Asynchronous discussion for declaration syntax - * Vote! - -### Attachments - -[/~https://github.com/onflow/flips/pull/11](/~https://github.com/onflow/flips/pull/11) - -[https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2](https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2) - -* Status: - * Approved and implemented - * Preview release available to try out the new feature - * Second preview release - -* Open problems: - * Trolling attack - * Problem: - * Attachments introduce the problem of receiving arbitrary values - * What if attachment aborts in destructor? - * Multiple kinds of aborts: panic, infinite loops, etc. - * Owner cannot remove attachment - * Owner cannot destroy outer resource - * Solution ideas: - * Allow force delete? - * How? - * What if code assumes destructor succeeded? e.g. FT total supply - * Return to creator? - * What if data cannot be paid for? - * Return to "network lost and found"? - * Preventing destroy - * technically nearly impossible atm - * Limit destroy? - * Some destructors mutate, e.g. FT updates contract total supply - * Only allow "self-calls"? - * "Two-staged destructors"? - * In other languages? - -* Next steps: - * Address trolling attack? - * Breakout session - * Deploy to TN, not MN - * Not feature flagged, would need two separate flow-go builds - -### Interface Inheritance - -[/~https://github.com/onflow/flips/pull/40](/~https://github.com/onflow/flips/pull/40) - -[https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750](https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750) - -* Status: - * No further progress - * Currently at bottom of priorities - -* Open questions: - * Meeting notes: [https://docs.google.com/document/d/1LUvRg0T09mdE2Ndgti6xI1AY_KPYGJr2ZRLVuqzGxFg/edit#heading=h.d4wc1pr484vi](https://docs.google.com/document/d/1LUvRg0T09mdE2Ndgti6xI1AY_KPYGJr2ZRLVuqzGxFg/edit#heading=h.d4wc1pr484vi) - -* Next steps: - * Schedule another session - * Is this still a blocker for NFT/FT v2? - -### Extend transaction format -[/~https://github.com/onflow/flips/pull/41](/~https://github.com/onflow/flips/pull/41) - -* Status: - * Had many breakout sessions - * Zeroing role based syntax - * Roles have both prepare and resolve - -* Open problems: - * Unexplored corner: - * Useful for multi-sign use-cases - * Does model also make sense for single-sign use-cases? - * Signer assignment - * Mapping signatures to roles - * Currently Flow transaction signatures are sequential - * Action-based model? - -* Next steps: - * Another breakout session to continue conversation - * Update Extended Transaction Format FLIP with meeting notes from last breakout session - * Add information about new prepare/resolve mechanic proposed - -### AuthAccount capabilities - -[/~https://github.com/onflow/flips/pull/53](/~https://github.com/onflow/flips/pull/53) - -* Status - * Had break-out session - * Preview release - * Enabled on all networks but Mainnet - * Working on [account entitlements](https://forum.onflow.org/t/super-user-account/4088) - * Want to approve and - -* Open problems: - * Forbid Public? - * Could restrict for linkAccount - * What about CapCon issueAccount? introduce AccountCapability to allow distinguishing? - * How can we get it out to Mainnet? - * Add temporary mechanism, e.g. another type, like proposed originally in [https://forum.onflow.org/t/super-user-account/4088](https://forum.onflow.org/t/super-user-account/4088) ? - * Need to prevent accidental signing - -* Next steps: - * Brainstorm temporary solution - * Another breakout session - * Involve wallet folks (e.g. Dapper, Blocto, etc.) - -### External Mutability -[/~https://github.com/onflow/flips/pull/58](/~https://github.com/onflow/flips/pull/58) - -[/~https://github.com/onflow/flips/pull/59](/~https://github.com/onflow/flips/pull/59) - -* Status: - * Had breakout session - * Multiple alternatives / FLIPs - * FLIP 58: - * Add additional static checks - * Deemed overkill - * FLIP 59: - * Remove/restrict let fields - * Deemed better than 58 - * Impact analysis: - * Inner mutability used as a feature - * E.g. MetadataViews standard - * Need delegation functions for nested members - * More boilerplate - * Moves problem, but does not solve it - -* Open problems: - * Unclear how to proceed - -* Next steps: - * Breakout session to determine how to proceed diff --git a/meetings/2023-04-13.md b/meetings/2023-04-13.md deleted file mode 100644 index 80a5fad37b..0000000000 --- a/meetings/2023-04-13.md +++ /dev/null @@ -1,291 +0,0 @@ - -# Apr 13, 2023 - -* First fully open/public meeting 🎉 - -* Code coverage feature shipping in CLI 🎉 - - * Huge shoutout to Ardit Marku from Build Squad - -* New contributor: darkdrag00nv2 🎉 - -* Contribute: - * FLIPs - - * Cadence: [/~https://github.com/onflow/cadence/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22Good+First+Issue%22](/~https://github.com/onflow/cadence/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22Good+First+Issue%22) - - * Cadence tools: [/~https://github.com/onflow/cadence-tools/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22Good+First+Issue%22](/~https://github.com/onflow/cadence-tools/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22Good+First+Issue%22) - -## FLIPs - -### AuthAccount capabilities - -* [/~https://github.com/onflow/flips/pull/53](/~https://github.com/onflow/flips/pull/53) -* Status - * Approved and implemented 🎉 - -### Capability Controllers - -* FLIP: [/~https://github.com/onflow/flow/pull/798](/~https://github.com/onflow/flow/pull/798) - -* Status: - - * Had many breakout sessions - - * Final API discussions - - * Implementation in progress - - * No remaining concerns - -* Open problems: - - * API: Capability publishing - -* Next steps: - - * One more breakout session - - * **Vote!** - -### Entitlements and Safe Downcasting - -* FLIP: [/~https://github.com/onflow/flips/pull/54](/~https://github.com/onflow/flips/pull/54) - -* Status: - - * Had breakout session for nested entitlements. Consensus on solution - - * Implementation in progress - - * No remaining concerns - -* Open problems: - - * Attachments - -* Next steps: - - * Address remaining technical issues async - - * **Vote!** - -### Attachments - -* Attachments FLIP: [/~https://github.com/onflow/flips/pull/11](/~https://github.com/onflow/flips/pull/11) - -* Forum discussion: [https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2](https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2) - -* Status: - - * Approved and merged 🎉 - - * Deployed to Testnet - - * Receiving feedback - - * Discovering use-cases - - * Need mitigation for trolling attack - - * Mainnet blocked on solution for trolling attack - - * Had breakout session for trolling attack - - * Have idea for solution, but might depend on breaking change (Stable Cadence) - -* Open problem: - - * Trolling attack - -* Next steps: - - * Address trolling attack - - * Need breakout session - -### Interface Inheritance - -* FLIP: [/~https://github.com/onflow/flips/pull/40](/~https://github.com/onflow/flips/pull/40) - -* Forum discussion: [https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750](https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750) - -* Status: - - * Was on hold due to prioritization, planning to continue now, given other FLIPs done - - * Had breakout session - - * Implementation available - -* Open questions: - - * Multiple interface default functions (diamond problem) - - * Meeting notes: [https://docs.google.com/document/d/1LUvRg0T09mdE2Ndgti6xI1AY_KPYGJr2ZRLVuqzGxFg/edit#heading=h.d4wc1pr484vi](https://docs.google.com/document/d/1LUvRg0T09mdE2Ndgti6xI1AY_KPYGJr2ZRLVuqzGxFg/edit#heading=h.d4wc1pr484vi) - -* Next steps: - - * Schedule another breakout session - - * Is this still a blocker for NFT/FT v2? - - * Still being used, expected to be available - - * Not 100% required, but preferred. Less prone to errors - -### Extend transaction format - -* FLIP: [/~https://github.com/onflow/flips/pull/41](/~https://github.com/onflow/flips/pull/41) - -* Status: - - * No updates at the moment - - * Last breakout session was a while back - - * Planning to restart working group - -* Open problems: - - * Unexplored corner: - - * Useful for multi-sign use-cases - - * Does model also make sense for single-sign use-cases? - - * Signer assignment - - * Mapping signatures to roles - - * Currently Flow transaction signatures are sequential - - * Action-based model? - -* Next steps: - - * Have another breakout session - -### External Mutability - -* [/~https://github.com/onflow/flips/pull/58](/~https://github.com/onflow/flips/pull/58) - -* [/~https://github.com/onflow/flips/pull/59](/~https://github.com/onflow/flips/pull/59) - -* Status - - * Had breakout session - - * Multiple alternatives / FLIPs - - * FLIP 58: - - * Add additional static checks - - * Deemed overkill - - * FLIP 59: - - * Remove/restrict let fields - - * Deemed better than 58 - - * Impact analysis: - - * Inner mutability used as a feature - - * E.g. MetadataViews standard - - * Need delegation functions for nested members - - * More boilerplate - - * Moves problem, but does not solve it - - * Investigating another idea (entitlements, references to fields) - -* Open problems: - - * Usability - - * FLIPs have different compromises - -* Next steps: - - * Breakout session to determine how to proceed - -## Related FLIPs - -### Account linking standard - -* FLIP: [/~https://github.com/onflow/flips/pull/72](/~https://github.com/onflow/flips/pull/72) - -* Status: - - * Had breakout session - - * Great feedback - - * Implementation in progress: - - * [/~https://github.com/Flowtyio/restricted-child-account](/~https://github.com/Flowtyio/restricted-child-account) - - * Positive sentiment, thumbs up from e.g. Flowty, Niftory, Dapper, etc - - * Wallets like it, even though it is more work for them - -* Open problem: - - * Regulatory risk for application developers - - * Discussions with legal council, technical solution - - * Discovery of linked assets - -* Next steps: - - * Work out how to restrict access - - * Continue implementation - -### FT/NFT v2 standards - -* FLIP: [/~https://github.com/onflow/flips/pull/56](/~https://github.com/onflow/flips/pull/56) - -* Status: - - * Multiple breakout sessions - - * Several major changes: - - * [/~https://github.com/onflow/flow-nft/pull/126#issuecomment-1505864702](/~https://github.com/onflow/flow-nft/pull/126#issuecomment-1505864702) - -* Open problems: - - * Waiting on FLIP for emitting events from interfaces (would allow nested type requirements) - - * [/~https://github.com/onflow/cadence/issues/2069](/~https://github.com/onflow/cadence/issues/2069) - - * Need to open FLIP for removal of nested type requirements - - * Upgrade constraints - -* Next steps: - - * Breakout session for upgrade - - * Maybe needs storage migration - - * Open FLIP for removal of nested type requirements - -## Questions - -* Changelog for Stable Cadence? - - * Announcement of breaking changes Stable Cadence in forum - - * [https://forum.onflow.org/t/another-update-on-stable-cadence/3715](https://forum.onflow.org/t/another-update-on-stable-cadence/3715) - - * Preview release available, needs to be updated - - * Will create TN instance with changes diff --git a/meetings/2023-05-04.md b/meetings/2023-05-04.md deleted file mode 100644 index df84098a6a..0000000000 --- a/meetings/2023-05-04.md +++ /dev/null @@ -1,167 +0,0 @@ -# May 4th, 2023 - -## FLIPs - -### Capability Controllers - -* FLIP: [/~https://github.com/onflow/flow/pull/798](/~https://github.com/onflow/flow/pull/798) - -* Status: - * Final API adjustments - * Implementation nearing completion - * No remaining concerns - -* Open problems: - * None - -* Next steps: - * Update FLIP, no capcons for links - * Migration, rollout documentation - * Documentation around pattern (e.g. getCapability to construct, link later) - * Clarify migration: find storage path, storage path does not need to store anything - * **Accept, unless objections** - -### Entitlements and Safe Downcasting - -* FLIP: [/~https://github.com/onflow/flips/pull/54](/~https://github.com/onflow/flips/pull/54) - -* Status: - * Implementation done - * No remaining concerns - * Additional features requested → follow-up FLIPs - -* Open problems/concerns: - * Complexity - * Parts: entitlements, downcasting, mappings - * Syntax (comma, and, set) - * Migration? - * Current access control pattern: public declaration, *but* restricted type to gate access - * Maybe get rid of pub and priv? - * Type in existing capability - * Breakage is OK, security problem not. Maybe have contract be broken until fixed - -* Next steps: - * Details for migration, maybe breakout session - * Documentation and tutorials, for existing and new developers - * Demonstrate with e.g. AuthAccount/PublicAccount, standard library (arrays, dictionaries, etc.), FT, NFT, etc. - * Preview release for Stable Cadence: Emulator, Playground, etc. - * **Accept, unless objections** - * Maybe propose removal of restricted types, not "necessary" or very useful anymore - -### Attachments - -* FLIP: [/~https://github.com/onflow/flips/pull/11](/~https://github.com/onflow/flips/pull/11) - -* Forum discussion: [https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2](https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2) - -* Status: - * Approved and merged 🎉 - * Deployed to Testnet - * Receiving feedback - * Discovering use-cases - * Need mitigation for trolling attack - * Mainnet blocked on solution for trolling attack - * Had breakout session for trolling attack - * Have idea for solution, but might depend on breaking change (Stable Cadence) - -* Open problem: - * Trolling attack, blocking. Working on solution - -* Next steps: - * Address trolling attack - * Breakout session for contexts ("try-catch") in public - -### Interface Inheritance - -* FLIP: [/~https://github.com/onflow/flips/pull/40](/~https://github.com/onflow/flips/pull/40) - -* Forum discussion: [https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750](https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750) - -* Status: - * Had more breakout sessions, ironed out almost all last questions/problems - * Implementation available - -* Open questions/concerns: - * Explicit declaration of inherited interfaces? - * Declaration (conformance list) - * Also in restricted types? Subtyping relationship → clarify in FLIP - * No tooling required when reading contract - * Also helps author - * Verbosity / explicitness vs conciseness / implicitness - * Example: FT - -* Next steps: - * Resolve last question/concern - * **Accept, unless objections** - -### Extend transaction format - -* FLIP: [/~https://github.com/onflow/flips/pull/41](/~https://github.com/onflow/flips/pull/41) - -* Status: - * No updates at the moment - * Last breakout session was a while back - * Planning to restart working group - -* Open problems: - * Unexplored corner: - * Useful for multi-sign use-cases - * Does model also make sense for single-sign use-cases? - * Signer assignment - * Mapping signatures to roles - * Currently Flow transaction signatures are sequential - * Action-based model? - -* Next steps: - * Have another breakout session - * Contact Jeff - -### External Mutability - -* [/~https://github.com/onflow/flips/pull/58](/~https://github.com/onflow/flips/pull/58) - -* [/~https://github.com/onflow/flips/pull/59](/~https://github.com/onflow/flips/pull/59) - -* Status - * Had more breakout session - * Working on comparison and examples - -* Open problems: - * Usability - * FLIPs have different compromises - -* Next steps: - * Comparison of different solutions and examples - * Another breakout session - -### Interface Conformance Improvements - -* FLIP: [/~https://github.com/onflow/flips/pull/83](/~https://github.com/onflow/flips/pull/83) - -* Overview: - * Relaxation of existing restriction for interface conformance - * Default function in one interface + Conditions in another interface is currently rejected - * Proposal is to relax restriction and allow this case, given there is no conflict - -* Open problem: - * Conditions may currently have side-effects - * Delay until Stable Cadence? - -* Status: - * Discuss and approve asynchronous - -## Questions - -* Can/should we maybe wipe Testnet? - * Many broken/stale accounts and contracts - * Hadn’t come up before - * Maybe suggest, e.g. in GitHub discussions and/or forum - * Big disruption for some users - * Iteration broken (but shouldn’t be) - * More realistic? There will be always broken code / accounts etc - * Want to be able to test if dapp works with broken - * Testnet is "staging" for Mainnet - * Cannot wipe Mainnet - * After Stable Cadence, should be less of an issue - * Maybe FLIP? "Governance"? - * Should be able to force delete broken values (--> force delete problem, see above: attachment trolling problem) diff --git a/meetings/2023-06-15.md b/meetings/2023-06-15.md deleted file mode 100644 index 8f2ff0df6f..0000000000 --- a/meetings/2023-06-15.md +++ /dev/null @@ -1,274 +0,0 @@ -# June 15th, 2023 - -## FLIPs - -### Capability Controllers - -* FLIP: [/~https://github.com/onflow/flow/pull/798](/~https://github.com/onflow/flow/pull/798) - -* Status: - * FLIP approved and merged 🎉 - * Implemented - * Deployed on TN - * Need documentation - -### Entitlements and Safe Downcasting - -* FLIP: [/~https://github.com/onflow/flips/pull/54](/~https://github.com/onflow/flips/pull/54) - -* Status: - * FLIP approved and merged 🎉 - * Implementation almost complete (reference conversion) - * Plan for migration: [/~https://github.com/onflow/flips/pull/95](/~https://github.com/onflow/flips/pull/95) - -* Open problems/concerns: - * Migration - * Need to migrate values (run-time types) and need to e.g. re-hash in dictionary - -* Next steps: - * Merge last PR(s) - * Preview release for Stable Cadence: Emulator, Playground, etc. - -### Attachments - -* FLIP: [/~https://github.com/onflow/flips/pull/11](/~https://github.com/onflow/flips/pull/11) - -* Forum discussion: [https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2](https://forum.onflow.org/t/flip-cadence-extensions-attachments/3645/2) - -* Status: - * FLIP approved and merged 🎉 - * Deployed to Testnet - * Receiving feedback - * Discovering use-cases - * Need mitigation for forced resource deletion - * Mainnet blocked on solution for forced resource deletion solution - * Had breakout session for resource deletion solution - * Have idea for solution, but might depend on breaking change (Stable Cadence) - -* Open problem: - * Resource deletion, blocking. Working on solution - * Maybe deploy to MN without solution? - -* Next steps: - * Resource deletion solution - -### Interface Inheritance - -* FLIP: [/~https://github.com/onflow/flips/pull/40](/~https://github.com/onflow/flips/pull/40) - -* Forum discussion: [https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750](https://forum.onflow.org/t/flip-interface-inheritance-in-cadence/3750) - -* Status: - * FLIP approved and merged 🎉 - * Implemented - -### Interface Conformance Improvements - -* FLIP: [/~https://github.com/onflow/flips/pull/83](/~https://github.com/onflow/flips/pull/83) - -* Overview: - * For interface conformance - * Allow two interfaces, conditions + default function (currently prohibited) - -* Status: - * Positive sentiment - -* Open questions: - * None - -* Next steps: - - * **Approve, unless opposition** - -### Remove pub, pub(set) and priv - -* FLIP: [/~https://github.com/onflow/flips/pull/84](/~https://github.com/onflow/flips/pull/84) - -* Overview: - * Remove access modifiers - * Replacements already exist (access(all), access(self)) - -* Status: - * Positive sentiment - * Implementation drafted - -* Open questions: - * None - -* Next steps: - * **Approve, unless opposition** - -### Emit events from function conditions, allow concrete events in interfaces - -* FLIP: [/~https://github.com/onflow/flips/pull/111](/~https://github.com/onflow/flips/pull/111) - -* Overview: - * Originally proposed by Deniz - * Emit events from conditions - * Allow concrete events in interfaces, avoids need for redeclaration - * Depends on nested type requirements getting removed - -* Status: - * Positive sentiment - -* Open questions: - * None - -* Next steps: - * Discuss a bit more - * Approve, unless opposition - -### Remove restricted types - -* FLIP: [/~https://github.com/onflow/flips/pull/85](/~https://github.com/onflow/flips/pull/85) - -* Overview: - * Remove restricted types - * Used for access control (restricted references) - * Redundant with addition of entitlements - * Interface sets (intersection types) - -* Status: - * Positive sentiment - -* Open questions: - * None - -* Next steps: - * **Approve, unless opposition** - -### Account Type - -* FLIP: [/~https://github.com/onflow/flips/pull/92](/~https://github.com/onflow/flips/pull/92) - -* Overview: - * Replace AuthAccount and PublicAccount - * Originated in account linking FLIP - * Use entitlements - -* Status: - * Positive sentiment - -* Open problems: - * None - * Migration (effects on existing API, forced breakage) - * (Naming) - -* Next steps: - * Finish design for migration - * **Approve, unless opposition** - -### External Mutability - -* Vision: [/~https://github.com/onflow/flips/pull/97](/~https://github.com/onflow/flips/pull/97) - * Not a FLIP, but supporting document - * Bigger picture for FLIPs - * Update on previous proposals - * Looking at problem again: use entitlements - -* FLIPs: - - * **Change member access semantic** - * FLIP: [/~https://github.com/onflow/flips/pull/89](/~https://github.com/onflow/flips/pull/89) - - * Overview: - * Accessing a field on a reference returns a reference - - * Status: - * Positive sentiment - - * Open questions: - * None - - * Next steps: - * **Approve, unless opposition** - - * **Introduce built-in mutability entitlements** - - * FLIP: [/~https://github.com/onflow/flips/pull/86](/~https://github.com/onflow/flips/pull/86) - - * Overview: - * Built-in entitlements for mutating functions of containers (arrays, dictionaries) - * Can also used by user-defined types - - * Status: - * Positive sentiment - - * Open questions: - * Naming - - * Next steps: - * Maybe approve and refactor names later if needed (before release) - * **Approve, unless opposition** - - * **Improve entitlement mappings** - - * FLIP: [/~https://github.com/onflow/flips/pull/94](/~https://github.com/onflow/flips/pull/94) - - * Overview: - * Allow entitlement mappings for non-reference fields - * Improves "Change member access semantics" (FLIP 89) - - * Status: - * Positive sentiment - - * Open questions: - * None - - * Next steps: - * **Approve, unless opposition** - -### Add Range type - -* FLIP: [/~https://github.com/onflow/flips/pull/96](/~https://github.com/onflow/flips/pull/96) - -* Status: - * Design almost complete - * Implementation in progress - * Looking for feedback - * Positive sentiment, but details unclear - -* Open questions: - * Multiple types? - -* Next steps: - * Complete - * **Approve, unless opposition** - -### Extend transaction format - -* FLIP: [/~https://github.com/onflow/flips/pull/41](/~https://github.com/onflow/flips/pull/41) - -* Status: - * No updates at the moment - * Last breakout session was a while back - * Planning to restart working group - -* Open problems: - - * Unexplored corner: - * Useful for multi-sign use-cases - * Does model also make sense for single-sign use-cases? - - * Signer assignment - * Mapping signatures to roles - * Currently Flow transaction signatures are sequential - - * Action-based model? - -* Next steps: - * Have another breakout session - * Contact Jeff - -## Questions/Feedback - -* Indicate feature support in CLI - -* Applications to demo changes and additions - - * Candidates: - * Standards (FT, NFT) - * Core contracts - * Kitty Items (e.g. for marketplace) - * NFT Pawn Shop - * Asset Handover diff --git a/meetings/2023-08-15.md b/meetings/2023-08-15.md deleted file mode 100644 index f215b35d68..0000000000 --- a/meetings/2023-08-15.md +++ /dev/null @@ -1,167 +0,0 @@ -# Aug 14th, 2023 - -## Ways to contribute - -* Participate in [FLIP (Flow Improvement Proposal) discussions](/~https://github.com/onflow/flips) -* Contribute to Cadence implementation: ➡️[GitHub issues](/~https://github.com/onflow/cadence/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22Good+First+Issue%22) -* Contribute Cadence tools: ➡️[GitHub issues](/~https://github.com/onflow/cadence-tools/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22Good+First+Issue%22) - -## FLIPs - -### Interface Conformance Improvements - -* FLIP: [/~https://github.com/onflow/flips/pull/83](/~https://github.com/onflow/flips/pull/83) -* Status: - * FLIP approved and merged 🎉 - -### Remove pub, pub(set) and priv - -* FLIP: [/~https://github.com/onflow/flips/pull/84](/~https://github.com/onflow/flips/pull/84) -* Status: - * FLIP approved and merged 🎉 - -### Emit events from function conditions, allow concrete events in interfaces - -* FLIP: [/~https://github.com/onflow/flips/pull/111](/~https://github.com/onflow/flips/pull/111) -* Status: - * FLIP approved and merged 🎉 - -### Remove restricted types, interface set types - -* FLIP: [/~https://github.com/onflow/flips/pull/85](/~https://github.com/onflow/flips/pull/85) -* Status: - * FLIP approved and merged 🎉 - -### Add Range type - -* FLIP: [/~https://github.com/onflow/flips/pull/96](/~https://github.com/onflow/flips/pull/96) -* Status: - * FLIP approved and merged 🎉 - -### External Mutability - -* Vision: [/~https://github.com/onflow/flips/pull/97](/~https://github.com/onflow/flips/pull/97) -* FLIPs: - * **Change member access semantic** - * FLIP: [/~https://github.com/onflow/flips/pull/89](/~https://github.com/onflow/flips/pull/89) - * Status: - * FLIP approved and merged 🎉 - * **Improve entitlement mappings** - * FLIP: [/~https://github.com/onflow/flips/pull/94](/~https://github.com/onflow/flips/pull/94) - * Status: - * FLIP approved and merged 🎉 - * **Introduce built-in mutability entitlements** - * FLIP: [/~https://github.com/onflow/flips/pull/86](/~https://github.com/onflow/flips/pull/86) - * Status: - * Positive sentiment - * No new feedback in last few weeks - * Implementation and documentation ready - * Last conversation was about naming convention for entitlements - * Open problems: - * None - * Next steps: - * **Approved** - -### Account Type - -* FLIP: [/~https://github.com/onflow/flips/pull/92](/~https://github.com/onflow/flips/pull/92) -* Status: - * Positive sentiment - * No new feedback in last few weeks - * Implementation ready -* Open problems: - * None -* Next steps: - * **Approved** - -### Remove nested type requirements - -* FLIP: [/~https://github.com/onflow/flips/pull/118](/~https://github.com/onflow/flips/pull/118) -* Overview: - * Remove nested type requirements - * Allow declaration of events in interfaces as concrete types (used in core contracts) -* Status: - * Positive sentiment - * No new feedback in last few weeks - * Implementation ready (2 PRs) -* Open problems: - * None -* Next steps: - * **Approved** - -### Random function - -* FLIP: [/~https://github.com/onflow/flips/pull/118](/~https://github.com/onflow/flips/pull/118) -* Overview: - * Rename unsafeRandom to random, underlying implementation has been secured using Flow protocol native random beacon - * Update the interface to a safer and more convenient one (generalized types and a modulo parameter) - * Rollout: add random, deprecate unsafeRandom, finally remove in SC release -* Status: - * Positive sentiment for random -* Open problems: - * Behavior in scripts - * Should not panic - * Several options - * Naming: - * Potential for misuse by developers. Unsafe → safe renaming might be confusing - * Maybe addressed by commit-reveal scheme FLIP: [/~https://github.com/onflow/flips/pull/123](/~https://github.com/onflow/flips/pull/123) -* Next steps: - * Determine script behavior, maybe propose in separate FLIP - * Schedule breakout session - * Deniz - * You? Leave a comment! -* Feedback: - * Just switch unsafeRandom to safe random generator for now - * Different name/indicator to prevent misuse? - * Trigger developers to check documentation, see/use commit-reveal scheme design pattern to use returned safe random properly - * `random(iReadTheDocs: Bool)` - * Our bar is very high, other systems isn't - -### Commit-reveal scheme for non-reverted randomness - -* FLIP: [/~https://github.com/onflow/flips/pull/123](/~https://github.com/onflow/flips/pull/123) -* Overview: - * Provide a safe pattern to address transaction abortion after a random is revealed - * Commit to block - * In the future, query history of past randoms - * Use past, committed seed for new random -* Status: - * Positive sentiment - * Waiting for feedback -* Open problems: - * None -* Next steps: - * Gather more feedback - -### Remove custom destructors - -* FLIP: [/~https://github.com/onflow/flips/pull/131](/~https://github.com/onflow/flips/pull/131) -* Overview: - * Proposal to address inability for users to destroy resources they own - * One of the discussed options (others: try/catch, etc.) - * Originated from attachments feature (attachment might prevent destruction of whole resource) - * Remove destroy - * Allows users to always destroy resources -* Status: - * New - * Very much an RFC! -* Open problems: - * Philosophical question (sending to "burner account") - * Existing code / applications - * "Migration" path for use-cases like FT total supply -* Next steps: - * Discuss - * Breakout session - * You? Leave a comment! - * Publish resource destruction options document, add to FLIP -* Feedback: - * Provide details on impact on applications, e.g. core contracts like FT/NFT - * Chicken-and-egg problem: need more data on how feature is used, can then figure out if/what alternative is - * Even if exploit vector isn’t used today, it should be addressed/prevented - * If important use-case exists, also not worth it to remove - * Emitting events could maybe be allowed - * Given impact, reach out to more developers / gather more feedback - -## Related FLIPs / forum discussions - -* [https://forum.onflow.org/t/storage-fees-improvements-and-few-random-ideas-on-the-way/5104](https://forum.onflow.org/t/storage-fees-improvements-and-few-random-ideas-on-the-way/5104) \ No newline at end of file diff --git a/meetings/2023-09-12.md b/meetings/2023-09-12.md deleted file mode 100644 index 0b2f11dc0f..0000000000 --- a/meetings/2023-09-12.md +++ /dev/null @@ -1,185 +0,0 @@ - -## Sep 12th, 2023 - -### Ways to contribute - -* Participate in [FLIP (Flow Improvement Proposal) discussions](/~https://github.com/onflow/flips) - -* Contribute to Cadence implementation: ➡️[GitHub issues](/~https://github.com/onflow/cadence/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22Good+First+Issue%22) - -* Contribute Cadence tools: ➡️[GitHub issues](/~https://github.com/onflow/cadence-tools/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A%22Good+First+Issue%22) - -### Website - -[https://cadence-lang.org/](https://cadence-lang.org/) 👀 - -### Progress on Cadence 1.0 - -[https://forum.onflow.org/t/update-on-cadence-1-0/5197](https://forum.onflow.org/t/update-on-cadence-1-0/5197) 🎉 - -### FLIPs - -#### Relax interface conformance restrictions - -* FLIP: [/~https://github.com/onflow/flips/pull/134](/~https://github.com/onflow/flips/pull/134) - -* Overview: - - * Follow up on interface conformance improvements ([/~https://github.com/onflow/flips/pull/83](/~https://github.com/onflow/flips/pull/83)). - - * Proposes to allow empty function declaration defined in one interface to coexist with a default function implementation defined in another interface. - - * Currently the same is allowed if the empty declaration has a pre/post condition. - - * When interface default functions were introduced, interface inheritance did not exist yet - - * Current behavior was intentional, tried to avoid interface author breaking implementations by adding function implementation (default function) - -* Status: - - * FLIP is waiting for a final decision - - * Reference implementation is complete: [/~https://github.com/onflow/cadence/pull/2725](/~https://github.com/onflow/cadence/pull/2725) - -* Next steps: - - * Would like to get more feedback - - * Provide means / explanation to try out - -#### Random function - -* FLIP: [/~https://github.com/onflow/flips/pull/120](/~https://github.com/onflow/flips/pull/120) - -* Overview: - - * Rename unsafeRandom to random, underlying implementation has been secured using Flow protocol native random beacon - - * Update the interface to a safer and more convenient one (generalized types and a modulo parameter) - - * Rollout: add random, deprecate unsafeRandom, finally remove in SC release - -* Status: - - * Positive sentiment for random - - * Renamed to revertibleRandom - -* Open problems: - - * Behavior in scripts - - * Should not panic - - * Several options - - * Naming: - - * Potential for misuse by developers. Unsafe → safe renaming might be confusing - - * Maybe addressed by commit-reveal scheme FLIP: [/~https://github.com/onflow/flips/pull/123](/~https://github.com/onflow/flips/pull/123) - -* Next steps: - - * Voted, approved 🎉 - -#### Commit-reveal scheme for non-reverted randomness - -* FLIP: [/~https://github.com/onflow/flips/pull/123](/~https://github.com/onflow/flips/pull/123) - -* Overview: - - * Provide a safe pattern to address transaction abortion after a random is revealed - - * Commit to block - - * In the future, query history of past randoms - - * Use past, committed seed for new random - -* Status: - - * Positive sentiment - - * Waiting for feedback - -* Open problems: - - * Storage/sharing of state, see below - -* Next steps: - - * Gather more feedback - - * Maybe have breakout session to discuss concerns - -* Feedback: - - * Why stored on-chain? - - * What is the concern? - - * Should be stored in protocol state - - * Details on how data is shared/stored - - * If just implementation detail, make it explicit - - * Where else? - -#### Remove custom destructors - -* FLIP: [/~https://github.com/onflow/flips/pull/131](/~https://github.com/onflow/flips/pull/131) - -* Overview: - - * Proposal to address inability for users to destroy resources they own - - * One of the discussed options (others: try/catch, etc.) - - * Originated from attachments feature (attachment might prevent destruction of whole resource) - - * Remove destroy - - * Allows users to always destroy resources - -* Status: - - * Breakout session: Came up open problem - - * Synced with execution team, discussed tombstoning (marking data as deleted, "garbage collection") - - * Updated FLIP with default events - - * FLIP ready for another round of discussion - -* Open problems: - - * Philosophical question (sending to "burner account") - - * Existing code / applications - - * "Migration" path for use-cases like FT total supply - - * Tombstoning implementation - -* Next steps: - - * Need to discuss implementation approach more - - * Implementation is not blocking Stable Cadence release, but can vote on change itself, removal of custom destructors - - * Do not need a solution for "large resource deletion" problem - - * Breakout session next week, after giving time to read through updated proposal - -* Feedback: - -### Related FLIPs / forum discussions - -* [https://forum.onflow.org/t/idea-wasm-execution-engine-in-cadence/5164](https://forum.onflow.org/t/idea-wasm-execution-engine-in-cadence/5164) - -* [https://forum.onflow.org/t/storage-fees-improvements-and-few-random-ideas-on-the-way/5104](https://forum.onflow.org/t/storage-fees-improvements-and-few-random-ideas-on-the-way/5104) - -* [https://forum.onflow.org/t/seeking-feedback-on-cadence-cookbook-modernization/5200/2](https://forum.onflow.org/t/seeking-feedback-on-cadence-cookbook-modernization/5200/2) - diff --git a/meetings/2023-10-24.md b/meetings/2023-10-24.md deleted file mode 100644 index b8822d054e..0000000000 --- a/meetings/2023-10-24.md +++ /dev/null @@ -1,277 +0,0 @@ - -## Oct 24th, 2023 - -### FLIPs - -#### 134: Relax interface conformance restrictions - -* FLIP: [/~https://github.com/onflow/flips/pull/134](/~https://github.com/onflow/flips/pull/134) - -* Overview: - - * Follow up on interface conformance improvements ([/~https://github.com/onflow/flips/pull/83](/~https://github.com/onflow/flips/pull/83)). - - * Proposes to allow empty function declaration defined in one interface to coexist with a default function implementation defined in another interface. - - * Currently the same is allowed if the empty declaration has a pre/post condition. - - * When interface default functions were introduced, interface inheritance did not exist yet - - * Current behavior was intentional, tried to avoid interface author breaking implementations by adding function implementation (default function) - -* Status: - - * FLIP is waiting for a final decision - - * Reference implementation is complete: [/~https://github.com/onflow/cadence/pull/2725](/~https://github.com/onflow/cadence/pull/2725) - -* Next steps: - - * Would like to get more feedback - - * Provide means / explanation to try out - -* Notes: - - * Accepted - -#### 210: Improvement to entitlement mapping syntax - -* FLIP: [/~https://github.com/onflow/flips/pull/210](/~https://github.com/onflow/flips/pull/210) - -* Overview: - - * Got some feedback that visually entitlements and entitlement mappings appear too similar when used in an `access` modifier. This can be confusing to developers because the former cannot be accessed on an unentitled reference, while the latter can be (and produces an unentitled output) - - * Proposed needing a `mapping` keyword in access modifiers: e.g. `access(mapping M)` - -* Status: - - * FLIP proposed, has general approval - -* Next Steps: - - * Accept FLIP, merge implementation? - -* Notes: - - * Approved - -#### 196: Restrict Capabilities Publish - -* FLIP: [/~https://github.com/onflow/flips/pull/197](/~https://github.com/onflow/flips/pull/197) - -* Overview: - - * Current Cap Cons API allows publishing capabilities of another account - - * Was not possible with linking API - - * Could lead to confusion for developers (e.g. query balance, but balance is from another account) - -* Status: - - * Ready for vote - -* Next Steps: - -* Notes: - - * Approved - -#### 212: Reject references to references - -* FLIP: [/~https://github.com/onflow/flips/pull/212](/~https://github.com/onflow/flips/pull/212) - -* Overview: - - * It is currently possible to create references to references, e.g. &&T - - * Such references are not useful - - * In Cadence 1.0, additional work is requires to keep them working - - * Proposal is to forbid them - -* Status: - - * Ready for vote - -* Next Steps: - -* Notes: - - * Approved - -#### 131: Remove custom destructors - -* FLIP: [/~https://github.com/onflow/flips/pull/131](/~https://github.com/onflow/flips/pull/131) - -* Overview: - - * Proposal to address inability for users to destroy resources they own - - * One of the discussed options (others: try/catch, etc.) - - * Originated from attachments feature (attachment might prevent destruction of whole resource) - - * Remove destroy - - * Allows users to always destroy resources - -* Status: - - * Updated FLIP with default events - - * Discovered that introduction of attachments would require additional code in e.g. Vault.deposit to prevent exploit - - * FLIP ready for another round of discussion - -* Open problems: - - * Philosophical question (sending to "burner account") - - * Existing code / applications - - * "Migration" path for use-cases like FT total supply - - * Tombstoning implementation - -* Next steps: - - * Need to discuss implementation approach more - - * Implementation is not blocking Stable Cadence release, but can vote on change itself, removal of custom destructors - - * Do not need a solution for "large resource deletion" problem - - * Breakout session next week, after giving time to read through updated proposal - -* Feedback: - - * Non-mutable contraction mainnet using custom destructor - - * Overhead creating workaround - - * Will USDC implement a workaround ? - -* Notes: - - * Approved - -#### 95: Entitlements migration - -* FLIP: [/~https://github.com/onflow/flips/pull/95](/~https://github.com/onflow/flips/pull/95) - -* Overview: - -* Status: - -* Next Steps: - -#### 179: Staged Contract Updates - -* FLIP: [/~https://github.com/onflow/flips/pull/179](/~https://github.com/onflow/flips/pull/179) - -* Overview: - - * Contract mechanism to define contract update deployments and execute updates in stages at/beyond a block height. Execution can also be delegated to a third party via Capabilities - -* Status: - - * Proposed & approved by Jerome & Josh - - * Was hoping for community approval on the FLIP before moving to approval, but only feedback provided so far - -* Next Steps: - - * Approve unless recent feedback is opposed - - * Merge tryUpdate() to finalize v0 implementation & build out tests - - * Design automated update solution so delegated updates can be executed immediately post-spork - - * Begin to address callouts around: - - * Creating update configuration - - * Emulating configured updates - - * Monitoring update status - -### Other - -#### Discuss changes to attachments - -* Overview - - * Problem: - - * Attachments are able to declare what entitlements they need, to perform operations on base - - * A *third-party* might prepare a value with an attachment. With the transfer of the value, also the attachment and thus the permissions on the base, are transferred - - * The receiver might not realize - - * Reference to base stays "alive" beyond TX/script - - * Running example: - - * Currency converter on vault, can deposit and withdraw - - * Proposal: - - * Remove support for requirement of entitlements - - * Only allow public access to begin with - - * Later: Add support for entitled access, - - * e.g. through - - * Entitlement mapping - - * `access(M) attachment A for S {}` - - * Privilege escalation through mapping? - E.g. Deposit → Withdraw - - * ```cadence - mapping M { - X -> Y - } - - access(Y) fun foo() { - // can use X on base - } - ``` - - * Maybe hardcode to Identity mapping? - - * `access(X) fun foo() { … }` - - * no mapping - - * Requirements on per-function level (instead of whole attachment) - - * Do not want to require splitting attachments into parts - - * Alternative: Sanitization - - * Doesn’t scale, too easy to forget, footgun ("malicious USB stick") - -* Status: - - * Decide if this / what should be proposed in a FLIP - -* Next steps: - - * Propose FLIP for - - * Requirement removal - - * Propose unentitled access to start with - - * Can add entitled access later (see above) - - * Examples for proposals which allow entitlements diff --git a/meetings/2023-11-15.md b/meetings/2023-11-15.md deleted file mode 100644 index ea6c8018e5..0000000000 --- a/meetings/2023-11-15.md +++ /dev/null @@ -1,120 +0,0 @@ - -# Nov 15th, 2023 - -## FLIPs - -### 179: Staged Contract Updates - -* FLIP: [/~https://github.com/onflow/flips/pull/179](/~https://github.com/onflow/flips/pull/179) - -* Overview: - - * Contract mechanism to define contract update deployments and execute updates in stages at/beyond a block height. Execution can also be delegated to a third party via Capabilities - -* Status: - - * Approved - -### 217: New behavior for attachments with entitlements - -* FLIP: [/~https://github.com/onflow/flips/pull/213](/~https://github.com/onflow/flips/pull/213) - -* Overview: - - * Current attachment feature, requiring entitlements, allows third-parties to "sneak in" permissions into the base value - - * Proposal removes entitlement requirements, entitlements are derived from reference on base - - * Simple compromise - - * Tradeoff between power and safety. Only use-case that is no longer possible is read-escalation - -* Status: - - * "Audit" from security researcher - - * No open problems, proposal is complete and looking for feedback - -* Next Steps: - - * Accept unless there is no further feedback until end of next week - -## Other - -### Cadence 1.0 feedback - -* Austin reached out to community, asked for awareness - - * Very little awareness - - * Surprise of breaking changes - - * Breaking changes are not that big of a deal - - * But fact of breaking is scary - -* Going to talk to top 20 projects, with Andrea and Albert - - * Awareness - - * Get feedback - - * Support - -* Have not "advertised" it much so far - -* With rollout plan and environments, tools, etc. "ready", more announcements - -* Cadence 1.0 hackathon? (both projects and bug hunting / bug bash) - - * Example: OpenSea Sea Port bug bash - -* Cadence 1.0 office hours - -* Incentivize update? - -* Blackout periods? Awareness through disruption - - * TN - - * How to even do that on MN? Downtime would be brutal - - * Maybe depend on update staged? - -* How to amplify message? - - * In tooling like CLI, Emulator, etc. - - * In tools/projects like Flowdiver - - * On Website - -* Should not hide / make it very clear that this release is breaking - - * But also explain why the breaking changes are made (security, features, locked down contracts, etc.) - -### Cadence 1.0 migration plan - -* Had breakout session - -* Use Sandboxnet, clean network - - * Run pre-1.0 for a while, allow community to seed the environment with contracts and data - - * Then switch over - -* Is a clean Sandboxnet with 1.0 adding much value over Emulator? - - * Not really? For most developers Emulator is enough - - * Some developers don’t bother with the Emulator, go directly to TN - - * Some projects are relying on other projects (e.g FIND on FLOAT) - - * Difficult to have all dependencies deployed themselves in e.g. Emulator or even SN - - * Bringing up clean SN is not much effort - - * Bringing up SN from TN state is a lot of effort - - * "Seeding-period SN" solution good tradeoff diff --git a/meetings/README.md b/meetings/README.md new file mode 100644 index 0000000000..6d300c351c --- /dev/null +++ b/meetings/README.md @@ -0,0 +1,3 @@ +# Cadence Language and Execution Working Group + +Meeting notes moved to /~https://github.com/onflow/Flow-Working-Groups/tree/main/cadence_language_and_execution_working_group