You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
IPlugin defines onInstall and onUninstall as such:
/// @notice Initialize plugin data for the modular account./// @dev Called by the modular account during `installPlugin`./// @param data Optional bytes array to be decoded and used by the plugin to setup initial plugin data for the modular account.function onInstall(bytescalldatadata) external;
/// @notice Clear plugin data for the modular account./// @dev Called by the modular account during `uninstallPlugin`./// @param data Optional bytes array to be decoded and used by the plugin to clear plugin data for the modular account.function onUninstall(bytescalldatadata) external;
bytes calldata is used because we expect different plugins to receive different shapes of data when initializing and cleaning up. However, there is no canonical way of determining how to encode this data from the client, without prior knowledge of how to encode it (e.g., access to the source code or documentation).
Perhaps this can be surfaced in pluginMetadata(), but more exploration needs to be done on the best format the encoding scheme should be returned. Ideally, the format should be easily parsable by client SDKs today.
The text was updated successfully, but these errors were encountered:
See huge value to ask plugins to provide data structures for installation/uninstallation for off-chain clients/services.
With an ongoing discussion in the TG channel about what data lives where (pluginMetadata or pluginManifest), it's worth some careful thoughts on where to surface those data.
Considering the separation of the two concepts:
pluginMetadata hosts view data that can be managed/updated by the plugin devs.
pluginManifest manages the immutable plugin installation instructions.
It might make more sense to include them in the pluginManifest.
IPlugin
definesonInstall
andonUninstall
as such:bytes calldata
is used because we expect different plugins to receive different shapes of data when initializing and cleaning up. However, there is no canonical way of determining how to encode this data from the client, without prior knowledge of how to encode it (e.g., access to the source code or documentation).Perhaps this can be surfaced in
pluginMetadata()
, but more exploration needs to be done on the best format the encoding scheme should be returned. Ideally, the format should be easily parsable by client SDKs today.The text was updated successfully, but these errors were encountered: