You’re kidding me – I was working on *exactly* this pretty recently, because to me it seemed crazy to me that this exact solution doesn’t exist. Yes storage and bandwidth requirements for some types of fedi servers are absurd and it seems like this would be a big help.

It’s not yet working or even real close to it, but the basic design that this *will* have once it’s reached alpha status is:

* Media volumes exist as a FUSE mount which exposes a media volume
* Multiple nodes can share the same volume in a swarm; it’s stored via content hash in a Merkel tree, which means deduplication, cache coherency, and trustworthiness of the data from random nodes. You don’t need to have the whole volume in your local cache in order to have the mount (like IPFS)
* You can choose to pin volumes on your node (requesting replication in full to local storage – this obviously must be done from at least one connected node to guarantee that data isn’t lost)
* There’s a service worker which can cut out the middleman and grab stuff directly from the swarm nodes, to cut down on bandwidth and storage requirements on the central server

I had shelved it for some other things, but if you want to give a bounty, I’m psyched to pick it up and start working on it again, because I thought it was a great idea. I left my email – reach out to me and let’s talk more; if you give me a week or so to clean up the code I can probably give you a little demo of the (very, very small) part of it that’s actually working now and we can see if it can fit what you were thinking, and talk more about timelines and features.