Dock Registry implementation

[gabrielstoica]

As discussed with @V1d0r and team, we're going to move the Dock creation process on-chain. This allows a MetaDock user to create and manage their Containers through a single access point.

DockRegistry follows the Factory Pattern, allowing users to deploy and manage multiple Containers and keep track of their parent Dock.

Breaking changes

DockRegistry stores the address of the ModuleKeeper. Therefore, when a new module is to be enabled, by calling the _enableModule() method on the ModuleManager, an extra call to get the ModuleKeeper address is made on the registry. For reference, check this line.

Container does not inherit from Ownable anymore. Instead, there is a local onlyOwner modifier that calls the DockRegistry.ownerOfContainer() method to check if msg.sender is the actual owner of the Container. As a result, the registry is the single place where the ownership of a container can be updated through the transferContainerOwnership() method.

task: c4378d88023a473187a82bd81ce095cc

[V1d0r]

This is a valuable enhancement, bringing the Dock onto the blockchain. The Dock is a critical component, and having the registry on-chain enables users to effectively manage containers, track ownership, and control permissions. Additionally, the ability to transfer containers and docks as the service evolves introduces the desired granularity and modularity.

Regarding the module keeper address stored in the Dock registry, it’s important to minimize redundant calls elsewhere in the code. It may be worthwhile to consider how other essential addresses, such as those for future management contracts, will be stored. For example, should we implement a mapping system for efficient address management? Should the contract be designed to be upgradable? These are questions worth exploring further.