ADR-138: Technical Assessment for the new Backpack V2

Need

This is a technical proposal for the needs described here: PRD: Backpack V2

The intention of this document is:

• Identifying which teams will be involved and what responsibilities they’ll cover.
• Dividing the new functionality in smaller tasks that will be estimated accordingly in order to create a development roadmap.
• Finding possible corner cases in order to preemptively identify and solve them.
• Reaching a consensus between different affected teams in terms of defining the different functionalities and flows.

Involved teams

This initiative will require a cross team effort that will include the following teams:

• Explorer: for the UI, UI functionalities and integration with the back-end side.
• Platform: for the modification of the already existing lambdas endpoints in order to make them compatible with the new requirements (sorting wearables by different criteria, filtering them by different criteria, etc.) and the creation of new ones required.
• dServices: for managing the new way of saving the equipped wearables and outfits from the new Backpack.

Back-end dependencies

We currently have several lambdas endpoints (compatible with pagination) that are already being used by the current version of the Backpack to retrieve the information about the wearables. These endpoints are:

• Base Wearables: /lambdas/collections/wearables?collectionId=urn:decentraland:off-chain:base-avatars
• Owned Wearables: /lambdas/users/:userId/wearables?includeDefinitions=true
• Owned Emotes: /lambdas/users/:userId/emotes?includeDefinitions=true
• Third Party Wearables by collection: /lambdas/users/:userId/third-party-wearables/:collectionId&includeDefinitions=true

We're going to need to modify some of these endpoints in order to make them compatible with the new requirements. The following is a description of each one of the new requirements and how they will affect the current endpoints:

Possibility of including the collection id in the owned wearables lambdas

In order to give the user the possibility of seeing and manage any type of wearables, base, owned, third party together in the backpack, we will be able to include them as part of the result returned by the owned wearables endpoint instead of having to request them separately.

In order to be able to do it, we will need to add a new parameter to the existing Owned Wearables endpoint that will be used to specify the collection ids, either Decentraland, 'urn:decentraland:off-chain:base-avatars' or any third party collection, and return the list of wearables that match with that collections. The new parameter will be called collectionId and will be a string that will accept any value. We should be able to specify more than one collection id separated by commas.

Endpoints affected:

• Owned Wearables: /lambdas/users/:userId/wearables?includeDefinitions=true&collectionId=:collectionId1,:collectionId2...

Possibility of including the collection id in the owned emotes lambdas

In order to give the user the possibility of seeing and manage any type of emotes, base, owned, together in the backpack, we will be able to include them as part of the result returned by the owned emotes endpoint instead of having to request them separately.

In order to be able to do it, we will need to add a new parameter to the existing Owned Emotes endpoint that will be used to specify the collection ids, either Decentraland or base, and return the list of emotes that match with that collections. The new parameter will be called collectionId and will be a string that will accept any value. We should be able to specify more than one collection id separated by commas.

Endpoints affected:

• Owned Emotes: /lambdas/users/:userId/emotes?includeDefinitions=true&collectionId=:collectionId1,:collectionId2...

Filter wearables/emotes by text

The user will be able to filter the wearables/emotes by text.

In order to be able to do it, we will need to add a new parameter to the existing endpoints that will be used to specify a text and return the list of wearables that match with that text. The new parameter will be called textFilter and will be a string that will accept any value.

Endpoints affected:

• Owned Wearables: /lambdas/users/:userId/wearables?includeDefinitions=true&textFilter=:anyText
• Owned Emotes: /lambdas/users/:userId/emotes?includeDefinitions=true&textFilter=:anyText

Filter wearables by category

The user will be able to filter the wearables by category.

In order to be able to do it, we will need to add a new parameter to some of the existing endpoints that will be used to specify the category and return the list of wearables that match with that category. The new parameter will be called category and will be a string that will accept any value.

Endpoints affected:

• Owned Wearables: /lambdas/users/:userId/wearables?includeDefinitions=true&category=:categoryText

Sort wearables/emotes

The user will be able to sort the wearables/emotes by different criteria: newest/oldest, rarest/less rare or name A-Z/name Z-A.

In order to be able to do it, we will need to add a new parameter to the existing endpoints that will be used to specify the sorting criteria. The new parameter will be called sort and will be a string that will accept the following values:

• newest (this should be the default sorting criteria)
• oldest
• rarest
• less_rare
• name_a_z
• name_z_a

Endpoints affected:

• Owned Wearables: /lambdas/users/:userId/wearables?includeDefinitions=true&sort=:sortingCriteria
• Owned Emotes: /lambdas/users/:userId/emotes?includeDefinitions=true&sort=:sortingCriteria

Get wearable market details (NEW ENDPOINT)

The user will be able to click on a wearable and open a modal with some details as:

• Creator (optional): Name and image of the creator of the wearable.
• Collection (optional): Name and image of the collection where the wearable belongs to.
• Network: Network where the wearable is deployed.
• Contract address: Address of the contract where the wearable is deployed.
• Latest sales: List of the latest sales of the wearable. It would be a list of the following information:
  • From: Name and image of the seller.
  • To: Name and image of the buyer.
  • Type: Type of the transaction (Transfered or Minted).
  • When: Date of the transaction.
  • Price: Price of the transaction.
• Minting number and total scarcity (optional): Minted number + total amount of NFTs of this wearable.

In order to be able to do it, we will need to create a new endpoint that will return the details of a specific wearable:

• Wearable details: /lambdas/wearables/:wearableId/market-details

Get a random list of equipped wearables (NEW ENDPOINT)

The user will be able to click on a [RANDOMIZE] button and equip a random list of wearables on his avatar.

In order to be able to do it, we will need to create a new endpoint that will return a random list of wearable ids from the owned wearables of the user. The wearables must be from each category, avoiding conflicts with hides and replaces whenever possible.

• Random list of wearables: /lambdas/users/:userId/random-wearables

Outfits

The outfit information should be stored in the catalyst because we need to support multi-platform.

On the other hand, we should avoid storing it in profiles since it is information that only each individual user needs and does not need to be shared with other users. Adding it to the profiles would add an additional data transfer for each request unnecessarily.

We need to discuss as a team what is the best approach.

Regarding to the outfit image previews, they can be generated in the client when saving the outfit. There is no need to store the images in the catalysts.

We may encounter the need of checking that the wearables in the outfit are valid for the current user. (What happens if the user does not have the wearable anymore?)

Equip/save wearables

We though about several alternatives to avoid performance issues by saving the profile every time you equip an item:

1. Equip all the items and only when the backpack is closed, make the request to save the profile.
2. The profile will be updated/saved in intervals of 20 seconds (to be defined) or whenever the user closes the backpack.
3. Save the profile when the user equips a wearable.

Saving the profile would mean that the nearby users will be able to see the changes as soon as possible. We should discuss what would be the best option taking in consideration the user experience and performance.

Emotes pagination

We will need to refactor the current emotes catalog, the same way on how we did on wearables catalog, so its supports pagination. We will also reduce kernel responsibilities, moving all (or most) of the emote handling in the renderer. No need backend support. Open ticket: #4429

BackpackEditorV2

In Unity we are going to implement a new UI for the backpack v2 requirements, including all the components needed.

We will keep retro-compatibility with the old one, including the UI, service calls and dependencies.

License