> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/contributor/contributor-pt/conteudo/entities.md).

# Entities

Cada peça individual de conteúdo no mundo (como uma scene ou um wearable item) é chamada de uma *Entity*.

Entities são pacotes imutáveis de [files](https://github.com/decentraland/docs/tree/main/contributor/filesystem.md) com um identificador de string único, derivado de forma determinística dos dados contidos, que pode ser usado para descobrir e baixar os files relacionados do content server.

O arquivo principal de uma entity é o *manifest*, um documento JSON que descreve as propriedades gerais da entity, bem como atributos especiais para cada [type](#types). O identificador de uma entity é, na verdade, o [identificador do file](https://github.com/decentraland/docs/tree/main/contributor/filesystem.md#identifiers) deste manifest.

Como são imutáveis, as entities não podem ser atualizadas no sentido tradicional. Em vez disso, são substituídas por novas entities descobertas usando o mesmo estável [pointer](https://github.com/decentraland/docs/tree/main/contributor/pointers.md). A versão mais recente de uma entity é dita estar *ativa*.

Toda entity é assinada por um owner (que está associado a uma conta Ethereum). O owner pode posteriormente usar as mesmas chaves de assinatura para enviar uma nova versão da entity e indicar que ela substitui a antiga. Os content servers validam essas signatures antes de aceitar novas entities, quer elas venham diretamente de um client ou tenham sido encaminhadas por outro server.

Você pode ver entities realmente implantadas na [prática](https://github.com/decentraland/docs/tree/main/contributor/practice.md) .

### Tipos de Entities <a href="#types" id="types"></a>

Existem sete types de entities:

* [**Scenes**](/contributor/contributor-pt/conteudo/tipos-de-entity/scenes.md): espaços virtuais no mundo com seus próprios objetos e comportamento.
* [**Profiles**](/contributor/contributor-pt/conteudo/tipos-de-entity/profiles.md): informações sobre um player específico, como o nome e o avatar.
* [**Wearables**](/contributor/contributor-pt/conteudo/tipos-de-entity/wearables.md): roupas e itens que os players podem adicionar aos seus avatars.
* [**Emotes**](/contributor/contributor-pt/conteudo/tipos-de-entity/emotes.md): animações que o avatar de um player pode executar.
* [**Stores**](/contributor/contributor-pt/conteudo/tipos-de-entity/stores.md): sites de marketplace para wearables e emotes que os players podem comprar.
* [**Outfits**](/contributor/contributor-pt/conteudo/tipos-de-entity/outfits.md): outfits salvos para um player específico.

Todos os types seguem os mesmos procedimentos de criação, identificação, ownership e hosting.

### Propriedades Comuns <a href="#properties" id="properties"></a>

Toda entity possui certas propriedades comuns no seu manifest, aplicáveis a todos os types. Esses campos de nível superior estarão sempre presentes:

| Campo       | Valor                                                                                                                                              |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| `type`      | Um de `scene`, `perfil`, `wearable`, `emote`, `store` ou `outfits`.                                                                                |
| `ponteiros` | Um array de [ponteiros](https://github.com/decentraland/docs/tree/main/contributor/pointers.md) associada a esta entity.                           |
| `timestamp` | O timestamp UTC Unix em que esta entity foi carregada.                                                                                             |
| `content`   | Um array de referências a files adicionais [files](https://github.com/decentraland/docs/tree/main/contributor/filesystem.md) no package da entity. |
| `metadata`  | Um objeto com informações específicas para este type de entity.                                                                                    |

A estrutura e os values do `metadata` campo para cada type são detalhados em suas páginas específicas. O `ponteiros` array também tem contents diferentes dependendo do type.

{% hint style="info" %}
Os manifests de entities antigos podem conter o `version` field, obsoleto em [ADR-45](https://adr.decentraland.org/adr/ADR-45). Você pode ignorá-lo com segurança, já que o `timestamp` field agora é usado para versionamento.
{% endhint %}

Este é um typical JSON manifest descrevendo uma entity:

```json
{
  "type": "wearable",
  "pointers": ["urn:decentraland:matic:collections-v2:0xbdf21eaf54ebf4a6cadc2dcb371df7afce98bc1d:0"],
  "timestamp": 1628181913506,
  "content": [
    // ...file references, see below
  ],
  "metadata": {
    // ...specific fields for this entity type, see the relevant page
  }
}
```

Você pode encontrar os schemas para essas estruturas JSON, juntamente com outros objetos no protocolo Decentraland, no [Common Schemas](https://github.com/decentraland/common-schemas) repositório.

{% hint style="info" %}
Ao examinar manifests de entities, você pode encontrar campos não documentados. Isso ocorre porque o schema da entity permite propriedades personalizadas adicionais, livremente definidas pelo owner.
{% endhint %}

### Files <a href="#files" id="files"></a>

Como mencionado acima, todas as entities têm pelo menos um file associado: o JSON manifest que descreve a própria entity. O identificador da entity é, na verdade, o [identificador do file](https://github.com/decentraland/docs/tree/main/contributor/filesystem.md#identifiers) deste special file.

O `content` O field dentro de cada manifest é um array de referências a files adicionais. Normalmente, estes são assets, como modelos 3D e animações, ou scripts para scenes.

Todos os files são armazenados no [sistema de arquivos distribuído](https://github.com/decentraland/docs/tree/main/contributor/filesystem.md), e cada item no array tem duas propriedades:

| Campo  | Valor                                                                                                                                                |
| ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| `file` | O nome interno usado pelos files nesta entity para se referenciarem uns aos outros.                                                                  |
| `hash` | O [identificador global deste file](https://github.com/decentraland/docs/tree/main/contributor/filesystem.md#identifiers), único em todo o conteúdo. |

É assim que normalmente fica dentro do `content` field:

```json
[
  {
    "file": "thumbnail.png",
    "hash": "bafkreiglecvpnqibvf6pltcnid5nhbx3caj77lu4ia4xitpmp3lrcouuhm",
  },
  {
    "file": "model.glb",
    "hash": "bafkreic2i3awiu7srhatf3k47l3c5lmadisznjigppor2a35saosjfbo25",
  },
  // ...more files
]
```

{% hint style="info" %}
O `file` o valor do field está sempre em minúsculas, para evitar problemas ao construir entities em diferentes sistemas operacionais, onde a capitalização do nome do file pode ser importante.
{% endhint %}

A vida útil de um file está ligada à entity que o contém. Para entities ativas (isto é, ainda não substituídas pelo owner), os content servers são obrigados pelo protocolo a preservar todos os files associados. Se a entity for deletada, os files podem ser mantidos ou descartados a critério do server.

### Propriedade e Autenticação <a href="#ownership" id="ownership"></a>

Para provar ownership e autorizar ações em torno de entities, o [serializada em JSON](https://github.com/decentraland/docs/tree/main/auth/authchain.md) mecanismo é usado.

O [`decentraland-crypto`](https://github.com/decentraland/decentraland-crypto) repository contém a implementação de todos os procedimentos criptográficos.

### Descobrindo e Baixando Entities

Os content servers podem ser usados para localizar entities usando [ponteiros](https://github.com/decentraland/docs/tree/main/contributor/pointers.md), e para baixar seus manifests e quaisquer files adicionais.

* Para resolver um pointer em um entity ID, você pode usar o [`/entities/active`](https://decentraland.github.io/catalyst-api-specs/#tag/Content-Server/operation/getListOfEntities) endpoint.
* Usando o entity ID, você pode baixar o manifest com o [`/contents/<id>`](https://decentraland.github.io/catalyst-api-specs/#tag/Content-Server/operation/getContentFile) endpoint.
* Para obter todas as entities ativas de um certo type, comece baixando um [snapshot](https://github.com/decentraland/docs/tree/main/contributor/snapshots.md).

Confira a [prática](https://github.com/decentraland/docs/tree/main/contributor/practice.md) seção para exemplos e guias.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/contributor/contributor-pt/conteudo/entities.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.