I've split each dag exploration tool into a separate subdomain:
I'm not sure what I will do if there's ever a dag worth exploring that doesn't fit neatly into a three-letter acronym (tla).
You can find the source on GitHub.
I built an interactive registry exploring tool hosted at explore.ggcr.dev a while back. We used "ggcr" as shorthand for google/go-containerregistry, so I snagged the "ggcr.dev" domain when the ".dev" gTLD was new. Since the website is essentially an interactive version of crane (and was initially developed on a branch of the ggcr repo), it made sense to host it under ggcr.dev. Eventually, I decided that I wanted a more aesthetically pleasing and generic domain, so I moved everything to "oci.dag.dev". That domain name is by far the most expensive part of running this site.
Shortly after joining Chainguard, I learned that alpine packages are also "just" gzipped tarballs embedded in a merkle dag, so I forked most of the logic to work work with APKs and spun up apk.dag.dev.
More recently, Russ Cox published rsc.io/gitfs, and I realized I could do the same (more or less) with git at git.dag.dev.
This site was built with love by the human hands of @jon.dag.dev. I hope you find it useful.
I've spent my entire career interacting with container registries in one way or another. For my own use, I built (with others) crane as a sharp debugging tool. Since I was on the registry team at Google at the time, people often came to me with registry problems, and solutions to those problems often ended up in crane. Likely due to poor documentation, people continued to come to me with their problems even if they were already aware of crane, because they weren't sure where to start. Part of the motivation for explore.ggcr.dev was to scale myself by making common debugging paths more approachable and interactive. This (sometimes) allowed people to debug their problems without needing to talk to me at all, which removed me as a bottleneck for them and gave me back a bunch of time to focus on my own work.
A long time ago I wrote up a short explanation of how it all works, but I've been meaning to write a more in-depth (and interactive) explanation. I've yapped about this in more detail on the Ship It podcast if this is at all interesting. There's also my targz repo which I extracted from the site into a standalone implementation. It is mostly a thought experiment but it serves as a decent model of how the oci and apk sites work. The git site is just a thin wrapper around a fork of rsc.io/gitfs and is less polished.
I'm still trying to come up with a good name for this style of interface. It's not completely novel but I don't see people do it that often. For me, the important features are:
If all these things are true for a given dag, I think this style of site is very useful. The user can build up a model of the relationships between objects in the dag themselves using their own real data rather than trying to follow contrived examples with manually drawn boxes and arrows. The web is a very successful graph that everyone is familiar with, even if they don't think of it in terms of graphs. Projecting an opaque data model onto a hypermedia graph I can just load up in my browser makes it super comfy to use and really easy to share. Rather than giving you a long command you have to run locally (and potentially install additional software), I can just send you a dag.dev link and we can look at things together.
If you encounter a bug or have a feature request, don't hesitate to file an issue on GitHub.
If there are other interesting dags I could help you explore, feel free to reach out to @jon.dag.dev on blue sky so we can brainstorm.
I am pretty sure this style of site was heavily inspired by my experience using tools like phpMyAdmin and code search.
I was cursed with the knowledge of gzip magic by Aidan Steele.
Big thanks to Docker as well for lifting Docker Hub rate limits on my account for oci.dag.dev.