Sync stable cadence branch with master

meetings/2023-10-24.md

@@ -0,0 +1,277 @@
+
+## 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