Thanks for the PR! Just to give you a heads up, it's very unlikely this will snuck in into the v3 stable release (no plan on ETA) due to the blast radius of this change. I just want to set the expectations here!

@milosgajdos Completely understand. My main motivation for this was to see if I could implement the API . which if you are interested in a unfinished version is located here

Could I suggest that a way to include the subject functionality before the v3 could be to include it as a experimental feature. Effectively this proposal would add the following to the config yaml

experiments:
   subjects: true

The api and write paths could then both be implemented behind the feature flag providing the ability to incrementally deliver this solution without releasing. Users would be able to enable it at their own risk.

This is obviously your decision to make. I know that projects like harbor implement the subject functionality independently of the registry itself so it might be useful in the future to provide that feature flag regardless.

This change is required to implement the referer API in a consuming application I maintain. Is there a better alternative than waiting or vendoring the code in our application?

Maybe some other OSS implementation provider referrer API implementation but it's not currently planned in upstream. First we want to make a stable release and then discuss what next if anything. There has been no support from CNCF and negligible activity from most of the maintainers, so I would not rely / wait for this

Thanks for the re-base and the work @alistair. I've moved to a role that doesn't deal with the registry much any more. So the chances of me getting this across the line is slim. Anyone else is welcome to pick this up or do it green field.

This is failing CI

CI got stuck somehow, will close and reopen.

@alistair Are you still interested to work on this? It looks like you've been absent from Github for the recent past.

This is failing validation and DCO

Hi @ChristianCiach, @milosgajdos

It might be worthwhile getting an understanding of what state it needs to be in to get it approved and understand the full scope of the work.

Lets see how well my memory is working

1. This PR implements support for handling manifests with subjects and building the appropriate index, essentially the write path.
2. a second draft pr implements the actual index/read api.
3. We need to consider what needs to occur when a user upgrades distribution. Do they need to rebuild the index etc?
4. GC support. Need to consider what this means.

I am also not working much within this space as well. So while I would still be interested in getting what I've done so far across the line I'm also very aware that from a production reliability perspective this isn't something ill be using day to day.

@milosgajdos the validate step fails due to the api documentation changing.

% ./bin/registry-api-descriptor-template ./docs/content/spec/api.md.tmpl > /tmp/api.md
% diff docs/content/spec/api.md /tmp/api.md
1143c1143
<  `MANIFEST_BLOB_UNKNOWN` | blob unknown to registry | This error may be returned when a manifest blob is  unknown to the registry.
---
>  `MANIFEST_BLOB_UNKNOWN` | blob unknown to registry | This error may be returned when a manifest blob is unknown to the registry.
1144a1145
>  `MANIFEST_NOT_ACCEPTABLE` | manifest does not match Accept header | This is returned if the manifest known to the registry has a different mediaType then the client's Accept header.
% echo $?
1