Problems with Standards Integrations with JS SDK

[BenKurrek]

I wanted to discuss how standards would come into play with the JS SDK. Generally, it is expected that the methods outlined within the standards (i.e nft_transfer, ft_transfer_call, nft_supply_for_owner etc..) are implemented on the contract itself.

This is made apparent in nomicon sections that state, for example, "Contracts which want to make use of nft_transfer_call must implement the following:" or "The contract must implement the following view methods:" etc...

Let's look at a common scenario to see why this is a problem. Let's say you have a dApp that wants to list all NFT contracts and allow users to paginate through NFTs for any given contract similar to SecondX. The dApp will keep a list of NFT contracts and then paginate using nft_tokens by calling the contract directly. If there's a JS contract in there, this will not work since in order to call the JS contract, you need to go through the enclave jsvm.testnet first and the way you call these methods is different since you need to base64 encode the arguments unlike how you would interact with conventional smart contracts.

I'm honestly not even sure how you would integrate the events standard since the jsvm contract will be emitting all those events. Say you had 100 different NFT contracts all written in JS that all were all deployed to the same jsvm.testnet account. If all of them have events being fired, the indexers will think that all the NFTs belong to the jsvm.testnet account and it won't be able to associate which NFTs come from which contracts. All the NFTs will get mixed up and you might also run into the case where there's duplicate token IDs.

I also wanted to mention the idea of the storage management standard since users will all be sharing the same root jsvm.testnet account and have their contracts live there. How will $NEAR payouts be handled if you're using a JS contract? Does everybody have access to the funds stored on the jsvm.testnet account or is it segregated and a specific usable amount is allocated to each contract that gets populated whenever someone transfers funds and is interacting with that specific contract?

Please let me know your thoughts on these issues as I think they're extremely important to consider.

[frol]

TL;DR: Aurora EVM has the same problem, and it is just an isolated environment without native connection to the rest of NEAR ecosystem

I feel JS enclave will need some sort of bridging since call 'nft_transfer' on jsvm.testnet won't work as it needs some internal account ID to know where to route the function call in the first place. I haven't been actively following near-sdk-js development, but unless there is a plan to have a bundler that will deploy a single JS bundle with VM into Wasm file and deploy it as a single contract, we will have quite isolated environment similar to EVM on Aurora, which can only be bridged with the native NEAR world.

P.S. Thinking a bit more about it, I feel there will be a need in having a standard defining how to wrap the function calls for JS enclave, so nft_transfer and other interfaces could remain compatible on the standards level, though it will add a bit of a hassle on the tooling side just like multisig added (you cannot send a function-call anymore, you need to wrap it into add_request and send the transaction to the owner account)

[BenKurrek]

Even if JS is its own isolated environment similar to EVM, there's still a bunch of problems and we have to think very carefully about them before release. One such problem is with events because the indexer won't know which NFTs belong to which "contract."

[austinabell]

Perhaps using multi-token standard will be a consideration for supporting this for enclaves, with some mapping of token ids to the addresses of the tokens on the contract?

Aside from that, unclear how this can be done for enclaves since there is no way to distinguish which token balance is viewed through something like ft_balance_of unless the implementation on jsvm has an additional field on top of the standard for additional metadata like address?

For interacting with the contract, you could deploy a wrapper ft or nft contract that just routes transfers through jsvm, but this will come at probably unreasonable costs for the cross-contract call and also you wouldn't have access to the view calls (since cross-contract)

[austinabell]

Well, it's not fine because it has a different interface than the standard (making the standard irrelevant in this case).

Obviously alternative would be to have a separate standard for enclaves and just have first-class support within tooling, but that's a non-trivial ask of engineering resources across teams

[BenKurrek]

Ah yea I was more-so saying it was fine outside of the whole interface being different. If the interface was the same, it would be fine, but events and (maybe?) deposits are a little worse off.

Completely agree though.

[austinabell]

Well, yes and no, because the parameters are part of the interface, not just the function names. Certain tools like marketplaces trying to include (N)FTs on enclaves won't work unless hard-coded the different interfaces depending on which contracts are being called.

I suppose you're suggesting that at least if the inner parameters are equivalent, marketplaces or other contracts that use it would just have to add support to wrap specific parameters with the jsvm interface wrapping format?

[BenKurrek]

Yes exactly. This is not great UX, though, since there would need to be conditional logic based on whether you're interacting with a JS contract or a native contract. It is, however, doable.

Events on the other hand will just break entirely...

[austinabell]

maybe there should be a meta-standard for enclaves so that the format is consistent across these contracts so that it doesn't have to be hard-coded for each type of contract