The current thinking from the meeting (correct me if I'm wrong) is that Docker extensions are late-bound named Docker containers; each extension defines a set o

The current thinking from the meeting (correct me if I'm wrong) is that Docker extensions are late-bound named Docker containers; each extension defines a set of "drivers", which have privileged communication to the Docker daemon, and which speak libchan (which is msgpack over HTTP 2) to interface with well-defined "internal" (but public) APIs in the Docker daemon. Each driver can bind to sets of internal APIs, which allow it to insert blocking hooks in e.g. a networking API, for "network create" or for volumes, before "volumes create". In terms of extending the CLI, there was some mention of standardizing on JSON Schema for specifying the APIs, such that CLI user interfaces could be auto-generated. A lot of detail here remains to be thrashed out, but yes, the git model is definitely one to look at. We also talked about modelling this on other successful plugin models, such as the one that ships with Eclipse.