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 <dstainton...@gmail.com> 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. _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
