# Sistema de archivos

Detrás de las diferentes APIs de contenido en el protocolo Decentraland hay una implementación de un sistema de archivos distribuido. Cada servidor de contenido posee una copia del almacenamiento completo y sincroniza las actualizaciones que recibe con otras instancias.

Los archivos subidos al sistema son **inmutables**. Una vez desplegados, ni su identificador ni su contenido cambian. Solo pueden actualizarse en el sentido de que se sube una nueva versión y las aplicaciones eligen usarla, mientras que la anterior puede descartarse.

Puedes experimentar con archivos en la [práctica](https://github.com/decentraland/docs/blob/main/contributor/content/practice/README.md) sección.

### Identificadores de archivos <a href="#identifiers" id="identifiers"></a>

El sistema de archivos de Decentraland está organizado en un índice plano (es decir, no existe una jerarquía natural de directorios), donde cada archivo es identificado por una cadena única.

Las cadenas identificadoras están prefijadas por [codificaciones base32](https://en.wikipedia.org/wiki/Base32) del hash SHA-256 del contenido del archivo, usando el [algoritmo IPFS CID v1](https://docs.ipfs.tech/concepts/content-addressing/) . Se ven así:

```
bafybeicgclohdfaccu2sqqkzrzuenjxzcry3m5vcb4mpxgucjl3oheq5tq
```

El prefijo en los primeros bytes indica la codificación, la versión y el tipo de hash del propio identificador.

{% hint style="info" %}
Por razones históricas, algunas APIs llaman al identificador de archivo *hash* en lugar de *id*, pero se refieren a lo mismo. También puedes encontrar identificadores heredados en contenido antiguo que se ven un poco diferentes.
{% endhint %}

En la práctica, estos detalles no son necesarios para descubrir y descargar contenido. La mayoría de los clientes del protocolo pueden tratar los identificadores como cadenas opacas sin perder funcionalidades.

Toma en cuenta que los identificadores modernos CIDv1 son compatibles con IPFS, dando el mismo CID para el mismo archivo, por lo que IPFS puede usarse como proveedor de archivos.

### Propiedad y persistencia

Excepto por [snapshots](https://github.com/decentraland/docs/blob/main/contributor/content/snapshots/README.md), los archivos almacenados en la red están asociados a una [entity](https://github.com/decentraland/docs/blob/main/contributor/content/entities/README.md) propiedad de una cuenta de Ethereum. El propietario es el único autorizado para actualizar la entity y los archivos relacionados.

El protocolo exige que los servidores de contenido siempre almacenen la última versión de una entity y sus archivos, pero pueden elegir si conservan versiones antiguas según su configuración individual.

### Descargar archivos <a href="#downloading" id="downloading"></a>

El [`/contents/<fileId>`](https://decentraland.github.io/catalyst-api-specs/#tag/Content-Server/operation/getContentFile) el endpoint del servidor de contenido puede usarse para descargar cualquier archivo. Sus identificadores se encuentran en el [manifest](https://github.com/decentraland/docs/blob/main/contributor/content/entities/README.md)de la entity padre.

### Subir archivos

Los archivos no se suben de forma independiente. En su lugar, se empaquetan dentro de entities y se suben durante el despliegue de la entity al servidor de contenido.

Vea la [documentación para creadores de contenido](https://github.com/decentraland/docs/blob/main/creator/README.md) para más detalles.