RNS Logo

rns.recipes

◈ 9ce92808be498e9e05590ff27cbfdfe4
Guest posting from WWW mirror disabled. Ident on Nomad @ 9ce92808be498e9e05590ff27cbfdfe4 or sign up to post

Distributed cloud system over reticulum

Started by falafool 44aada36cb287bc8... ·

falafool 498e462afc534ace...
#1

I have had this idea of distributed cloud storage over reticulum, where
communities can contribute their storage for one big cloud storage.

And i think the idea is worth exploring, generally distributed cloud systems be it computing power, storage or other might be a good match for reticulum.
Or maybe not? What do you think can such system be closely integrated into a network protocol such as reticulum, or are they quite independent?

Hope we get to spitballs some ideas of concepts and implementations

falafool 498e462afc534ace...
#2

other uses i can think of distributed clouds:
I'd love to have more computing power,but can't afford to always buy the newest GPU every 5 years. Why not make a network of confidential GPU's (where RAM and VRAM are encrypted or data doesn't even reach host RAM).

Brooke 108902ad5b095f9e...
#3

It feels to me like distributing storage is more or less a solved issue, meaning a method for utilizing open source software like https://garagehq.deuxfleurs.fr/ over a Reticulum network would be very useful. Currently it almost seems like a perfect fit.

But, distributed compute is a much harder problem as I understand it. Existing methods for confidential compute are either incredibly slow (+500% overhead) or have known drawbacks like TEE. Though the exploits made available for TEE are certainly difficult to utilize in-practice.

falafool 498e462afc534ace...
#4

cool, i think creating a distributed cloud storage with strangers on here, and maybe even with topics would be very fun and useful.

Anonymous
#5

falafool wrote:

I have had this idea of distributed cloud storage over reticulum, where
communities can contribute their storage for one big cloud storage.

And i think the idea is worth exploring, generally distributed cloud systems be it computing power, storage or other might be a good match for reticulum.
Or maybe not? What do you think can such system be closely integrated into a network protocol such as reticulum, or are they quite independent?

Hope we get to spitballs some ideas of concepts and implementations

Just a thought there wasa concept called filecoin way back the issue became use case at the time storage was cheaper than dirt and still is relatively on expensive. There was also the worry of nefarious things being on you drive implicating you so not sure how it faired. Much like other crypto endeavors i think its dwindled from reality. The idea wasnt bad though it used the coin to pay node hosts for the storage. More trusted and reliable your node and more you stored more you got from the pool

steveplays daf042c1c000a24b...
#6

Relevant thread: LXMF Content Destinations (started by kaedon; 14/08/2026)

I'll have to test this, but I was thinking of a program that announces itself with an average announce frequency (6h), so peers can know a node is hosting the program. The program could send a list of hashes of folders, files and data blocks on request (to not cause announces to be multiple MiB when a node has a large amounts of hashes). All hashes would be unique, like in IPFS, so links can be created using hashes. Data blocks are hashed in 1 KB blocks, or maybe eventually variable block size would be useful, if 1 KB is too small/big. I suppose it depends on the file type, how often the file is changed and how large the edits are at once.
I drafted up a simple commutative history system based on Pijul as well, where changes are put into a directed acyclic graph using an insertion or deletion operation, referencing bytes or containing the actual bytes, to prevent duplication of data. This also allows for storing moved bytes without requiring the bytes themselves to be duplicated in history. History could be signed using a Reticulum Identity, so it can be (partially) verified.
Repositories are just collections of files. Node operators decide which files they host and mirror from other nodes. I don't know how to allow for branches yet, like in Git repositories. I was thinking that a single folder/file can only have a single history, to keep the implementation simple, but while writing this I realized that does not allow for creating branches (and thus no forks). That's a problem.

I need to put a lot of this into my actual draft document in clear writing and put more thought into it, so it's a bit vague for now, but I'm curious to hear the thoughts on this. A system like this would be super nice to have on Reticulum, for various use-cases.

burger ace748e1c4e3fd4e...
#7

good idea but pls read the zen :3

Post a Reply

Supports Markdown: **bold**, *italic*, `code`, ```code blocks```, [links](url)

Log in to upload images

Quote
Copied to clipboard