Hi, I'm a Tahoe-LAFS core dev. I'm excited about the possibility of
Tahoe-LAFS becoming really useful to Tails users, and I'm grateful to
others, especially David Stainton, for moving this forward.
On Sun, Jun 1, 2014 at 12:46 PM, David Stainton <dstainton415@???> wrote:
>> Tahoe documentation could mention this:
>> https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/quickstart.rst
>
> OK... I volunteer to update
> https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/quickstart.rst
> to mention install Tahoe-LAFS using the Debian package.
Well, hold on, if people start by going to the Tahoe-LAFS home page
(
https://Tahoe-LAFS.org), then they see a prominent big blue button
labeled "Download Tahoe-LAFS". If they click that button, it takes
them to
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Installation ,
which prominently advertises Debian (as well as Ubuntu, Arch Linux,
NetBSD, Slackware, SmartOS, and NixOS), and which *less* prominently
offers a hyperlink named "Run this release from source." which takes
them to the quickstart.rst.
So, it seems like if they got to the quickstart.rst from that path,
then they don't really need an added link or text on quickstart.rst
pointing them back the way they came!
What if they got to the quickstart.rst from a different path? Well, my
first suggestion would be to find the thing that pointed them to
quickstart.rst, and have it point them to
https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Installation instead.
>>> 2. Tails persistent volume assistant feature additions:
>
>> It's good to have a concrete integration proposition! Looks good to me
>> (understandable and usable), but i'm curious about other people's
>> opinions. And... would that not be better to have, like you propose, 3
>> columns, but the third being Tahoe, so users can choose to persist
>> localy, OR on Tahoe, OR both - by selecting one column, the other, or
>> both. But... Tahoe column should be grey if Tahoe has not been configured.
I'd like to raise a warning flag here to indicate that it might be a
mistake to categorize Tahoe-LAFS as being a persistence solution. It
does *not* function super well when used as a local filesystem. Think
of it instead as an alternative to SFTP. Or as an alternative to
Bittorrent, which offers an *upload* action in addition to a download
action.
Here is my write-up for how Tails users could potentially use
Tahoe-LAFS instead of SFTP:
https://labs.riseup.net/code/issues/6227#note-20
On the other hand, as that write-up suggests, Tahoe-LAFS *might* be
okay as an alternative to a (local) persistence solution, as long as
the user doesn't mind the long lags on every action, doesn't mind that
it breaks if it can't connect to the Internet, and doesn't use an app
that tries to do a lot of small writes to disk, and doesn't use an app
that times-out and gives up if its reads or writes take more than a
few seconds to complete.
So, I don't want to say "Stop! Do not go forward and experiment with
Tahoe-LAFS as a persistence tool.", because it *might* work. But I do
want to say "Why don't we use it for what we know it is good at, and
we can also do an experiment in using it as a persistence tool, and
let it be okay if that experiment fails.".
So my question for Tails devs (this is where my ignorance begins):
does Tails come with an SFTP client? Does it come with a Bittorrent
client? Can we make Tahoe-LAFS be the third thing next to those two
things?
>>> 4. Tahoe-LAFS backup GUI applet
>
> I'll be opening a Tahoe-LAFS trac ticket about this one soon.
> Of course it will have to be written for the same desktop environment
> that Tails uses.
> I agree that this is lower priority than hacking the persistent volume assistant
> and writing a Tahoe-LAFS client configuration assistant. I will work
> on those first.
I agree that Tahoe-LAFS is good for backup.
By the way, I'm the founder of a company trying to commercialize
Tahoe-LAFS, and we'd like to offer some free storage service as a way
to help this effort along. I haven't figured out how to make it useful
to Tails users (and devs) while limiting the amount of expense it
would cost us to maintain it. One idea I just had is to hack our
backend servers to reject any uploads of ciphertext files that are
larger than about 100KB. I am guessing that this might make it still
usable for config files, text documents, HTML pages, etc., but not
usable for the photo, music, and movie files that might otherwise
quickly start costing us too much to maintain. Any thoughts about
that?
(Obviously, someone could work-around that limitation by breaking
their large files into many pieces, but I assume that wouldn't happen,
at least not soon, because anyone who understands the system well
enough to do that understands that doing that would force us to
shutdown the free service, simply by ramping up our costs. If that's
their goal, they could accomplish it just as well by writing a script
to upload an infinite stream of files read from /dev/urandom.)
Regards,
Zooko Wilcox-O'Hearn
Founder, CEO, and Customer Support Rep
https://LeastAuthority.com
Freedom matters.
