1. Proposed title of this feature request

Make Red Hat Quay a Artifact repository

2. What is the nature and description of the request?

Customers today very much appreciate the capabilities that Red Hat Quay is offering but are unable to adopt the product because it's missing capabilities to store non OCI artifacts. When creating a software supply chain, a central registry that stores all input and intermediate artifacts that make up the software that gets packaged into a container image is a natural place to enforce governance, vulnerability analysis and automated the lifecycle.

Red Hat Quay should provide a way to store and manage non-OCI  artifacts and support artifacts that require their own API and metatada, such as Helm Charts, npm (nodeJS), Maven (java), pypi (Python), conda (OS), cran (R), sbt (Scala), nuget (.NET) or yum/dnf (rpm). It should also have an ability to introduce first class UX for new artifact types like ML/LLM models. It should also be possible to generically store arbitrary binaries or text files without any metadata or specific client support, such that they can be directly downloaded with tools like curl from a predictable URL using either tag names or digest.

3. Why does the customer need this?

Right now, customers are required to run different tools in parallel to manage the different kinds of artifacts, which is cost-intensive, requires lots of resources, and also different knowledge, which is also expensive and difficult to maintain.

Having Red Hat Quay support all possible artifacts would eliminate the need to run multiple tools in parallel and instead offer a single solution that customers can standardize on, reducing the cost of maintenance and complexity.

4. How should this feature be delivered?

Quay should have an extensible plugin framework that introduces new endpoints, which in turn allow to store, index, serve and search (each where applicable and supported by the client) intermediate software artifacts such that existing software package manager clients can work directly with it and are unaware of the fact that it is a Quay registry. Internally, all artifacts and binaries should be stored as OCI artifacts, such that the existing Quay feature set for content management and lifecycle (permissions, pruning, replication, immutability, OCI referrers, etc) are still applicable to them and reachable via the regular Quay API and also OCI distribution spec.

It is expected that this is a ongoing concern within Quay deployment and this feature does not server as the catch-all for implementing the various package managers. Instead this feature asks for the generic plugin framework to be delivered that would allow to implement package/artifact-specific plugins that extend both the Quay API and data model.