[DAO:8b64b85] Linked Wearables Redesign

[dao]

by 0x87956abc4078a0cc3b89b419928b857b8af826ed (Nacho)

Linked Draft Proposal

Linked Wearables Redesign

Summary

Proposed is an enhanced architecture and design for LinkedWearables to address client performance issues caused by low-performing API Resolvers and a simplification process for new third parties, from inception to maintenance of collections

Abstract

After initially considering shutting down Linked Wearables due to performance drawbacks, it has become evident that the functionality is highly valued by the community and has a significant potential for expansion and adoption. However, the current model also presents bureaucratic challenges and can be cumbersome for content creators.

Motivation

To foster greater adoption and streamline the cost and maintenance of LinkedWearables, it is necessary to implement a new process and architecture capable of adapting to the demand while preventing any potential performance issues for the client. This new model can also help improve the user experience when managing LinkedWearables in-world.

Specification

We propose the following changes to the current Linked Wearables implementation:

• Remove the ThirdParties API dependency:
  • Enhance the URN already used for third-party wearables to provide enough information about the NFT item with a Linked Wearable associated.
  • Validate NFT Ownerships on-chain using a RPC Provider and the corresponding Smart Contracts.
  • Creating a new UI on top of the builder to manage Linked Wearable Collections
  • Fetching all Linked Wearables for the backpack using a new service that will feed from the builder.
• Allow third parties to “Pay” directly to the DAO rather than going through a 4M MANA threshold voting process.
• Create a migration plan for existing thirdparties.

External Image

Impacts

Reduced entry costs and complexity for Third-Party Providers:

• Eliminated Resolver API: Third-party providers no longer need to invest in developing, deploying, and maintaining a resolver API to validate LinkedWearables ownership.

New Cost Structure:

• DAO-Covered RPC Calls: The DAO will cover the cost of new RPC calls used to retrieve user-owned NFTs and validate asset ownership in scenarios like profile deployment, node synchronization, and profile sanitization. The cost of the NFT API will be waived from the Foundation to the DAO. For pricing examples, you can refer to the available pricing plans at https://docs.alchemy.com/reference/pricing-plans - the API calls and costs will be capped to avoid unexpected expending.

This new cost will be covered by a new third-party registration process, but it is beyond the scope of this poll. They will be addressed in a subsequent poll to discuss and determine fees and the permissible quantity of allowed published wearables.

Implementation Pathways

Standardized URN: Implement a new URN format that incorporates all necessary segments for performing on-chain ownership validations of the associated NFTs.

urn:decentraland:matic:collections-thirdparty:[3rd-party-NAME]:
[contractAddressChain]:[contractAddress]:[itemId]:[NFTTokenId]

• 3rd-party-NAME: Name of the Third Party
• contractAddressChain: The Chain of the NFT’s smart contracts (Polygon, Ethereum).
• contractAddress: The address of an ERC-721 or ERC-1155 smart contract for the NFT collection that will have associated Decentraland Item.
• itemId: the id of the Decentraland wearable.
• NFTTokenId: the 3rd party NFT tokenId that will have the associated wearable.

LinkedWearables Service: Create a service specifically designed to manage LinkedWearables and its third-party providers. This service will:

• Store Third-Party Information: Securely store data from third-party providers, including smart contract addresses for their collections, chain IDs used, and NFT IDs corresponding to specific Decentraland wearables.
• Retrieve User-Owned LinkedWearables: Upon receiving a user’s wallet address, the service will efficiently return URNs for all LinkedWearables owned by that user. This process involves retrieving the owned NFTs associated with the wallet and cross-referencing them with Decentraland wearables stored in the local database with the information set by the third party.

Decentraland UI: Third-Party Provider Management

• Registration and Management Portal: Implement a dedicated user interface for third-party providers. This interface will allow providers to:
  • Register as a Provider: Complete a streamlined registration process.
  • Collection Management: Manage their collections of LinkedWearables and the mappings between the NFTs and the Decentraland Wearables.
• Data Storage: Information entered by providers during registration and management will be securely stored within the LinkedWearables service.

Catalyst Ownership Validation and Backpack Management:

