Underlying the different content APIs in the Decentraland protocol is an implementation of a distributed file system. Each content server holds a copy of the entire storage, and synchronizes the updates it receives with other instances.
Files uploaded to the system are immutable. Once deployed, neither their identifier nor their contents change. They can be updated only in the sense that a new version is uploaded and applications choose to use it, while the old one can be discarded.
You can experiment with files in the practice section.
File identifiers #
Decentraland’s file system is organized into a flat index (i.e. there is no natural hierarchy of directories), where each file is identified by a unique string.
The prefix in the first few bytes indicates the encoding, version and hash type of the identifier itself.
In practice, these details are not necessary to discover and download content. Most clients of the protocol can treat identifiers like opaque strings without losing capabilities.
Note that modern CIDv1 identifiers are compatible with IPFS, yielding the same CID for the same file, so IPFS can be used as the file provider.
Ownership and Persistence #
Content servers are required by protocol to always store the latest version of an entity and its files, but may choose whether to retain old versions according to their individual configuration.
Downloading Files #
Uploading Files #
Files are not independently uploaded. Instead, they are packaged inside entities, and uploaded during the deployment of the entity to the content server.
See the content creator documentation for more details.