mathias-hiron commented 1 year ago

The SDK currently provides a low level API on top of which a lot can be built, with some effort.

To make things easier for most devs, key use cases should be supported directly by the SDK using a higher-level API.

One such important use case, is accessing the list of tokens of a given user address in a given FA2 contract, along with their metadata. This would be an API that handles aspects of tzip-12 (FA2), tzip-16 (Contract metadata) and tzip-21 (Rich Metadata).

A very first version of the API would support just enough to interact with the contracts created by the Objkt's minting Factory. Here is an example of such contract: KT1AXCXcYiV1ACc6diBfHq1TVynj8KvqeoUZ

The API would make it possible to:

obtain the list of tokens that a given user owns on such a contract
obtain metadata such as the values the image, tags and attributes from each of these tokens.

Fetching these can be done through tzkt, with a query like this: https://api.tzkt.io/v1/tokens/balances?token.contract=KT1AXCXcYiV1ACc6diBfHq1TVynj8KvqeoUZ&account=tz1ZuhCMnA1gZHfNzgKNFm1B2mjSDKJsQfJN

Performance issues need to be taken into account, to avoid putting unnecessary load on tzkt. In the initial use case, the intent is not for the game to get real time updates on these, but maybe load them at startup or when the user explicitly requests to refresh the data. For real time updates, a system of events would later need to be added.

Support for pagination and filtering / requesting only a subset of the fields could be a good idea to improve performance, but a version without it would already be great.

zamrokk commented 1 year ago

avoid putting unnecessary load on tzkt

Why ? Goal of an indexer is to be enough robust to support any request like Google does

With doing an unique call at startup/caching would decrease workload
I doubt we will have heavy volume right now, btw

Objkt's minting Factory <= so first version would be to mint all NFT manually on Objkt ?

m-kus commented 1 year ago

Custom API makes sense once you need aggregations, custom response models, merging with external feeds, etc. For basic things like querying balances + metadata TzKT is more than enough. Making a separate indexer is extra developing and maintenance costs one would prob want to avoid.

I would also rename this task to high-level api for reading fa2 data, as now it implies that this is something related with preparing/injecting transactions rather than accessing indexed data.

We can do high-level interface that exposes necessary info which is hiding the tzkt usage underneath so that it can optionally be switched to something else if necessary.

Groxan commented 1 year ago

avoid putting unnecessary load on tzkt

Why ? Goal of an indexer is to be enough robust to support any request like Google does

That's not the goal of the indexer. The goal is to provide you with flexible access to the blockchain data. Robustness is an absolutely different thing, that directly depends on the resources you are willing to spend. So, let's be more responsible, because the less efficient code you write, the greater someone's expenses ;)

like Google does

Interesting expectations 😄 Do you realize how much resources Google spends to handle the load?

zamrokk commented 1 year ago

I know, but I suppose that the business plan would be free quota and paid API for heavy consumers once we have enough users of dapps on Tezos, right?

Le ven. 3 mars 2023 à 16:36, Maksim Strebkov @.***> a écrit :

avoid putting unnecessary load on tzkt

Why ? Goal of an indexer is to be enough robust to support any request like Google does

That's not the goal of the indexer. The goal is to provide you with flexible access to the blockchain data. Robustness is an absolutely different thing, that directly depends on the resources you are willing to spend. So, let's be more responsible, because the less efficient code you write, the greater someone's expenses ;)

like Google does

Interesting expectations 😄 Do you realize how much resources Google spends to handle the load?

— Reply to this email directly, view it on GitHub https://github.com/trilitech/tezos-unity-sdk/issues/15#issuecomment-1453711329, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATLHMH2AHNBZVCR3OFFNQ3W2IFYDANCNFSM6AAAAAAVOUH3IY . You are receiving this because you commented.Message ID: @.***>

Groxan commented 1 year ago

Right. Nevertheless, I don't think customers will be happy, paying for actually unnecessary things. Like, for example, paying for 100k requests per day, while it could be 10k, if you spent some time on optimization :)

mathias-hiron commented 1 year ago

Objkt's minting Factory <= so first version would be to mint all NFT manually on Objkt ?

The current plan is to use DNS, as you can provide more information and do batch mint of NFTs

In the future, we could allow minting from the game or from the unity Editor

SamuelAsherRivello commented 1 year ago

Ticket looks great.

I will soon work on a "Tezos SDK For Unity Examples Project" with a few isolated demos. One will be "Does the current authenticated user have this specific NFT?" which I will solve with C# on top of the SDK.

For context, I have 20 years game dev experience, 1.5 year of Web3 experience, and 2 weeks of Tezos experience.

Here are some tangentially related Unity C# API's of (Does user X have asset Y?) from some competitive SDKs. I provide this as inspiration, not necessarily a prescription for a particular solution.

If I can offer a helpful video chat to anyone, please reach out on Tezos Slack. My Tezos Slack profile has my hours of availability.

Enjoy!

Inspiration

Inspirational SDK APIs

ChainSafe - await ERC1155.BalanceOf(contract, account, tokenId);
Loom - await contract.StaticCallAsync<MapEntry>("GetMsg");
ThirdWeb - await blah.getOwned();
Ankr - await _erc721Contract.GetData<BalanceOfMessage, BigInteger>(balanceOfMessage);

More

https://assetstore.unity.com/decentralization

Pseudocode

I have only casual familiarity of the backend complexity of this ticket. For conversations' sake, here is the approach to API shape I have used when solving something similar in non-Tezos SDKs.

The following is pseudocode for one of my own non-Tezos SDKs.

namespace RMC.Core.Samples
{
    public class Example01_SmartContractCallAsync : MonoBehaviour
    {
        private const bool IsLogging = true;

        //  Unity Methods  --------------------------------
        protected async void Start()
        {
            // Init
            await CustomWeb3System.Instance.InitializeAsync();

            // Check Auth
            bool isAuthenticated = CustomWeb3System.Instance.IsAuthenticated;
            if (!isAuthenticated)
            {
                //Stop scene, go auth, come back
                throw new NotAuthenticatedException(this);
            }

            await SmartContractCallRequest1();
        }

        //  Methods ---------------------------------------
        private async UniTask SmartContractCallRequest1()
        {
            ISmartContractCallRequest smartContractCallRequest = new GetGoldPointsRequest();

            ISmartContractCallResponse<int> smartContractCallResponse = 
                await CustomWeb3System.Instance.SmartContractCallAsync<int>(smartContractCallRequest, IsLogging);

            if (smartContractCallResponse.IsError)
            {
                Debug.LogError(smartContractCallResponse.ErrorMessage);
            }
            else
            {
                Debug.Log($"High-Level, getGoldPoints result = {smartContractCallResponse.Result}");
            }
        }
    }
}

TAG

PriorityForSam

m-kus commented 1 year ago

Requires #24 to be merged In the scope of this task ITezosAPI will be extended with additional methods

m-kus commented 1 year ago

Specification (RFC): https://hackmd.io/zaZTTOe1R4uz6HwghUVBaw

trilitech / tezos-unity-sdk

Add a higher-level API for reading data from FA2 contracts #15

Inspiration

Pseudocode

PriorityForSam