• LinkedWearables URN use: Leveraging the extended URN format enables Catalyst to perform ownership validation of NFTs associated with the LinkedWearbles. The URNs provide all necessary information for Catalyst to directly call the relevant smart contracts using RPC calls.
• Backpack Endpoint: Introduce a new “backpack endpoint” within Catalyst. Clients can use this endpoint to request all LinkedWearables associated with a specific wallet address. This streamlines backpack management by eliminating the need to filter items provider-by-provider, as is currently required.

Smart Contract Updates

• The existing version of the smart contracts responsible for managing third-party information must undergo an upgrade to enable the registration of new third parties.

Use Case: Update Collection from the Builder
External Image

Use Case: Retrieve All Linked Wearables for Display in the Backpack
External Image

Conclusion

Removing third-party APIs and implementing changes to the URN will ensure all NFT item ownership validation occurs on-chain, enhancing reliability. This model simplifies the onboarding process for new third parties by eliminating API development and maintenance costs. On the other hand, it establishes a mechanism to boost adoption among third parties and facilitates more efficient wearables management within the client interface.

Vote on this proposal on the Decentraland DAO

View this proposal on Snapshot

[HPrivakos]

That proposal is lacking too much information to be a governance proposal.

@dao

• • Fetching all Linked Wearables for the backpack using a new service that will feed from the builder.

So the new service will be hosted by the Foundation?
We are centralizing a previously decentralized process.

@dao

This new cost will be covered by a new third-party registration process, but it is beyond the scope of this poll.

The pricing is quite important when changing the whole linked wearables process. We shouldn’t approve this change with those questions still pending. How much will that cost to the DAO? How much will that bring to the DAO?

This would make yet another part of Decentraland highly reliant on the Foundation, which I don’t think we should be comfortable doing.
Redeploying the service is not even a solution to help with this as they say they will keep some data in database, so redeploying the service will be useless without a dump of the database.

[Nacho]

Hi Kyllian.

The new service will be hosted by the foundation but open source. It will only store a map of chainId:contractAddress:nftId <> Decentraland wearable urn. Doing this on-chain will incur high costs. Forcing third parties to build their APIs is ok for decentralization but is against mass adoption. It is a tradeoff. We tried the first model and generated a lot of friction, bad experiences for users, and communities facing the impossibility of hiring developers to build and maintain an API for them. About data accessibility, for example, we can create a process to create public DB snapshots.

About the NFT API cost, it will depend on the qty of third parties, NFTs and users. There are a lot of NFT APIs out there. We only need to answer the question, “Tell me which NFTs an address has for all of these smart contracts”. It is obvious that the current “registration” process needs to change. Third parties may pay the DAO, and part of that can be used to pay the API. For example, the Alchemy one costs $199 for 1.5 billion requests. We are doing 1M requests nowadays.

[HPrivakos]

Is that something that can be hosted on each catalysts instead of a service hosted by the Foundation? It would incur slightly higher cost for the catalyst owners, but as you said the cost is minimal with the current number of requests.

Another concern I have is that this solution would remove all flexibility that was possible via a custom API. We will only be limited to NFTs on chains supported by Alchemy (even if they support the most common chains already) and we might be limited by the options offered by this Foundation service, example: mapping one nft to one address or “if this address has any of those nft”, but probably not more custom solutions like if this address has between 10 and 20 NFTs from this collection then give access to that linked wearables.
Aaron is trying to do a “Golden ApeCoin NFT Shields to the top 690 ApeCoin Holders.” for example, that’d probably not be possible with that new solution.

Decentraland DAO

Neither would be most of those: Decentraland DAO

[Canessa]

While the technicalities of this are outside of my area of expertise, I FULLY SUPPORT any and all ways to get other NFT projects to Decentraland via Linked Wearables. Maybe we need other options outside of the Linked Wearable program?

I am thoroughly impressed by how easy it is for projects like A Kid Called Beast, Vipe Heroes, Grifters, etc. to go and be their avatar on other platforms in less than 5 minutes. It’s only my opinion, but I think that a metaverse that doesn’t easily support your ability to run around as your avatar is antiquated and will not remain relevant in Web3. So far, 2024 has been the year of the VRM download, we have to make it even easier to come be your avatar in Decentraland.

Devs, do you own any Beasts, Vipes, PudgyPenguins, Apes, etc. and have run around with them on other platforms? If not, please understand this is a huge part of Web3 culture. People are building their entire brands around their VRM’s, and will go wherever they can use them easily.

[AaronLeupp]

