Use XDG_DATA_HOME, XDG_CACHE_HOME, and XDG_CONFIG_HOME for saving data

[leroycep]

The Arch Linux wiki has a page on these environment variables: https://wiki.archlinux.org/title/XDG_Base_Directory

Current Path	Path Using XDG Base Directories	Potential Default Path under XDG
.reticulum/config	$XDG_CONFIG_HOME/reticulum/config	~/.config/reticulum/config
.reticulum/storage	$XDG_DATA_HOME/reticulum/	~/.local/share/reticulum
.reticulum/storage/cache	$XDG_CACHE_HOME/reticulum/	~/.cache/reticulum

[leroycep]

Oh, reticulum already kind of supports using XDG_CONFIG_HOME when it exists:

Reticulum/RNS/Reticulum.py

Lines 223 to 228 in 0ff51fe

	if os.path.isdir("/etc/reticulum") and os.path.isfile("/etc/reticulum/config"):
	Reticulum.configdir = "/etc/reticulum"
	elif os.path.isdir(Reticulum.userdir+"/.config/reticulum") and os.path.isfile(Reticulum.userdir+"/.config/reticulum/config"):
	Reticulum.configdir = Reticulum.userdir+"/.config/reticulum"
	else:
	Reticulum.configdir = Reticulum.userdir+"/.reticulum"

Still, I would like to see:

• XDG_CONFIG_HOME and similar as the default directories
• Proper handling of the XDG_CONFIG_HOME and related environment variables.

[evgmik]

I second idea of using a separate (well defined XDG) cache directory. This allows not to save cached thing during backups: configs are precious (and usually small in size) but cache seems to grow with every new announcement. By modern standard cache is tiny (75MB) but it seems to grow every day.

Same issue is for nomadnetwork. Its storage/lxmf seems to grow very quickly, I already store 0.5 GB after running it for a week.

[markqvist]

The Reticulum cache is cleaned periodically, and should never reach obnoxious levels, but still, it's a good idea to have some way of not include unnecessary cache entries in backups. That being said, some of the cached data is important for transport nodes, so it's also not a good idea to put it in completely ephemeral storage.

If you're running an LXMF propagation node, the lxmf/storage directory contains the propagation message store, which is why it will take up some storage space.

Right now though, most of that space is actually file-system overhead, since each message is stored in a separate file. On filesystems such as ext4, that don't support multiple file entries in each block, or storing small files directly in the inode structure, this will incur significant overhead. The actual message store data size may be only around 50 megabytes, but could easily consume around 500 megabytes of disk space, due to this overhead.

In the future, there will be an option to keep the message store in a sqlite database, which will bypass this overhead. For now, it is also possible to use a filesystem like btrfs (which I * think* can store small files in inodes by default) to drastically cut down on disk usage.