Best practice for app discovery of shared objects?

General
1

Hi,

I have a general question: what are some of the best ways to discover / look up shared objects?

For example, say I’m developing an app using the [Deepbook contract](h ttps://docs.sui.io/deepbook-design) and I (as the app developer) want to create Pool<..> objects for use by other users of my app (and possibly even of Deepbook).

After I create such Pool<..> s:

  1. It would appear there is no easy way an instance of my app – running, say, on a user’s phone – to discover the objectId s of the created Pool<..> s; my app would have to hard code those objectId s, or perhaps my app would touch a REST endpoint to fetch the latest list of objectID s. Is there a better way? A GraphQL query of all Pool<..> objects now shared that were created by my Move package?

  2. Management of new, retired, in-use Pool<..> s seems cumbersome; have any solutions become popular or even supported by Sui primitives? For example, an AccountCap can be obsoleted – revoked, effectively – just by creating a new one; it’s not clear what approach would be best for new shared objects like Pool<..> s. Any good approaches out there?

As further example, it should be clear why, given a Move function that does:

[...]
        let (pool, pool_owner_cap) = create_pool_with_return_<BaseAsset, QuoteAsset>(
          [...]
        );

        transfer::public_transfer(pool_owner_cap, tx_context::sender(ctx));
        transfer::share_object(pool);
    }

…this python [pysui/suix_GetOwnedObjects](https://docs.sui.io/sui-api-ref#suix_getownedobjects)-using code will fail to discover the Pool<..>:

def find_objects(client, sui_type, address_owner=None, ordered_by_type_version=True):
    find_results = client.get_objects(address=address_owner)  # uses h ttps://docs.sui.io/sui-api-ref#suix_getownedobjects
[...]
3 Likes
2

(Sorry for the broken links but the forum won’t let me include links :confused: )

2 Likes