Replies: 4 comments 18 replies
-
|
I think we can start clarifying some questions, assuming we do the Proof of concept on top of the wearables to leverage all the business flows like curators, collections, marketplace, lambdas, entities in catalysts and subgraphs among other.
|
Beta Was this translation helpful? Give feedback.
-
Is a question to think while designing new stuff, nothing to respond, just to avoid having multiple definitions for same things. |
Beta Was this translation helpful? Give feedback.
-
Could you be a bit more specific on this question? "Active" as equipped at a time? If we just mean active in the backpack for visualization it will depend or the renderer itself, the target platform and such. |
Beta Was this translation helpful? Give feedback.
-
|
@guidota I'd like to propose that you update the initial first posting with the answered questions and with the open questions to prevent having them sparse over the comments |
Beta Was this translation helpful? Give feedback.
-
|
Active => the deployment is part of the last snapshot and is actually referenced by any pointer (users, parcels). It cannot be deleted by the Garbage Collector (if activated). For instance,
Wearables are not limited but we know there are a few thousands. Aprox. amount of entities per type: Understanding how many active deployments are there, we can deduct the disk min or max space usage for the entity type. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the delay, I didnt notice the reply due to being collapsed in the "thread". I'm afraid I cannot answer how many active entities will we have. Maybe it would be helpful to specify a bit more the question to avoid mistake it for how many equipped emotes can somebody have. |
Beta Was this translation helpful? Give feedback.
-
|
@AjimenezDCL friendly reminder for follow up |
Beta Was this translation helpful? Give feedback.
-
|
@guidota would you like to take the chance to do some schema composability/versioning initiative? or may we move forward with an open schema? |
Beta Was this translation helpful? Give feedback.
-
|
Let's start with the open Wearable schema and I will come up with some alternatives, Emotes feature should not be blocked. |
Beta Was this translation helpful? Give feedback.
-
|
On the renderer side reusing the wearables for the emotes doesn't affect us (at least negatively). In fact we can take advantage of the architecture we have for the wearables catalog. To kick-off emotes I dont think we need this discussion to be done but having at least a stub of the wearable schema will prevent us from backtracking too much. |
Beta Was this translation helpful? Give feedback.
-
|
Just for the record a candidate schema for the Emotes M1, is still WIP but the composition would work along these lines. {
"id": "headexplode",
"name": "Head Explode",
"description": "A fitting and engaging description",
"rarity": "epic",
"tags": null,
"emoteV0Data": {
"loop": false
},
"thumbnail": "QmMyThumbnailHash",
"representations": [
{
"bodyShapes": [
"urn:decentraland:off-chain:base-avatars:BaseFemale"
],
"mainFile": "f_head_explode.glb",
"contents": [
{
"file": "f_head_explode.glb",
"hash": "QmMyHashValue"
}
]
}
]
} |
Beta Was this translation helpful? Give feedback.
-
|
For the TP wearables, we have a slightly different schema than for the current one (Wearable). For the TPWearables and the standard Wearables, we compute the hash of the entity, that is, we hash the entity's contents and its metadata to later do the corresponding checks taking into consideration which is the type of wearable. For the TPWearables it will be computed to check that it belongs to a merkle tree and for the Wearables it will be used to check that they're the content hash of an item in the blockchain. The metadata of the entities hashed MUST contain the same properties, that is, we must be sure that what we hash in the dApps side is the same that it's being hashed in the catalyst side. |
Beta Was this translation helpful? Give feedback.
-
|
Wait a sec, there is nothing else than the entity itself to embed any information, other methods would require huge hairy refactors, as the authChain could be. Why was sending the |
Beta Was this translation helpful? Give feedback.
-
|
That's the problem, we have no other information than the entity and authChain in a deployment. As I understand, we need the entire entity to hash and use it on the In case B, I think it would work but not sure if Maybe we can store the |
Beta Was this translation helpful? Give feedback.
-
|
I bet on that approach, case B. We can make it as elegant and scalable as possible. It would be a better way to do ADR32 section 2. For maximum flexibility, it can also be expanded to type MerkleRootCapable = {
merkleInformation?: {
proof: any
index: number
includedFields: string[]
hashedContent: string
}
}
type Wearable = MerkleRootCapable & { ... }
// calculates the merkle root and embeds it into the entity
function calculateMerkleRoot(mut entity: MerkleRootCapable, includedFields: string[])
// validates the hashed content and merkle proof
// 1. using entity.merkleInformation.includedFields, generate object X
// 2. serialize object X (deterministic) in Serialized(X)
// 3. hash(Serialized(X)), compare against entity.merkleInformation.hashedContent for CRC
// 4. validate merkle proof of the hash
function validateMerkleRoot(mut entity: MerkleRootCapable, extra)I'd prevent modifying the authChain at all costs due to exploding complexity |
Beta Was this translation helpful? Give feedback.
-
|
+1 to the idea of adding the |
Beta Was this translation helpful? Give feedback.
-
|
@nachomazzara I think we are confusing the terms here, the entity file is the metadata file. And then the entityId is the CIDv1 of that metadata file |
Beta Was this translation helpful? Give feedback.
-
Description
Adding more and more entities into the catalysts sounds good and the way to go, so we need to make it easy and generic enough to get flexibility.
Emotes are very similar to wearables at first sight, but they can become very complex (sequencing, for instance). Initial implementation would be fine to extend Wearables schema to include some fields like
emoteDataor more representations.Some questions arise among others:
We briefly discussed about designing a framework where we can compose entities and do schema versioning (retro compatibility?), some thoughts would be ideal to move fast (fail fast?) in order to implement Emotes for Fashion Week, but also taking into account this will be preceding other features.
@pentreathm @menduz @AjimenezDCL @olavra
Other entities in mind that can be affected by this discussion will be Third Party items.
Questions
Every time we want to add new entities we need to think in these questions:
Open Questions
(extending invitation to @decentraland/dapps @decentraland/platform)
Beta Was this translation helpful? Give feedback.
All reactions