Internal tables and systems of World

World uses Store internals, because it calls StoreCore.initialize in its constructor.

World's own internals are initialized via the deploy (opens in a new tab) cli utility (because they would exceed max contract size if called in a constructor).

Except NamespaceOwner is initialized in World's constructor, because it's needed for module access checks.

Tables

• NamespaceOwner - maps namespace to its owner's address
• ResourceAccess - maps selector (tableId / system selector) and caller address to access flag
• InstalledModules - maps name and arguments hash (so a module can be installed multiple times) to the module's address
• Systems - maps a system's selector (namespace + name) to its contract addresses and publicAccess flag
• SystemRegistry - reverse maps a system's address to its selector
• SystemHooks - maps a system's selector to an array of table hooks
• ResourceType - maps selector to a Resource enum value. Helps differentiate between systems, tables, etc, because they all share the same resource pool
• FunctionSelectors - maps selector of a function registered on World to its details: function's system namespace, name and selector. The system's function selector can be different from World's function selector.

Systems

Internal systems are in core module's implementations (opens in a new tab) folder, because they're installed by CoreModule.

• AccessManagementSystem - grants/revokes access to/from resources
• EphemeralRecordSystem - has emitEphemeralRecord for ephemeral tables
• ModuleInstallationSystem - installation of (non-root) modules in the World
• StoreRegistrationSystem - its methods should not be used with the World framework. Surfaces the APIs necessary to register Tables on-chain, but lacks namespaces used by World for better permission checks
• WorldRegistrationSystem - surfaces the APIs necessary to register Systems, Tables, and Namespaces on-chain