Merge pull request #2780 from onflow/bastian/meeting-2023-09-12

Add notes for 2023-09-12 meeting

meetings/2023-09-12.md

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