[Social-mediagoblin] Tahoe-LAFS as a document-oriented database

[Zooko O'Whielacronx]

Folks:

There is a discussion on the Tahoe-LAFS mailing list about how
Tahoe-LAFS could be used for storing assets such as media files.

http://tahoe-lafs.org/pipermail/tahoe-dev/2011-April/006257.html

I want to emphasize that I'm not "pushing" for social-mediagoblin to
use Tahoe-LAFS instead of using MongoDB or postgresql or whatever. I'm
sure you folks have good reasons for your choices (Chris has written
some notes about this issue) and I don't want Tahoe-LAFS to get used
in ways that it is ill-suited— that would just cause headaches for
everybody including me.

Rather, I think there are some important fundamental architectural
issues which are revealed in this conversation on the Tahoe-LAFS
mailing list. Regardless of which actual technologies we use, we
should understand and make conscious decisions about these
architectural issues.

Namely:

1. On what do you rely for the guarantee that the file is uncorrupted?
There are basically two use cases: you store a file yourself and get
it back later, or you share a file with someone else. In the former
you want to be sure that you get back the same file you put in. In the
latter the recipient wants to be sure that they get the same file the
sharer sent.

2. Is there a guarantee of confidentiality—that people who weren't
intended to see the file can't see it? If so, on what do you rely for
that guarantee?

3. Performance questions about clusters of servers and clients. May or
may not be relevant to socialmediagoblin.

Thank you for your attention.

Regards,

Zooko