Folks: I remember getting angry about this topic the last time we discussed it. It's strange how I get all hot under the collar about minor technical details such as the default erasure coding parameters in a secure distributed storage system. Anyway, the topic has come up again. I just posted this note on the ticket: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1082#comment:12 Regards, Zooko ------- This issue came up again. Omnifarious on IRC was explaining why he was giving up on his attempt to play with Tahoe-LAFS: <Omnifarious> Yeah, I have to create a bunch of storage nodes (I think) and I think an introducer and figure out what the introducers furl is or something. Also I was hanging out with Brian Warner a couple of nights ago and he tried to upload a file to a newly created test grid with only one server and was annoyed that it didn't work. For what it is worth, I have spent a lot of time over the years talking to people who deploy Tahoe-LAFS and paying attention to the process they go through and especially to what deters them or trips them up. I've probably learned about the experiences of more than 100 different people who've deployed, or attempted to deploy, Tahoe-LAFS over the last five or so years. I doubt that even one of those people would have accidentally used K=H=N=1 in their production grid without realizing the reliability implications. I think every one of them would have chosen to change K, H, and N after testing it out and before starting to rely on it for long-term storage. Therefore, I would like to re-open this dormant ticket and *strongly* suggest that we change the default values of K, H, N from 3, 7, 10, to 1, 1, 1, and we change the documentation to warn that if you want the erasure-coding features of Tahoe-LAFS then you have to choose your own K, H, and N based on your personal preferences and the shape of your grid. In addition to believing that this will not harm almost any users who are relying on Tahoe-LAFS for safe, long-term storage, and in addition to believing that this will greatly help newcomers who are trying to experiment with Tahoe-LAFS in a few spare minutes of their time, I also believe that it will help people understand the extremely important security properties of Tahoe-LAFS, most of which are actually independent of the erasure coding and are best understood without the complication of the erasure coding. _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE