Hi! I'm a developer on the Tahoe-LAFS project. On Wed, Feb 8, 2012 at 3:57 AM, Josef Spillner <2005@kuarepoti-dju.net> wrote:

A conceptual difference is that Tahoe is targeting homogeneous storage networks, where access to the servers is assumed because they also need to run Tahoe software, whereas NubiSave goes to great lengths (e.g. by contributing new FUSE modules to fuse.sf.net) to be able to talk to existing online storage providers despite their (often found) inability or unwillingness to be talked to in a uniform way.

A second conceptual difference is that Tahoe is more of a (static) RAIC and NubiSave more of a (dynamic) RAOC, where means that security can be traded for cost or proximity can be traded for signup privacy. This mechanism relies on formal provider descriptions.

I don't understand this, and can't say whether I think these two differences correctly apply to Tahoe-LAFS or not.

A practical difference is that Tahoe looks like a genuine engineering project, so it is available for more platforms, has better testing, and certainly an existing user base.

Thank you! We certainly work hard at making it reliable and secure. We're also open to accepting patches that make Tahoe-LAFS better for your use-case, as long as it doesn't complicate or destabilize the use-cases of others. Also, I love the idea of the FreedomBox and would like to see it become useful to a large number of people. The basic idea of serving storage from a FreedomBox doesn't sound incompatible with Tahoe-LAFS architecture to me. One thing that I would be careful of is not to try to use adhoc storage servers whose only qualification is "they managed to turn it on and run the software". This sort of principle of inclusion works great for transfer, e.g. Bittorrent, but not for storage. Unqualified nodes are too numerous and too unreliable to be any use for storage. They do more damage than good. I speak from long and hard experience, having been an architect of several successive notable failed projects, each of which attempted to take advantage of unqualified, random nodes to provide storage. But, FreedomBox storage servers do not have to be adhoc, unqualified storage servers. Anything which serves to filter out most of the 99% of bad servers would do. Possible ways to filter which storage servers you'll upload your ciphertext to: 1. The storage client has to manually add the storage server ID to a list of storage servers that she is willing to entrust ciphertext to. (This is basically what Tahoe-LAFS already offers, although it is currently mediated by a centralized thing called the "introducer".) 2. The storage server has to be blessed by some trusted authority before the storage clients will use it. (Again, the current introducer could sort of be pressed into service for this, but we're actively working on upgrading that to a more decentralized, flexible, and secure solution.) 3. The storage server has to have some aggregate "good reputation" among some collection of users. 4. The storage server is owned by someone in your social network. :-) I like this idea. When you befriend someone, that automatically grants them a certain amount of storage space on your FreedomBox. 6. The storage server has to demonstrate 30 consecutive days of better than 95% uptime before the storage client will entrust storage to it. 7. The storage server has to give a micropayment, let's say one dollar or one Bitcoin, to the client before the client will start using it. Then, the client will start paying the server for service. Within a few weeks or months the server will have earned back its dollar plus more. But, the initial requirement of a payment in the wrong direction serves to filter out most of the 99% of servers that are completely useless. I just came up with this crazy notion just now. I would encourage people interested in hacking on FreedomBox to try installing Tahoe-LAFS on it and give it a spin. There's nothing like practical, hands-on experience to inform your ideas. However, while you're waiting for it to run its extensive and time-consuming unit tests, you could also browse some hifalutin ideas: https://tahoe-lafs.org/pipermail/tahoe-dev/2011-February/006150.html http://lists.zooko.com/pipermail/p2p-hackers/2011-February/002906.html http://lists.zooko.com/pipermail/p2p-hackers/2011-August/002979.html http://lists.zooko.com/pipermail/p2p-hackers/2011-August/002986.html Regards, Zooko _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- 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