Tahoe Integration Questions
meejah at meejah.ca
Tue Feb 27 18:09:38 UTC 2018
procmem <procmem at riseup.net> writes:
> I envision making whonixcheck ping a Tahoe share instead which would
> essentially decentralize hosting while preserving message integrity
> and immutability.
One way you could organize this would be to have a write capability for
a mutable file controlled by Whonix devs. Then you give out a read
capability for this to "whonixcheck" and it can download the file and
will see any updates you've made to it.
You could even have this mutable file point to immutable files
containing actual releases if you wanted to also use the grid to deploy
> There is probably a few nifty things we can do with magic
> folders too but I don't know if this made into the Tahoe version before
> the Debian stable freeze.
Magic-Folders is probably not the right tool for this.
> What public/volunteer Tahoe grids can we use?
> Are there any known onion Tahoe grids?
There was one operating, but I'm not sure if it still is. Hopefully
someone can chime in here?
> Do you mind if we use your test grid? If not, then where can I find the
> latest info on the introducer? (wiki pages seemed outdated)
If you ask in #tahoe-lafs on Freenode I think there's a grid you can use
Tahoe currently doesn't have a "global"/"one true grid"
deployment. Existing grids are operated for their own reasons, etc.
One model for Whonix might be to have volunteers operate storage nodes
specifically for your Whonix grid. This would be sort of like the
concept of "running a mirror" for distribution services.
This should be done with some care: if there's lots of churn in
available storage-servers, then files can become un-accessible or
un-recoverable depending on the encoding options chosen.
More information about the tahoe-dev