status of module objects

[MoonShiesty]

i noticed aptos move create-object-and-publish-package is available in the latest aptos cli with documentation in aptos-core. this is a feature im super excited about

what is the status of module objects (can i use in testnet, mainnet)?
are there any examples of how to retrieve a signer_cap for a module object?

[0x-j]

Module object will be shipped as part of Aptos v1.10. It's already live on devnet, and we plan to release it on 03/28 on mainnet.

[gregnazario]

Objects use a different approach from resource accounts.

Resource accounts can only retrieve the signer from the signer capability, where the module objects use a reference based on ownership of the code object.

@JohnChangUK someone's interested in your work and you can give more details :)

[JohnChangUK]

As @0xaptosj said, in devnet already and plans to release to mainnet along with the governance proposal execution, as this feature is gated. Aptos CLI v2.5 will also need to be released as this contains the commands to execute this deployment successfully.

You cannot retrieve the signer_cap as objects don't use this. In the object_code_deployment module, the ManagingRefs keeps reference od the ExtendRef, which is used to generate the object signer.

Upgrades and freezing (making the code immutable) is done via object ownership, i.e. you must be the owner of the code. The retrieving signers and auth mechanism is abstracted away from the user, you simply just call upgrade if you own the code :)

[MoonShiesty]

i want a signer_cap so the module can manage objects it owns. for example: protocol FA stores, transferring NFTs with the module as the creator, see this discussion for an example: #54

or aptos's package manager example: https://github.com/aptos-labs/aptos-core/blob/main/aptos-move/move-examples/package_manager/sources/package_manager.move.

[JohnChangUK]

I see, the recommended way of doing this is to have objects have ownership/control over other objects. We want developers to start using this pattern rather than the SignerCapability, as the latter is more error prone. We refer to this term as composable, as objects own other objects.

Here is an example of how to create an object, which owns collections. The module you define can have access to mint/transfer NFTs and other things: https://github.com/aptos-labs/daily-move/blob/main/snippets/composable-nfts/sources/composable_nfts.move#L85-L92

[MoonShiesty]

i want to be able to create a collection with @deploy_addr (as the module object) as the signer/creator/owner. we could create a second object (ObjectController) but right now we don't need to do that for resource_accounts.

id prefer to see the module directly own objects, rather creating a second object to manage ownership. can you expand on why having the module directly own objects is more prone to errors?

[JohnChangUK]

The problem with resource accounts is that if you forget to store the SignerCapability, then there is no way to generate the signer, and this has caused problems in the past.

And ah, I see what you are saying, you don't want to create another object to manage ownership of objects. We've discussed about having the Object code deployed to an object having exposure to the ExtendRef/signer for the owner to extend this object. This way, you can get the object's signer and have this be the owner of objects. Hope that answers your question :)

[MoonShiesty]

We've discussed about having the Object code deployed to an object having exposure to the ExtendRef/signer for the owner to extend this object. This way, you can get the object's signer and have this be the owner of objects.

+1 on this. this would be our only blocker to picking up module objects