-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: install module with delegation #3586
Conversation
🦋 Changeset detectedLatest commit: b402910 The changes in this PR will be included in the next version bump. This PR includes changesets to release 30 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so cool to see the delegation in action via these store log changes for the mock game contracts
installAsRoot: false, | ||
installStrategy: "delegation", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to install the metadata module via a delegation? (Do we want to give the installer ownership over the metadata tables or keep it like anyone can install it but it's immutable after it's been installed?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
chatted in discord:
this doesn't change the current behavior, which passed namespace ownership back to the deployer: https://github.com/latticexyz/mud/pull/3586/files#diff-4b5b7ac0dc35d7914ce67b4dfcee8d54a4814b759a87d0ddce84efe17d3ade08L55
which is ~almost always going to be the world creator, since this is a default module installed with the world deploy, and only in cases where you're deploying to an old world with a new MUD version would this be a potential issue
can separately decide what we wanna do going forward
readonly root: boolean; | ||
/** | ||
* Allow the module to call systems on your behalf. | ||
* Useful when modules need to create namespaces or | ||
* upgrade systems in namespaces you own. | ||
*/ | ||
readonly useDelegation: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we throw an error/warning if both root and useDelegation are set to true?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would be nice but we have no module config validation yet, nor super strong types, so didn't feel like adding it
what happens in this case is root
is picked first, then useDelegation
, then regular/default path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these config options will ideally be abstracted away into helpers provided by the module like defineERC20Module
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could make sense to use the same installStrategy: "root" | "delegation" | "default"
approach in config but will tackle that later when we clean up module config (needs a rethink for args anyway: #2957)
fixes #3569