1000% this! Decentraland the first metaverse yet the last to do this is completely wild. There a reason why @MakeAnft and I last ones working on the current process and why everyone else left. Less bullying from the payroll trolls and more solutions to support inclusivity and onboarding of all other communities to get Decentraland back to where it should be. The OG and the best metaverse.

[DedHeadJ]

Hi Aaron, you know I support you! I genuinely love my green Fairy pet and ALWAYS wear it. For me you would do much better to resubmit your proposal with some technical guidance. When I read you belittling others it makes me have less confidence in you. I would vote YES on a new proposal as long as the correct information was added, and I do believe the community is behind you.

I wish you all the best!
Jenn

[Nacho]

@HPrivakos

Is that something that can be hosted on each catalysts instead of a service hosted by the Foundation? It would incur slightly higher cost for the catalyst owners, but as you said the cost is minimal with the current number of requests.

Do you mean the map between the NFT and the wearable?
We will need to define a new entity type, but we can evaluate it.

Not-supported chains are a downside of this solution, but I’m curious about how they can bring value to Decentraland. If they are not still supported, chances are that the community is not big enough. Regarding Aaron’s example, yes. We can’t support that case out of the box, but they can create a contract answering the ownerOf call and support it somehow by doing some on-chain operations.

[HPrivakos]

@Nacho

but they can create a contract answering the ownerOf call and support it somehow by doing some on-chain operations.

That’s a time consuming and expensive solution to implement for something which is not an issue with the current implementation.

@Nacho

Not-supported chains are a downside of this solution, but I’m curious about how they can bring value to Decentraland. If they are not still supported, chances are that the community is not big enough.

Bitcoin Ordinals for example are quite popular and not supported by Alchemy, there are a lot of non-EVM chains lately. Avalanche, Blast (used by DG), Bitcoin Ordinals, BNB, Polkadot, Tron, etc… are not supported by Alchemy.
Sure we can used different RPC for each, but if we need 15 RPCs to be able to support 15 different chains, it might not be the best

[Nacho]

That’s a time consuming and expensive solution to implement for something which is not an issue with the current implementation.

Yes, but a possible workaround.

Bitcoin Ordinals for example are quite popular and not supported by Alchemy, there are a lot of non-EVM chains lately. Avalanche, Blast (used by DG), Bitcoin Ordinals, BNB, Polkadot, Tron, etc… are not supported by Alchemy.
Sure we can used different RPC for each, but if we need 15 RPCs to be able to support 15 different chains, it might not be the best

So far, I will see this as a downside if we want a better onboarding and UX. It is hard to have a solution that covers all the use cases that scale and keeps good asset quality and UX.

[DedHeadJ]

I would also like to know why this was deleted. I see nothing in this statement that would warrant a deletion. Who is responsible for removing this and why was this removed?

[AaronLeupp]

Stop removing or hide my reply to @DedHeadJ ! This is censorship!

[dao]

Linked Wearables Redesign

This proposal is now in status: PASSED.

Voting Results:

• Yes 98% 12,505,531 VP (62 votes)
• No 1% 1,463 VP (6 votes)
• Abstain 1% 1,410 VP (2 votes)

[Ozymandias]

@Nacho @HPrivakos
So I know I’m very late here, as I only arrived fairly recently, but I reached out to parties involved and got no answer, so I will express my concerns here.

Why is anyone talking about implementing a database when the database is already there, in the form of the blockchain ?

A PRO subscription to etherscan.io is all that is needed to get the latest state of a NFT (with erc721-token-inventory-by-contract-address).

With a bit more engineering, it is also possible to use the FREE etherscan.io plan, where only the list of NFT transfers is available (with erc721-token-transfer-events-by-address).

[Ozymandias]

The latter does not even require storing information into any kind of cache, which makes it ideal for one-off cloud executions.

Edit: it wasn’t made clear at first so I didn’t realize, but etherscan.io’s free plan only allows for 900 calls per day, so this no-information-storage strategy can’t really work, unfortunately.

For the Waifumon, I call this free API from etherscan.io and simply parse the list of all the transfers which occurred, to identify, for each NFT, which account ends up having it in the end.

With a Javascript Map, this ends up being O(n • log(n)) in the number of NFT transfers, which makes it absolutely negligible compared to the time it takes for the network calls of the API itself.