Upload

Users upload files to a validator of their choice. This is important as it's the only time that the audio for upload is in "plaintext". The validator will receive the bytes of the upload, either through a direct upload or chunked, and start the transcoding process. Mojave uses FFMPEG to transcode all incoming audio files into FLAC and all incoming image files into PNG. This ensures that there's no data loss for anyone's files but formats are normalized and predictable. Once the local transcoding is complete the validator will compute a CID for the new file and start the encryption process.

An OpenTDF manifest is created alongside a DEK which the file is encrypted with. Then based on the parameters of the uploader the DEK is wrapped and distributed to the appropriate actors. In most cases this will be the validator set of the network and also one for the original uploader. The DEKs for validators are distributed through P2P and can be lazily fetched if validators are offline. The DEK for the original uploader is distributed through the chain itself and lives in the chain's store. This ensures that as long as the network is online the original uploader can always get their content back.

A transaction is submitted to the chain with the new CID and metadata about the file. It gets confirmed by the network and now all validators have visibility into this new file in the form of it's CID. The original uploader now seeds this file over the BitTorrent network and other validators that are required to replicate it download it and start seeding as well. At this point the original validator can cleanup the original file and remove the transcoded copy if they are not required to store it by rendezvous.

Archive nodes will also index the new CID chain events and simply seed the encrypted file over the BitTorrent network alongside the other validators that must via rendezvous.

Upload

Users upload files to a validator of their choice. This is the only time audio or image data exists in plaintext. The validator receives the bytes, either directly or in chunks, and processes the upload locally.

All audio files are transcoded to FLAC and all image files are transcoded to PNG using FFMPEG. This avoids data loss while ensuring formats are normalized and deterministic. Once transcoding is complete, the validator computes a content CID from the plaintext FLAC or PNG bytes. This CID represents the canonical identity of the content.

The validator then generates a DEK and encrypts the normalized file. The encrypted output is addressed by a separate blob CID. The blob CID identifies the encrypted storage object which is the actual file that is being replicated and distributed.

An OpenTDF manifest is created for the encrypted object. The manifest is stored in plaintext in the chain’s PebbleDB state, similar to other public metadata. A hash of the manifest is committed on-chain.

The DEK is wrapped to the public keys of the appropriate recipients. At minimum, the DEK is wrapped to the original uploader’s public key. Only wrapped DEKs are stored. Raw DEKs are never written to chain state. The uploader’s wrapped DEK is stored on-chain so the uploader can always recover their content as long as the network is online.

A transaction is submitted to the chain containing the content CID, blob CID, manifest hash, and associated metadata. Once confirmed, the object is considered registered.

Replication

Encrypted blobs are replicated between validators and archive nodes using BitTorrent. This replication layer is internal to the network and is used only for availability and redundancy. Standard clients and DSPs are not required to interact with BitTorrent, though advanced users may replicate content independently if they choose.

Access

Clients and DSPs access content exclusively over authenticated gRPC / ConnectRPC endpoints. Validators serve encrypted blobs to clients and may lazily retrieve missing blobs from the replication network. Decryption happens client-side. Clients may verify integrity by recomputing the CID of the decrypted plaintext and comparing it to the on-chain content CID. Clients must also request a wrapped DEK from an authorized validator so they can decrypt the content.