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.