Strictly for LAFS

So upon request I've added Tahoe-LAFS, the Least Authority File System, as a Freedombone app. I first investigated this system last year when I was looking for something which would be suitable for distributed file storage within a mesh network. For the mesh system I eventually went with IPFS instead, because Tahoe-LAFS normally requires a centralized introducer node and in any genuine mesh software architecture there should be no centralised systems.

However, that doesn't mean that Tahoe-LAFS isn't useful in a more conventional client/server scenario. Unlike IPFS caches or pinned files, Tahoe-LAFS tries to implement robust and secure data storage in a more systematic manner by keeping multiple shares for each file which can be used to reconstruct it, and you don't need to trust the servers running the system because the data at rest is encrypted.

On Freedombone Tahoe-LAFS is accessed via a web user interface using a Tor browser onion address. None of the system exists within the clearnet and so this could be run from an "onion only" installation of Freedombone. Following the usual principle of support between friends you can enter the details for other Freedombone servers running Tahoe-LAFS and build a larger storage resource in which you don't necessarily need to trust individual friends or expect their server up-time to be totally reliable.

Currently Tahoe-LAFS is mainly useful for storing files which don't change (which are "immutable"), so bear that in mind if you're using it.

Another detail of the way I've implemented it is that there are no introducer nodes and instead you manually enter the details for other servers. This means that there isn't any central point of failure. I'd recommend that server details be exchanged either via sneakernet on USB drives or within a chat system which implements forward secret end-to-end encryption (eg OTR or OMEMO).