Do we always prefer to publish package to object over account?

[0x-j]

Discord user ID

No response

Describe your question in detail.

Now that publishing package to object (AIP) is live on mainnet for a while, should we always encourage people to use it over account?

I can't think of much downside, except the ownership check needs to consider object owner, see an example

What error, if any, are you getting?

No response

What have you tried or looked at? Or how can we reproduce the error?

N/A

Which operating system are you using?

macOS

Which SDK or tool are you using? (if any)

TypeScript SDK

Describe your environment or tooling in detail

No response

[JohnChangUK]

It is the preferred and defacto standard for publishing code. When user’s publish modules to accounts, there are some drawbacks.

1. Publish directly to the user’s address on chain.
   1. If the user needs to make incompatible changes, they need to publish to a different account to avoid naming conflicts.
   2. The account has full control over upgrading the code and cannot give this permission away, e.g. to a governance entity. This limits programmatic control, flexibility and decentralization of protocols.
2. Publish modules to a resource account created.
   1. This method requires developers to generate different seeds each time a unique resource account is generated.
   2. Hard to use upgrade process. Upgrade permission is controlled via the resource account's SignerCapability which is confusing to claim and use to upgrade code.
   3. An additional Account resource is created every time a resource account is created, creating a lot of unnecessary bloat on chain.

Using objects allow transferring ownership of code, as well as programatically defining rules such as governance for upgrading etc.

[MoonShiesty]

I have a different perspective. We found the drawbacks to code objects were too large to move away from ResourceAccounts.

The drawback to code objects is that a code object can't retrieve its SignerCap/ extend_ref, while ResourceAccounts can using retrieve_resource_account_cap. This means code objects can't directly own or transfer other objects, such FungibleStore or Token. As a result, code object need to indirectly manage "owned" objects through a second object or resource account that has access to its extend_ref.

For example, we mint tokens with the ResourceAccount containing the package as the creator, then directly transfer those tokens to the signer who paid minted them. A code object would need to create a second "minter" object, that is the creator of the token and then transfer newly minted tokens from the indirect object to the user. The solution using an indirect mint adds complexity and compute, displays poorly on the explorer, and makes indexing more difficult.

I really like how easy it is to upgrade to code objects. But for us, the advantages we get from code objects, aren't worth the additional complexity required to manage all the objects that code owns.

[JohnChangUK]

Thanks for the valuable feedback! If we were to expose the signer of the code object, this would address the issue right? And it would only be exposed if you are the owner of the code object.

[MoonShiesty]

we were to expose the signer of the code object, this would address the issue right?

yes

And it would only be exposed if you are the owner of the code object.

if we went with this approach, we would still need to create a resource account which owns all our code objects; we have many actions where a user is the signer, and the module needs an extend_ref to withdraw from its FungibleStores or transfer minted tokens to the signer of our mint function.

id prefer an approach where code objects can have "self-ownership" and can retrieve and store a SignerRef in init_module, similar to ResourceAccount. i think makes a lot of sense for protocols which use governance: self-governed protocols shouldn't depend on a second account/object to sign on their behalf

[0xwml]

Wanted to +1 @MoonShiesty's preferred approach. Storing a SignerRef would simplify things on our end - specifically enabling simpler implementation for things like creating named sub-objects (as the object interface does not enable named object creation without a signer ref).