 Good morning folks. Let's see here. Dustin. Hi. Let's see here. A little chat column agenda. And I seem to have way too many windows open already. But I guess that's what hibernate does for you. Hey, Derek. Okay. I'm just pulling up the latest. So give me a second here. Okay. Move the cheese. Okay. So. We'll give a minute for folks, but basically. Just trying to make some progress on the workflows so that we can. Get back to testing the notary clients. Hey, Omar. Oh my God. Yeah. Yeah. I'm just trying to make some progress. I'm just trying to make some progress so that we can see you. And that is your new place with a very cool sliding barn door. Ha. It's correct. And it hasn't fallen down yet. So this is good. That's a, that's good. I guess you put it up yourself. Is that what the lack of endorsement there? Correct. Yeah. I've done some myself that is quite the challenge to. Yeah. Yeah. Yeah. Right. I'm just rambling. I was giving a couple of more minutes, but. So, okay. All right. So if you remember, if I get the workflow that we're trying to. Be too. As we're trying to get this experience kind of sketched out. So we can make sure that. We can make sure that we don't get too much of a glow going on. So we can get the end end workflow. So if we can get that sketch, we can see like, all right, does, do we like this experience? Like it's the, you know, putting a little bit of sample paint on the wall before we tape and mask and paint every wall across the house. Like, do we like this experience with the spotter of paint? So we're, we've got some basic signatures. Like if you look, you know, kind of, well, that's the most important thing in the process. So that we could be able to work with. And, you know, we can, I know how to generate, for a container image with manifests. We've been trying to figure out, okay, if we have that, and we know we could sign and verify something. Can we get an in and out of a registry so that we can promote it across two registries. And then use a policy manager like Opa. Which of course means it needs to be able to pull something from a registry and validate and so forth. We know just for complete clarity, we know the key management is a complete black hole right now. You know, I've been making some progress on that and we will fold that in. So there is an assumption that keys magically wind up on users machines. And we need to figure out the whole key management revocation all the pieces that relate to that so we're kind of just ignoring that one for the now for the meantime. We're ignoring it we're keeping it in a parallel effort and we'll come back to it. So with that's the case, the thing that we've been discussing is how do we persist signatures, how do we discover a signature and based on discovery what is this persistence metadata. Like pulling a signature is pretty straightforward because we're just trees and artifact. So just like you can pull any other artifact you can pull a signature object. And then overalls been doing some stuff on like a reference implementation with distribution. And then there's this prototype which you'll see is exactly why we need to work with some other clients because this is splitting atoms. Okay, which some will find cool because splitting arms is cool. So the, if you remember all this. So two things actually, where did I put this alright so over the weekend. Well that's unfortunate. Oh I see what happened. Okay, hold on. So over the weekend. I moved the discussion we had around different options for persistence. So if you remember we talked about a manifest index or a manifest link through index. There was a couple of discussions and how we decided what we want to consider. It turns out we had both the options and the current implementation in the same read me file. So it kind of really made it confusing for those of us that are directly involved much less anybody else looking. So we've split this out. Now in the docs distribution for envy to there's this persistent discovery options, which talks about what we've done. And then the root read me distribution read me will have whatever we're currently thinking about. And remember we've got this under this prototype one branch, you know, assuming reverses and so that's kind of just a little bit of stability of what we're trying to show here's the thoughts. And here's what we're currently using as the model. So with that of the three options, we've been sent doing around. If I have the net monitor container image. And in this case, it's, it's a matter of you'll see the 111 and just says it's a manifest. I'm ignoring the platform for the simplicity of this conversation. So I've got the image and I'm going to push an index that has a config object that has the signature in the content of the signature content of the config object. So in this case, if you remember the workflow, we've got, it comes from rabbit networks, because they're the ones provide authoring the software. I'm skipping the signature and Docker hub just for simplicity and eventually it winds up in Acme rockets, and they're going to sign it before they deploy it. So here's the web of networks. It eventually gets into the Acme rockets registry and Acme projects rocket signs that content. So that's the persistence model. And for those that are more text versus visual, I've put all the samples in here. So here's just a manifest for the net monitor image. And then here's the rabbit network signature. Notice it's an image index. I, we should talk about the version in here so long to make a note to come back and talk about that. The big media type says, Hey, this is a notary v to JWT, and it's signing the rabbit networks image. So those two match, right? That's that thing and nothing. And then there is the additional one. Oh, and then this is the signature itself in the config object. And the Acme rockets version is duplicated. So we talked about the pros and cons just to and then the expansion of that if you do use a multi arc index, how would the signatures look for that. So if you have your windows, notice the W for W manifest and then the Linux manifest. These are two individual manifest that are referenced by multi arc index. You could have both the Acme rockets and web of signatures on the multi arc index. And you could also have both of those on both the windows and Linux architecture specific manifests. And so far, just close the door here. Is that just going to raise kind of caught up in the recap of where we're at. So I don't quite understand what the different. So these are all the different nine different artifacts here are nine different Jason blobs. These are nine different artifacts. These are two to these three of the things we know and love today that are already out there right it's a windows and a Linux manifest that represent the net monitor software, and that's a multi arc index. These two, and these four are signatures on those. So these are the new things. Okay, so there's a, the OCI index pointing at another OCI index in this case. And OCI links can point at a manifest, which is what it's doing here, or an OCI next can point to another OCI index. Yes. Okay, yeah, I was just trying to understand what's going on here. Okay. No, it was a great question somebody asked this so I added this to make sure it scaled. So we're finding interesting holes in the spec that don't actually seem to refer much to indexes or even manifest referencing there's a bunch of implications there which has been interesting to surface, which you'll see the talk about it right here, but it just a level set so we have basically this. And this are the same thing just expanded to show a multi arc scenario. So then, if we've got these things persisted, and we're following with the model that a deployment makes a reference to a tag or a digest. And we want to be able to not, we don't want to force people to change that in their kube deploy compose, tell them whatever. But the environment will say well I'm only going to allow deployment if x company has signed that content. The idea is that I know the thing I'm trying to deploy I don't know what the signature is. So can I get the signature objects for the thing that is being referenced. And that's that's kind of what we're for focusing on here. So the idea is I need to be able to say for a given digest the net monitor software, can I find out what signatures supported. Now, we've been having this healthy conversation around do I have to make any changes to distribution to support signatures, like, well, that's a reasonable question. I believe that the implication of notary v one was a really heavy weight solution that required people to implement to support signatures, but we don't see a way to have no impact on registries to support signatures. So we're trying to balance that with what we think is the most reasonable. Other questions came up of, why are we special casing signatures. Should we just implement a pattern that can work for any artifact type. So that's the thought process that we have at this point is a thing can reference other things. It's actually seen it's actually somewhat interesting to say hey given a particular manifest, what indexes are pointing at it, like that would actually be kind of helpful. And of course there's other scenarios like seen abs and others that will use indexes and I hadn't thought all the way through how an S bomb might be referencing other things as well so there's probably a number of good use cases that will come up where we need to get this reverse lookup model. So the proposal basically is, you know, for an artifact for repo, the manifests, and this is kind of the standard thing is there's this new API that says refer metadata. Lots of conversations on naming, but let's go with the concept for a second and we can have lots of fun debates on the name. So if we use this diagram above here. If I know this is what I'm trying to deploy. I don't care whether you just the windows or Linux and notice it did at least get the two right. What are what are the signatures that are available for this. So the idea is you make a request for that digest. And of course there's the tag to digest, you know, calculation that's already done. And we would get a result back of descriptors plus and the plus is the other interesting conversation. So this just, you know, duplicates this just says hey this is the thing you asked for which looks like I actually did that get the copy paste right this time. And here's the descriptors that come back. Interesting problem is because the way we're trying to the way OC artifacts works is we're really just leveraging the scheme to scheme is that registries already know how to persist a manifest which has a collection of layers, and an index that is a collection of manifest or other indexes. So this doesn't change those two schemas in a registry. All we do is say the collection of layers or blobs that you're persisting could be something else, and we want to know that they are something else. So if you look at that you realize that on a descriptor, the three elements will always come back as index or manifest. And if I get a collection back that says here's all the digest, here's all the things that reference the net monitor image. I don't know whether I'm going to go through this list and have to find out, I have to pull it first to find out oh this thing's actually a signature versus, you know, the other thing I actually care about or in this case. I want to get just the signatures. And I don't really care that there's happens to be a multi arc index pointing at this thing. I really just want the signatures. So what you're seeing a start to tease in, and I'm not overly thrilled with it but I'm putting it in there for discussion is we return the artifact type, which is the config media type. I noticed now I can say, oh, of the things that I just found for this thing. Here are their two signature objects. I still don't know which is the web at networks and which is the net monitor. Acre Rockets one, but at least I know it's these two and I could ignore this one. I'm going to pause there for a minute. So this is basically just a filter out the refers that might have a signature. Correct. Well, in this case filter in because I want I really was actually two parts there's actually was in fact the current prototype might have it a way to specify the media type on this request that says only give me certain ones. The problem is this is not something you put a URL so it has to be encoded is it do we want to put it in the header. So, and the whole question of filtering always raises a lot of questions. So for now we're just saying let's start with refer metadata API that brings back anything that was referencing that object. And then the client, whatever the client is would say, I care about these two. Let me go fetch this object, then this object, and decide what I want to do with it and this object, because it's this type, I'm not even going to fetch because I'm not interested. So it's still two hops though, or two more round trips to get the to get at the signature for your quest total because there's to the refers and then you have to ask for the index and then you have to ask for the signature. So let's let's say we have a tag, because that's what you know we kind of want to say is the best practice for deployment use unique tags for deployment. So then I take from the tag I have to go get the digest. And then from the digest, I can go get this refer, and I lost track of many. So I started the tag, I get the digest. So I make a request for a tag to get a digest that's one. Then get the refers. And now I've got this list so that's two. So now I have to ask the two additional ones in this case so that's four, right, because I'm making a request for these two. And there's another hop in there which I'm going to work for a moment to figure out that I actually only care about the Acme rocket signature, because I only allow deployments to be done if Acme rockets is on that object. So that's five. What's what what we save though is I didn't have to go fetch this just to find out I don't care. Yeah, so I mean I agree with the with the data model being proposed here just trying to figure out. How to optimize this because in some cases like yeah you're saving something but if you're going to have it in a specific endpoint that trying to optimize then it should actually be optimal not just like save one extra hop out of like make it save off like 25% of the hops or something. Yeah, there is you're going to see there's an interesting config versus manifest reference that comes up as well in this discussion and we're definitely trying to figure out what's the balance between purity, and which is very generic use for lots of things but maybe it's going to be performant impactful that's not interesting versus they, you know, where's the right balance. So I, we're definitely struggling with that conversation. Yeah, I've come I've come in here late because I think the last time I joined the meeting. Yeah, a lot about the data model and I think the data models right in the way that it's referring to now I think it looks, looks good. This stuff you're thinking. Yep. Okay, cool. And Sam's been asking some really good questions it's work making us kind of test that. And I feel the questions they're being asked are keeping us in the right center. What, what kind of questions. And Sam remind me that what I know you're asking around the, oh, you're asking about adding to a layer to manifest or something. One of the big questions that I had was, why do we really need a new config field in the index. And are we able to leverage the existing manifests array. Instead, with just a separate media type for the reference that's controlling where the signatures is talking about the, the thing that it is signing. So if we, is it this one? Yeah. Persistence. So if we look at this one, what I think, Sam, keep me honest, I think this is what you're asking. If I have the net monitor image, what I would have is an OCI index that is the collection. And this is the rabbit signature, but instead of storing it in the config object, I actually store the signature as another artifact over as a manifest, which has a layer that actually the layer that's the signature. It doesn't actually have to be a manifest object. You could use the manifest field in the index to refer to it have a descriptor for pretty much whatever. I'm just pointing directly to a signature object in there. The question was just, do we really need to introduce a new config field into the index or not. So I try, I think in here, I went through that try to give some conversation. Not new changes. So discussion, discussion. Okay, I'm getting. So it's in that, in that poor quest. It's like one comment above the one still expanded. It's the one that's, yeah, that one. Okay. So if you look at the example here, I have, I put it so that there's two things in the list of manifests in that manifest array in the index, one of which is the manifest of the signed image and the other one is the same thing that you had had in the config field. Just moved it down into the manifest. And that was the question, do we really need to introduce and do config field into the index or not. So the question that this kind of teases that so this I might have wrapped up multiple times we were trying to first do this because there's multiple ways we refer to schemas and manifest. This media type is on the two schemas that we currently support the registries currently support image manifest image index. So this is saying is, it's not the config media type but we're actually going to say, registries will actually support yet another schema, which might be the same schema, because this isn't the I think this is, I think I'm not understanding you and you're not understanding me. Okay. So, in the example that you have in the doc. You have this exact same media type with that same digest and size, but instead of being in the list of manifests, you have it in a new field called config. Right. And that's all of what my question is, why do we need a new field called config versus moving that into the list of manifests right here. Fair, fair. So, I hear you, I think I hear you, but let me try to echo back what where what where I'm seeing it. First the index to have a config. Also, whether there's a storage in the configure not helps us understand the signal the index is of type signature. So that's the first part. The second one, which is actually the more important one is a list of manifests technically only supports today, two different media types. The image manifest and the index manifest or image index or image index and image manifest. And those represent schemas for how an object has collections. If this here would to have it here as a descriptor. If I understand the scriptures right maybe I don't understand you right is saying that there is a different type of schema that we're putting in the manifest collection. So there's like two statements that I want to want to tease out from what you just said. One is that you said that the index only supports two different media types in the manifest. Maybe I'm missing things in the spec but I didn't see that restriction there. So that's one. The second is that you called this a signature index. And I don't know that we need to have typed indices the type indication is really the manifest type field itself that's telling you what you're looking at. And I don't think that we need to have it like a separate signature type of index versus an image type of index. They're both just indices. And you look at when you're an application and you're trying to interact with this you read the media type field to figure out what you're trying to look at. Let me deal with the index as a type separately, because this is the one that I think will if we can fix this it would make a lot of optimizations better. So if I look at the image index definition, which is ironically not in distribution but in the image spec which is the refactoring conversation we've been having. So it's an array of objects that are committed manifests and it talks about these two. Basically this is the image manifest and this is the image index. In fact it says yeah but those that's not a restriction right there it says it must support at least, which implies that definitely could be other things it could support. So here is, so this is something we discussed early on artifacts and I'm really happy to have this open this discussion again. The, if I think about the way registries parsed incoming manifests. What makes artifacts really easy for registries to support is we actually didn't ask them to change anything in their incoming of parsing. We get a manifest that references some layers. The fact that the layers are is the one is only one layer and it happens represent a helm chart or a foo file a markdown file is irrelevant it doesn't matter. The only thing a registry has to do is say I allow other config media types to be persisted to be submitted as well. So that's what makes it super simple. The two, and we haven't dealt with index yet right this is all new and OCR effects doesn't support index yet the that same schema processing is the processing that gets done on an index as well when you look at an index. There is a schema for this index that is described as. And in fact this whole goo for the multi-arch step is all optional. So you can legitimately ignore this when I'm trying to persist. Let's just say a CNAB. Let's take signatures out for a second because it's just loaded with all these conversations. A CNAB is a collection that has an invocation image, which is supposed to be how I run this whole thing, and a collection of other images that might get deployed. In, if it would, if it worked better, it would actually have the helm chart as well as your compose whatever else that the CNAB needs. What they're doing today is they have to stuff those additional artifacts into the invocation image, which means that every time I want to deploy a different helmet I have to rebake my, my invocation image which just feels broken. So you're building your CLI because you're trying to deploy a particular thing. So having that collection is really helpful to be able to say that there's a collection of something else, not a multi-arch image. But I wound up going on the different artifact types for index. What I was trying to focus on is a registry doesn't need to, that knows how to parse indexes and index doesn't need to know these, these two would ever be any different. And if we do say a manifest media type is different, how much more does that make it complex for registries to parse? So in your proposal, the registry does need to know about the signature, because the registry needs to figure out how the signature, sorry, I miss speaking right now. But like, I don't think this changes much. Either the registry does want to parse it or it doesn't. And if it doesn't, it can treat that media type, whether it's in a config object or in a manifest as opaque. I don't think it makes a difference to the registry, whether it's in the config field, which doesn't exist yet, or if it's in the manifest field, which does exist today. The manifest does exist today, you're right. We still want to, which thread do I pull on, what it's still, let's say we go with this proposal. I'll take, let me use this one here. I'm suggesting you still want to push the signature as something else, because we always want to have a mutable objects. We don't want to have to, if I'm pushing a second signature, as in this case, I don't want to update this index. I want to be able to push, like when the, when web networks offer authors, the net monitor software, they might push it and immediately push the signature, that's fine. But when it goes to Docker Hub, they should be able to add a signature without changing this one. And when acting rockets wants to pull it into their register, they should be able to add a signature without impacting this or the other one. So Steve, I'm not suggesting a change of anything else in your proposal right now. The only thing that I'm asking is, why is it a config field versus in the list of manifests. Because you can still have the exact same thing where you've got a separate index that just pertains to the signature and the reference to the, the image, as opposed to the index that is the multi arc image itself. I'm not saying that we combine them, like, given the structure that you've laid out in this document here, the only question is why is it in a config versus in the existing list of manifests. No, great. That's what I'm asking and I'm just trying to, I'm just trying to get a solid base. So if we agree these are separate, then that's good. And then the question is, because now I don't have to worry about this being a multi arc index, right? It's not a multi arc index, it's a signature index. And now we could say that this has two references. It would have the, where's the manifest. Well, I guess that would be your suggestion here. It would have, where's your change. This is yours, right? Yeah. So it would have a reference to the web networks image, and I would have a reference to the signature. And instead of it being, the problem is this is a blob reference. It's not a manifest reference. But this is a blob descriptor. So it's the, I'm trying to understand one thing though. So is the point of this config field and using the index in that way. Is it for backwards compatibility or what's, because like, yeah, what what sounds proposing would be compatible roughly with existing registries today, the config method would not be compatible with any registries. So I guess I'm trying to figure out, like, what is the compatibility story and Sam, is that your, is that your main concern here is that if we introduce a new index type that there's to be no compatibility kind of on the day of release. Yeah, I mean, that's, that's a concern. I don't know if I'm, I'm, I have an opinion on whether we should or should not have the config field. I'm just trying to understand, do we have a more fully articulated reason for it. So that there's two parts because they're pulling at each other. What's nice about this, because we're bouncing with it back and forth, which is fine, is this does make it more optimal on the amount of round trips I have to make. And it also says that this config object, which actually storing data is a little weird, right config should be some kind of configuration information where the signature is clearly data. So there is a conflict that we're doing. The reason that we're putting config in the reason we're proposing putting index, sorry, config an index is twofold. The primary is just so that I can know that this index is of type signature. Right, so I can say actually it's probably easier to look at this one, because this index is a multi arc index. An index is a signature object. So we're basically saying there's different artifact types. There's container images, there's helm charts, there's wasms, regardless of where they live opas and so forth and those are all manifest types. What we're saying is there's also some other artifact types that that makes sense to be represented as an index and a CNAB has been the most obvious one. And the idea is that a signature can be one as well, because it allows me to do a reverse lookup. If we come up with, because even if we're saying that the signature is in here, and that's why I was trying to just focus on this one in that second ago, was we're still suggesting that a signature is of type index. We're just saying that instead of being put in the config we're putting in the manifest list. But if I query a registry for the objects that are in it, I'm going to want to know that this is a manifest, sorry, a container image. This one is a multi arc manifest. This one's a signature. This other thing off the screen is an opa versus a wasm or whatever. So if I don't have a config object that says this is a notary V2 object type, then how do I know this index is not a multi arc index. I guess, if we're talking about, I think we had this discussion, I don't know, I don't remember when the discussion was, it was the last notary call about kind of shoe horning the config into index and my opposition to doing that. I think that's kind of related to Sam's underlying concern is that it really adds more ambiguity and confusion to something that we've already, I mean, we spent the last year to complaining about the confusion around indexes image indexes versus artifact index versus manifest versus artifact manifest or just the whole image versus artifacts and adding config here. I don't think it's actually the, I don't actually think that fixes this problem. I think it actually makes it a little bit more confusing because of backwards compatibility issues. So let me ask more basic question because this is, you know, sometimes you have to go forward, take a step back and re-evaluate. We've always struggled on how do we say a thing that's in a registry is of one or the other. Is it a Helm chart? Is it a singularity? Is it a wasm or is it a container image? Or, you know, where are you going to see now? So I agree with the data model here. I think it's a right approach actually having the config and the references separated. Like, I mean, what Sam's proposing would certainly be compatible with what we have today. I think more compatible with what we have today. I think the data model you're proposing here is better. My opposition is specifically that we consider that like an OCI index. I think we should call it something else. And I think we should just call it like a manifest index or manifest artifact, manifest or something, and completely separate it from OCI images. That's my proposal in terms of like where this should go, but I think the data model is right from a notary perspective. The thing I'm trying to separate or tease apart is what Sam's suggesting is mutually exclusive. We can do both. I think that's one of the separate problems. Because where we, if we want to store something in a manifest list that allows us to get direct access to it, that solves a bunch of performance things. And that's super cool. The problem, the other problem, though, is I still don't know that this index is a type signature, as opposed to a multi arc index. I'm trying to tease out of the two problems. And you could actually argue that if I know that this index is a notary index as opposed to a multi arc index, then it actually frees up my ability to make the manifest list be a descriptor list actually. And it's actually pointing to the signature directly as opposed to a manifest that points to a blob or config. I'm not saying that very clearly. There's too many things in that conversation. The memory phrase. How do we, how do we know that this thing, this collection, the manifest list is not as a signature list as opposed to a multi arc list. That's it for Sam to answer. I mean, I think the question is, like, why do you want to, what's the, what do you need in order to make that distinction. Like, you can look at the media types of the things that are in the list of manifests and say, Oh, this one's a signature, and then I know that that's signature. True, like we've, in fact, Linux does, you know, is the non extension model in Linux that you parse the data and you can figure out the ideas, is there a more explicit thing that you can just say, without having to parse a collection and do some inference. Is there a reason not to have a way to directly say this index is of type is a signature, it is not a multi arc index as opposed to a registry having to parse the collection and make some inference around it. So if I do a repo listing in a registry, I want to be able to clearly see which, what type each thing is in the registry, whether it be a digest or a tag. Is this a container image and is it Windows or Linux? Is it a helm chart? Is it a singularity? Is it a wasm? Is it a signature? That's the simplicity of what we're trying to do. I mean, those are all things that you figure out from an index today. Like if you look at an index today, you're going to say, Oh, well, I, you know, this one's a Linux arm 64 image. This one's a Windows AMD 64 image. This one's a wasm image that's, that's contained in the descriptor in the index right now. But it's a multi arc index. The index, the index doesn't care, at least in the spec, whether it's a multi arc index or anything else. It's just a collection of things. Right. But today, the use case is it's a collection of container images that are differentiated by platform. And that is what most indexes are today, but that's not like the spec doesn't restrict it to that. Well, true, the restructors got a lot of respect has got a lot of openness and a lot of places, which is what we're trying to take advantage of, but we're also trying to figure out how do we not break, you know, what's the minimal impact we can have to something. So today, the proposal we've been having around the config object in index set lets a container be client, for instance, when it does a poll, that it would see that this is not a multi arc index that the media type, there either is no config object, or if there is a config object that it doesn't explicitly say it's a multi arc that it says, not for me, and just bails. And that's, that's kind of the model that we were focusing on the compatibility. If we say that this thing is still a multi basically a multi arc index but there's some other things in it. How does it know how to parse the different collections and in fact in a registry. When I list things, what you are saying that when I look at the, the index that I can see that the, you know, inside that index there's only an excellent windows and an arm and so forth. The question is the tag itself that says it's a multi arc index. That's what we're trying to differentiate. In fact, I think we've got this working in these here and I can show the example. Yes, I think one thing that I find kind of troubling about the idea of adding a field and calling it the same thing is how are registries supposed to handle that. When you push an index out that has a config field that config fields just ignored. And then somebody goes to pull that like oh there's a config I'm going to pull it the registry, you go to pull it and the registry like I don't have this object, because it didn't know anything was referencing it, because it had no idea that there was a config field. It like pushes the problem of registry compatibility down to the polling client which is the worst place to try to handle it. I was trying to multitask and didn't hear everything you were saying. Yeah, just saying that like you can you can add it, you can add support for it in the registry. But is if you're trying to use the same types, the same OCI type, this config field, the older registries aren't going to know aren't going to look at that field. And they're just, it's just going to be a lost object that a client's going to come down poll, say, oh, oh it has a config object therefore I'm going to go down this other branch of logic, and it's going to fail because the registry didn't keep that keeps that type or keeps that object because it didn't know that that object is being referenced. Yeah. So, like, what we let's just go back to how we did it with manifests right because this is basically trying to apply the same pattern we did on manifest to index. So, on a manifest, because this thing has this media type, we know it's a helm chart, and we can just pop the helm logo up here, as opposed to think I've got a singularity one in here as well. On this tag, it's a type singularity. Yeah, and I, I, I completely agree with this approach, like the I agree with the config field, like it's value in the manifest type. I think we're specifically here talking about the config field in the index type, because I agree that like having a config, and then some reference blobs is what we want. And we're stuck with these two, these two manifest types that are neither we have, we have in the have the regular manifest type which is clearly designed around images it has this weird word called layers in it. And then we have an index which has no config. So we're stuck with these two types, and we keep going back and forth about, like, Oh, should we put it in this type or if you put it in this type or should we. That's, that's all that's my recent proposal says, let's not use either those two types let's just introduce a third type. Either we use, we use the existing manifest type and just say layers means doesn't mean what you think it means. Or we use a new type, because if you take index and you add config, it is a new type. It has to be a new type it has to be a new version, and it has to be explicitly supported by clients and registries. Okay, so I just want to, I want to try and chip away in a couple of these separately because there's lots of different options we can go and just trying to make sure we're capturing the various problems. The reason I'm trying to show these two is just that this is how we differentiate the two types right so I'm just trying to see where we agree that we like this. Okay. If we like the way to differentiate the different types of manifest how a manifest can be used for different types. The thought process was we wanted to take that same concept on index that an index can either be a multi arc index, or it could be other things like a CNAP or a signature. The reason we were trying to use index for those two things for CNAP, it is a collection of artifacts, an invocation image, a couple of runtime images, hopefully the actual other artifacts that I would use for deployment like Helm and otherwise will be external things so that I don't have to rebake the invocation image each time. The reason that we were wanting to use it for index, sorry, signatures was we needed a way for something to reference something else. And if we remember in the discovery options, yeah, here we go. So in the example, let me make sure I got the right one. Yeah. So here's the example where we were exploring storing a signature as a manifest. If we store a signature as a manifest, how does one manifest declare it references something else. Now, we could change the manifest schema to add another property to it. What we, working with what we had, what we did, what we proposed was in the config object, this is the actual No, here this, the config object would store what it was referencing and registry could say, Oh, in the config object, I see what you're referencing and let me store that linkage. It felt weird that we are introducing that kind of behavior that now every registry has to pack crack the config of this particular type. This, this type to know what it's pointing at when an index already knows how to refer refer other things. So the question I'm kind of hearing here is, should a registries that today know how to deal with two different schemas manifest an index manifest being a single thing and it's being a collection of things. Should we introduce a third type. Yeah, my argument is if you add a config field you are introducing a third type, no matter what, like if you if you change the index, you can't just invisibly handle it like it is a third You can't invisibly right but that's what we wanted to use the versioning that says this property is an optional property in this new version of the scheme of this evolution is not a breaking change it's now to change. We wanted to test downward clients to see how they handle it. Yeah, that was my point last time is that there's no such thing as like no breaking change, like we learned this with OCI, we went from Docker to OCI. Yes, we, you can, you can version it, you can increase the version but it is a new type that needs to be handled like there's no, there's no magic that that's going to handle that they happen to. Until Tina runtime clients know how to handle signatures, they, the premise is we would version the schema and they should be forward compact aware, if that's the right word. They should say, look, I don't support anything greater than this version so I'm not going to accept anything until I know how to deal with it. So therefore, can I try and see if I'm understanding your concerns specifically is that you're worried that a registry which performs garbage collection is going that doesn't know about the config field is going to delete the object pointed to by the config field because there's no reference to it. Yep, that's one of the exact. Yep. So, I think Steve what, what Derek is saying is that if there is such a registry this isn't a forward compatible change, because the registry will lose track of the object. It's, it's potentially a forwards compatible change on the client side, but not on the registry side. Because we got multiple adding the new config field. And a new digest in there. If the registry doesn't know about it. It's going to lose track of the object that's referenced by that descriptor. Oh, the config object in other words, yes. Yes, so we think so there's two sets of compatibilities right there's the registries and there's six or eight of them major registries or whatever you know less than a dozen let's just say. And while there's probably less than a dozen container clients, there's how many deployments of those. So, part of this is trying to wrestle where what change and what the impact has. And the thought process is that registries today either don't support index, or if they do, many of them are checking the media type. And if the media type isn't of type index, they basically toss it anyway. So, if we add something, being able to communicate with the various registries on the registry side is less impactful than trying to find every compute node in the world that is running a container client container host. Yeah, but then you're still stuck in the situation where now you're trying to add a config, but you're also trying to be forward compatible or backward compatible with multi arc images. So essentially, every use of the index in this case is just trying to accommodate the possibility that a client may interpret it as a multi arc image, rather than let the clients explicitly say, I don't know what this is. And if it is a multi arc image, that's fine. Just leave it as a multi arc image but the idea that you're just trying to like, you're trying to reuse something in a way which you think that an older client will misinterpret it in the right way is kind of difficult. Like, there's already approach where the clients will explicitly tell the registry, these are the media types that I support. Right. So like we already have a way to do that. It's not always pretty, but we already have a way to do that. We do like the idea of having another type that's at the root because today, it's just index and manifest. The thing that we've been trying to do is figure out how do we not have a huge impact on that because what we're basically saying is for the most how it. Yeah, we can make it should registries have to know about these new schemas. That's what I'm trying to avoid. This is in parallel to because I don't want to derail the notary discussion, but maybe we should start up another thread on the manifest side to introduce something because yeah, in reality we would need to introduce this first in the manifest before we could use it in the notary or sorry in the artifacts back. So if we introduce something there, then, then maybe we can consider it here but yeah I agree like we don't, we can parallelize this we don't need to continue down that way. We do that we're going to wind up having this discussion the notary call that in fact on the notary call last couple weeks we've not had a bunch of notary specific conversations because we're trying to get them blocked on this so it's okay. Let's get a quick question around that so it sounds like we're worried about backward compatibility for registry implementations that just that only focus on those two media types and that anything else they might GC out of the way or do something untoward with wouldn't be in violation of the spec. I mean this the spec says that minimally those two media types are to be supported and that other media types may be in play and if you know I mean it's you know these specs are sort of RFC light I think that they're not hard coded specs but I mean, given that that is in the spec, it feels like it would be in violation to say well it's not these two that I care about so I'm just going to nuke those media type. I think that's why that's what Sam's proposals about or what Sam was suggesting because yeah the registry should not throw away should not do that anything that's in that manifest in that manifest array. However, anything that's in that config field a manifest may throw away because that was not part of the specification. You can't just add something to the specification later on and like you have to you have to create a new version right and when you create a new version. It is a new it is a new spec like like I know you're saying like oh it's just a minor version number. It's not like it's it's different behavior. It's not the same thing. So, right we were kind of at rat on. So, um, the, the, okay, do we, this one's not sure it's on this Wednesday's OCI agenda. So folks were talking to come back but I haven't seen anything yet. This is the thing that's kind of wrapping us up to try to throw up the next steps because we definitely want to get this resolved. I'm trying to get the right form to have this conversation because we're pulling it all the things that we've kind of gotten here and a bunch of these are great conversations to reevaluate. That's that's all point of the prototype is go forward and go back like no turned out we didn't like that let's go back and change it. But we do need to figure out what's the right thing to move forward with even if we might do it. That sounds good. Maybe I'll talk to you more. I think we talked a little bit after meeting last time. Steve, but yeah, maybe we should have a try to come up with a try to come up with a real proposal that can take to OCI proposing. Yeah, this change, or what the right way to get this changes I mean I agree with you with with the config like in the data model like it. I think we're just naming and where everything goes. Anyway, it's after prototyping. And the whole challenge is do how much special case and we want to do for signatures versus anything else. I'm like, the WASM thing came out of left field but that's the whole point of it. Because like they didn't have to do anything special. And that's what we're trying to enable and not make, make sure that as new types come up registries don't need to do anything special. Maybe what I'll do is list a couple of the things that were kind of in this and then we can decide, you know, that's not important or this one's big enough that we should make a change or maybe we'll make this one change and now all these new things get lit up. So, if that's kind of my hope with the artifact spec that that we can we can propose a solution there from the artifacts angle and if if the right solution is is versioning or adding a new version of the image index and we can but yeah I think we should propose this from the artifacts angle, not just the notary angle. Let me see what the agenda winds up being for Wednesday and if the solo folks aren't coming back then let's put this on Wednesday's conversation. Are you available. I see Sam's gone. Justin that's kind of late for you to. I can try to make sure I'm available, but I'm, I mean, I can, I can make it anytime though. Yeah, I can. I don't mind reaching out to you and Sam and well pretty much everybody's on this call. That's the slot where we can get a bunch of us that would have the interest and impact and let's shoot for the two o'clock Wednesday. Cormac you're muted. Sorry, put something on slack anyway. If you do a dark or something and put it on slack as well. Thanks folks. Cheers. Thanks.