Terra-distributable personal data storage.
The idea is pretty simple: a little box you put on your network where you can store your electronic files and not worry about losing them. These have been around for ages and come in all sorts of shapes and sizes. Many have some form of redundancy so that if something breaks (a disk fails, etc.) the data they store is not lost, but if something happens to the entire device (like a house fire, or it walks out the door) everything is gone.
The standard response to this is to back up the NAS somewhere "offsite", typically some cloud service. This works, but it usually involves paying rent, and trusting your most precocious, personal, private bits to companies who frequently loose track of such things is risky.
So the idea behind NAS-T is to solve the offsite backup problem through backing-up to OPT: Other People's NAS-T.
The device allocates some percentage of the total physical storage to store encrypted backups from other NAS-T devices (I'm still noodling on the exact amount).
For example, if you were to purchase a NAS-T with 10TB of storage, you could store 10TB of data on it, but the physical storage medium inside the device would have a capacity of maybe 15TB.
As soon as you connect a NAS-T device to your network and grant it access to the Internet it begins to store backup data from other NAS-T devices. Once you start copying data of your own to the device, that data is automatically encrypted and transmitted to other NAS-T devices across the Internet.
From your perspective it's no different than any other network storage device. You mount it on your computer like a network drive, you copy and delete files, etc. The only point where things change are in the event that you loose your device. If this happens, you can take a new NAS-T, configure it just like you did the original and once it is connected to the Internet, your files will begin to reappear.
I have a few ideas for the implementation of this but I'm trying to decide how deep I want to dive into that in this post. This is a topic I love to think and talk about, which means that if I get started this could be a really long post.
You've been warned, "here there be dragons"
It will surprise no-one that the way I'd implement this starts with something like JSFS, using one of the distributed blockstore designs I've experimented with. JSFS provides the foundational file store, defaults to encrypting jblocks and jnodes and distributes them to peers with a 1:3 replication ratio.
1:2 is safe, 1:3 is probably sufficient for most personal-use scenarios I can imagine. It could be higher, but I need to work the math more.
The real question is how to expose the JSFS API in a way that can be directly consumed by typical clients. A web UI is of course an option but something like SMB/CIFS (or whatever they call a "Windows share" now) is needed to fit into NAS expectations.
There are some unanswered questions here about discovery, firewall traversal, etc. but I've covered those topics extensively elsewhere with regard to JSFS federation so I won't go into that here. This application makes some of that easier because having some sort of coordination server(s) on the public Internet is not as unsavory as it is to me for general-purpose JSFS use.
This could be done a few different ways. The off-the-shelf-ish way would be to finish writing the JSFS FUSE driver and then use Samba/etc. on Linux to re-share the FUSE mount as a Windows network drive. This is probably the "right" way to do it but if you know me, you know I like doing things the hard way.
A more direct approach would be to write a driver that serves the Windows share directly from JSFS, possibly even bypassing the JSFS REST API and connecting to the underlying storage primitives. I've never written something like this for JSFS, but it's easy to imagine being a modular/pluggable part, especially in the Golang port.
Having a "slot" like this in the architecture opens the door for exposing other interfaces in a modular fashion; in fact the REST API could be the first of these modules...
Taking this route opens the door for getting rid of Linux entirely using something like gokrazy or a unikernel, making the device not only more resource efficient but also more stable, secure and eliminating the need to update it.
I've been looking for something to motivate me to complete the Golang port of JSFS and a project like this, if there's some interest from other people might be compelling enough to get me to do it.
Jason J. Gullickson, 2026