Create 2024-02-15.mdx

meeting-notes/2024-02-15.mdx

@@ -0,0 +1,43 @@
+---
+title: '2024-02-15'
+authors: naman
+tags: [protocol]
+---
+
+<iframe
+  src="https://drive.google.com/file/d/1oBuYg_LvGRGnKpjezok6PQGVN8ZpqVvy/preview"
+  width="640"
+  height="360"
+  allow="autoplay"
+></iframe>
+
+[Discord agenda thread](https://discord.com/channels/897514728459468821/1207385360116490360)
+
+1. The meeting was focused on the process of adding host functions, using WebAuthN as the example use case; continued from the previous meeting.
+2. Discussion of remaining concerns with adding secp256r1 verification host function from previous meeting.
+  - What does it mean for secp256r1 to be added as a host function vs. as a signer type?
+    - As a host function, user can sign soroban auth entries. Need another stellar account to fund and submit tx to the chain. The latter can be done by a stellar account which may be operated by a wallet or a contract.
+    - __check_auth is invoked when the contract being interacted with calls require_auth
+3. CAP-52 was drafted to introduce encoding/decoding functions for Base64, which is needed by WebAuthN. Considerations discussed in the meeting:
+ - Performance: 1066 bytes that costs 1M instr to encode a 32byte hash; so the cost is very small and it’s questionable whether a host function is required.
+ - Interface required two functions (encode/decode)
+ - Implementation wise, WebAuthN requires url alphabet and padding, which decoder likely needs to support. Should we use symbols or ints? Do we need custom alphabets?
+ - Do we really need more encoding schemes? Isn’t XDR enough? 
+ - Expensive auth mechanisms, i.e. webauthn, cannot be coupled with contracts with heavy business logic (which might be a lot of contracts), thus making adoption problematic.
+ - We should probably add building blocks to enable the ecosystem to add new use cases.
+4. CAP-53  was drafted to introduce encoding/decoding functions for JSON, which is needed by WebAuthN. Considerations discussed in the meeting:
+ - Performance: 3.9Kb, 2.5M CPU instr.
+ - If the size of the input blob is unknown, execution time will increase.
+ - Valuable to have such a lightweight function that’ll be used in various place.
+ - Interface: 11 functions
+  - What to do with numbers and decimals? Add decimals and floats?
+  - We only have to extract one field for WebAuthN but what about the general case?
+ - The number type in JSON is decimal but soroban does not support that. How should this be handled?
+ - Discussion around alternative interface and implementations.
+5. Core dev concerns
+ - Maintainability: if you add a host function, you have to maintain it forever. If there are more versions, we have to keep it around.
+ - Expanded surface area for security bugs.
+ - Should define a path where core dev is not in the implementation loop, as their schedules are packed with stability work. How to prioritize against stability work, which may get derailed due to new functionality such as what’s being currently discussed.
+ - Next steps:
+   - Core team to put together a plan for adding Base64. This is an important exercise that helps determine even more challenges of doing so. The output of this exercise may be that base64 _shouldn’t_ in fact be implemented at this point.
+   - Discussion around the JSON interface is to be continued.