Freedesktop.org: Standards: XDG Base Directory Specification is the main document at hand here.
Every now and again the folks that work on free software decide to rearrange a specified or de facto standard directory/file structure with an eye on improving the state of the platform. XDG-basedir is one such attempt, but there have been others like the advent of /run.
The XDG-basedir basically stipulates three locations:
$HOME/.configor$XDG_CONFIG_HOME$HOME/.local/shareor$XDG_DATA_HOME$HOME/.cacheor$XDG_CACHE_HOME
These are meant for your configuration files, data, and caches. These locations provide for some flexibility and improved organization over throwing everything in your $HOME. For example, your caches may be kept in a virtual path that points to RAM or on a SSD that is faster than your regular storage. Or your configurations may be on some networked disk.
Lots of applications support this specification in some way, though some more than others. To take advantage of this specification requires first looking to see what dot folders and dot files (ie, those named like .foo) exist in your $HOME. While you’re at it you may look in the above-mentioned folders to see what applications have already set up shop in their new locations.
Some applications will have moved their baggage themselves. Other applications implement the standard to whatever degree, but give precedent to the old location, the old dot files. They do this out of pragmatism. They don’t have to write a migration scheme, and they don’t confuse their long-term users who may not know or want to know about these new locations.
For these applications, moving the files yourself (or if the data/configuration/cache does not matter, simply deleting the existing file(s)) works fine.
For others, those that do not support the specification, you can often still move them if you define their environment to point to the proper location(s).
An example of the latter is Mercurial, the distributed source control system. It does not support XDG-basedir, but it does support the environment variable HGRCPATH. By properly setting it, export HGRCPATH=${XDG_CONFIG_HOME}/hg/hgrc (or the full path if you do not have XDG_CONFIG_HOME defined), you get the benefit of the specification without Mercurial actually supporting it.
In cleaning my own $HOME I found this sort of fix was useful for about six applications including vim and gnupg.
Still other applications do not support an environment variable to specify where their files live. Some of these will accept configuration file locations from the command line. For these, setting shell aliases or functions may help. I found this useful for only one or two applications.
Some applications have support for it in versions newer than I have installed. I let these wait, glad to know of the effort.
And quite a few applications have open (or closed) bugs for supporting XDG-basedir. In most cases this is less about the technical work for the specification and more about deciding if and how to support it. At least a handful of the applications I looked at were reticent to support it at all. Others said support would be welcomed given enough background to show what would/not break and with a patch available.
But several argued about how far they would support it. This mostly came down to applications willing to move their lot into $HOME/.config (or wherever $XDG_CONFIG_HOME), but not split out cache and/or data. It seemed this was more often argued against for portability reasons (ie, they support Microsoft Windows operating systems and want to allow their users to move their files between them or have them on one common drive without issue).
And in rare cases files are hard to nail down. They sort of configure, but they’re sort of data. Or they’re sort of data, but they’re sort of cache. (Hopefully never all three in one.)
On the whole I was able to reduce my number of dot files by about 15, and the number of dot directories by about 60.
At least a full half of the files and folders I lost were obsolete entries from applications that I no longer use. Another chunk were applications that wrote their configurations even though I used all default options. The rest were from applications that now support XDG-basedir or had other acceptable workarounds for moving their files.
I find this an interesting topic to look at given that the change to applications is not overly complex, but it affects a wide variety of applications. I also like having a cleaner $HOME as it makes finding things easier.
Maybe my next step will be to audit my XDG directories as I’m sure they contain some files from applications I no longer use.