<div dir="ltr">I'd like to thank both Brian Warner and David Stainton for their replies to my previous message regarding the implementation details of Tahoe-LAFS. After digging into the information I was given I feel that I have a better handle on the details of Tahoe. Reading up on Merkle Trees was especially enlightening.<div><br></div><div>Something that I've been wondering since then is the complexity introduced by mutable files. In a few use cases that I've been thinking about mutability is unnecessary and potentially even a liability. How much complexity is introduced into Tahoe's design to allow for mutabile files? If mutability was eliminated from an implementation of a system based on Tahoe's design would the system become appreciably less complex?</div><div><br></div><div>In a particular use case that I'm toying with there is no valid reason for data to be modified once it has been stored. Deletion of old data is the only case where a file/dataset would be useful. Essentially, I'm interested in using a Tahoe based system as a temporary store until the data in question can be moved to a more permanent store.</div><div><br></div><div>The reason that I ask about the complexity of the implementation is that I would likely need to port Tahoe's code to a language other than Python. I'm interested in using Tahoe or a Tahoe derived system on a system of distributed microcontroller based devices where running a Python interpreter would be difficult if not impossible. </div><div><br></div><div>Has anyone attempted an implementation of Tahoe's userspace components in a compiled language? C/C++, Go, Rust, etcetera?</div><div><br></div><div>Thank you for your time,</div><div><br></div><div>Adam</div></div>