Why does OCI Image Layout not match the OCI Distribution Spec paths?

[JustinGrote]

https://github.com/opencontainers/image-spec/blob/main/image-layout.md

And related blog:
https://oras.land/blog/lightweight-cloud-registry-oras

For example, there is an index.json, but the OCI distribution spec has no concept of this. If I were to publish an OCI image layout to a static site, the OCI distribution spec is never going to hit the index.json, it's going to look for <name>/tags/list or <name>/manifest/<ref>, and fail. That's what happens in my testing anyways.

So why does this spec not create a static file for tags/list and put the manifests at their appropriate refs rather than a "centralized" index.json?

If the distribution spec was updated to look for an index.json (similar to how the nuget v3 spec works) then it would make sense, but otherwise I don't get it.

[sudo-bmitch]

This has been discussed at opencontainers/distribution-spec#587 (searching for that is nearly impossible).

Both the distribution-spec APIs and creation of the Image Layout predate my involvement, so I can't say why specific decisions were made. However, the OCI distribution-spec was designed on Docker's registry implementation, which even predates OCI.

The OCI Image Layout is not a distribution-spec implementation. However, there are distribution-spec implementations that use the OCI Image Layout as a storage backend, including zot and olareg (disclosure, I'm the author of that).

There's nothing saying you cannot put other content inside of the OCI Image Layout directory structure. What we have is only the minimum requirements. And changing those minimum requirements would break all existing implementations of the spec. If you were to make a static filesystem served by nginx, I think you'll find similar results to the linked discussion, that the Content-Type and similar headers are required for many tools to properly function.

[JustinGrote]

That was my thought, keep the index and use it as a basis to drop out the manifest/etc. and as long as it's read only and the client doesn't freak out if during the pull spec it uses limit for tags but receives a fixed amount of records, should still be doable.

Thanks for the research!