There are also a few others, and I've spoken to Lennart about using casync. It's a bit of a mixed bag because while casync does give us mostly what we want (and I've had a very long thread on Twitter with Lennart about it), there are some other concerns I've heard in the past few days from OCI users that make me quite cautious about using a format that cannot be easily made into a runtime format.
For instance, some folks want to have their runtime format be identical to the image format (so that signatures of the image can be used to verify the running containers). This is something that you cannot currently do with stock OCI (though they have worked around it), but should be a consideration for a future format. I only became aware of this concern after writing my blog post, so I will have to include it in the next one. :P
My last skim of casync suggested that it's heavily block-oriented. That's fine for backups and FS duplication, but as a distribution format it doesn't really fly.
A lot of folks want two levels of insight into the image's provenance or trustworthiness:
1. Has the image been tampered with? This is mostly solved by TUF / Notary.
2. What are the files and where did they come from? This means you need a file-level abstraction that is simple and fast.
Insofar as casync is block-oriented instead of file-oriented, it's a poor fit for the second problem. It doesn't matter how efficient the streaming and storage is if you make people download the entire layer each time you want to check a single file.
For instance, some folks want to have their runtime format be identical to the image format (so that signatures of the image can be used to verify the running containers). This is something that you cannot currently do with stock OCI (though they have worked around it), but should be a consideration for a future format. I only became aware of this concern after writing my blog post, so I will have to include it in the next one. :P