(and if you like that article, consider subscribing to LWN!)
1. one that commits treeish diffs into objects, and then stuffs them into arbitrary content-addressable storage;
2. and one that manipulates (local or remote) mutable tables of refs to content-hash-URNs -- or "git repositories" for short.
The key component would be a facility (either a library or an OS service) for resolving content-hash-URNs into file-descriptors in some content-addressable storage system. The critical point is that this would not be a git component -- the committing tool wouldn't be in charge of where its objects go, and the repository tool wouldn't be in charge of resolving their URNs. Instead, both would just be relying on the host to decide how to get objects from/put objects into storage, and it's the host that would have a distribution strategy set up for all of its content-addressable objects, not just the ones that happen to be attached to git.
See http://www.fancybeans.com/blog/2012/08/24/how-to-use-s3-as-a...
The remote server can obviously be running an object-storage node itself, and so can your own local git repo -- the point is that you can have objects in more places than just your machine and the repo it's pulling from.