search

erc6900 / resources

18 stars 4 forks source link

Community Call #7 #29

Closed jwindawi closed 3 months ago

jwindawi commented 4 months ago

Request a calendar invite

Previous call recap

Meeting Info

Agenda

  1. Ecosystem developments
  2. ERC-6900 updates
  3. Research and development

To add or request a topic that you'd like to discuss, please comment in response to this Issue below!

CodesMcCabe commented 3 months ago

Thanks to everyone who joined for Community Call 7!

A recap of the call:

6900 ecosystem development

  1. CollabLand article - How to write an ERC-6900 Plugin
  2. 6900 plugin template
  3. Modular Account plugin template
  4. Video - What are ERC-6900 plugins?
  5. Video - Spearbit 6900 & Modular Account Security Review

ERC-6900 Updates

  1. @adam-alchemy reviewed the merged PR #39 - Remove Hook Group. HookGroup internal storage struct was redundant. It's fields are now stored in selectorData
  2. @adam-alchemy discussed an experimental feature #40 - Merge validation function assignments
    • looking for feedback. Suggestion to merge the assigned validation plugin for userOp validation and runtime validation that account is responsible to track. By merging the assignment of these functions we can expect plugins to implement the functions (or revert if unsupported)
  3. @adam-alchemy discussed an experimental feature #41 - Remove function id
    • looking for feedback. Simplifies the standard to make it more compatible with other interfaces.
    • Remove function ids from plugin functions, and refactor account internals to only hold address types for validation functions and hooks
  4. @jaypaik discussed his thoughts on open PR #38 - add replacePlugin
    • comments left in PR
    • version registry seems nice but increases overhead and plugin data. We should explore simpler alternatives.
    • For replacing a plugin there are 2 use cases (1) have a plugin already installed and you want to swap it out for another, (2) Upgrade an existing plugin. This PR only addresses upgrading an existing plugin. We should rethink how plugins work with dependency id's. We might only need to work on the update piece.
    • For the data migration piece, we should consider re-exploring @yoavw's early ideas on storing plugin data.

Research & Development

  1. @dphilipson discussed his thoughts on permissions currently being overly broad
    • current system uses overly broad permissions
    • If a malicious plugin is requesting perms to takeover account we must depend on auditor for every change to a plugin. The goal of permissions is not to not need to depend on auditors for every change
    • Todays plugins need to decide on what permissions they want beforehand. We should explore allowing users to elect to accept permission at the time they install it
    • Hooks could also be customized at installation time
    • Dont require everything to be done at the time the plugin is written
    • Can do this today but not really practical in production

The next call will be on Thursday, March 28th at 17:00 UTC. Add the event to your calendar!