# Zenodo issue

(Zenodo support suggested that I open a feature request.)
""
**Problem:**
Researchers are increasingly encouraged to use container-based solutions (e.g., Docker) to improve the reproducibility and transparency of results and reusability of research software. Preservation of the environment (image) is increasingly viewed as necessary to ensure longer-term reproducibility than the "recipe" (e.g., Dockerfile). While it is straightforward today to archive and obtain a persistent identifier/DOI for research data and software (code), doing so for container images is challenging. Many research repositories are unwilling to store the images due to their size. As a result, researchers either rely on commercial registries that provide no archival guarantees or, in a few cases, publish exports of container images to Zenodo, which provides a larger quota. However, it seems this approach would lose the benefit of storage efficiencies presented with image layering techniques.

## Describe the solution you'd like
Provide an OCI registry interface to Zenodo specifically for archival versions of images (commercial registries can be used otherwise). We are considering something like this for an upcoming project. The backend could be separate storage or using Zenodo as described below.

## Describe alternatives you've considered
This is potentially possible today. The user can `docker save` the image as a single tarfile but deposit it with the layers extracted. If the underlying storage is an object store, this could prevent duplication of layers. Each layer could be stored only once and the resulting deposited image can still be "loaded" into Docker by recombining into a single tar.

## Additional context
**Assumptions**:
This is strictly for archiving container images associated with research activities accompanying publications.

**Use cases:**
1. A researcher uses a container image to execute a computational workflow to obtain results that are ultimately reported in a peer-review publication. They deposit the container image and obtain a DOI that can be associated with the publication (likely separate from DOIs for data and software).
3. A researcher creates a container image with all dependencies installed to support re-execution and reuse of their research software. The software may be published in a peer-review journal (e.g., JOSS). They deposit the container image and obtain a DOI that can be referenced by their software or publication.
4. A peer-reviewer or independent researcher intends to assess, reproduce, or reuse artifacts from the first two cases. They download and run the associate image.