hello from the Tahoe-LAFS project

61 views
Skip to first unread message

Zooko O'Whielacronx

unread,
Dec 20, 2010, 1:35:14 AM12/20/10
to unho...@googlegroups.com
Hi there! I love the idea and it is neat to see how many other people
love the idea. Also, you have a beautiful logo. :-)

I'm one of the developers on the Tahoe-LAFS project --
http://tahoe-lafs.org . Tahoe-LAFS is a secure distributed cloud
storage system. All of the data is encrypted and digitally signed
before it is uploaded and spread redundantly across a set of storage
servers, so the user isn't vulnerable to the owners of the storage
servers snooping on or corrupting their data.

The API to read and write data is a RESTful HTTP protocol, so it is
possible for JavaScript web apps to load and store their code and data
on Tahoe-LAFS. The result is what I call "a decentralized web app".
All of the application-specific computation is done in JavaScript in
the user's browser, and all of the storage is encrypted, digitally
signed, and decentralized. There is no server! At least, no server the
failure of which can damage, corrupt, or take down the web app.

My blog is an example of this kind of software:

http://pubgrid.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html

Now, the "pubgrid.tahoe-lafs.org" in that URL should make you wonder
-- isn't that a server that my blog relies on? Well, that thing is a
stateless process which doesn't store any of the actual data and which
is easily replaced. If you download Tahoe-LAFS onto your local system
and build it (http://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.html
), then you can replace "pubgrid.tahoe-lafs.org" with "127.0.0.1:3456"
and get the same result:

http://127.0.0.1:3456/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/blog.html

I don't really understand the architecture of unhosted yet, but since
unhosted and Tahoe-LAFS have similar high-level goals, I hope it is
possible to combine the two tools.

The API for manipulating data stored in Tahoe-LAFS is documented here:

http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/frontends/webapi.rst

Regards,

Zooko

pir...@gmail.com

unread,
Dec 20, 2010, 3:21:31 AM12/20/10
to unho...@googlegroups.com
> I'm one of the developers on the Tahoe-LAFS project --
> http://tahoe-lafs.org . Tahoe-LAFS is a secure distributed cloud
> storage system. All of the data is encrypted and digitally signed
> before it is uploaded and spread redundantly across a set of storage
> servers, so the user isn't vulnerable to the owners of the storage
> servers snooping on or corrupting their data.

It's ironic that now that i'm working at my own custom file system at
my sparse time one of the developers of Tahoe want to collaborate on
UnHosted... :-P

> I don't really understand the architecture of unhosted yet, but since
> unhosted and Tahoe-LAFS have similar high-level goals, I hope it is
> possible to combine the two tools.

At this moment UnHosted storage structure is simply related to GET/SET
methods of key-value pairs (apart from SEND/RECEIVE methods for
messages) as a proof of concept, but we are at version 0.1 so it will
probably grow up in the future.

--
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

Michiel de Jong

unread,
Dec 20, 2010, 4:01:21 AM12/20/10
to unho...@googlegroups.com
Tahoe-LAFS was the inspiration for unhosted, and it's an honour to get an email from you on our project list.

All unhosted defines, is the UJ/0.1 protocol which (as Piranna already said) is just GET and SET for key/value use, plus SEND/RECEIVE for messaging use.

Originally, the unhosted storage node was going to be a tahoe-LAFS cluster. But since the protocol is so simple, for the proof-of-concept I just implemented a quick-and-dirty php-script that acts as a storage node. I heard on twitter that people are working on a node.js-based storage node. Obviously, in the future it would be great if we can have a tahoe-LAFS based storage node (as was the original plan, but not done yet because of time restraints and focus on other priorities). 

There are some issues in how this could work sensibly. It doesn't make any sense to do a DHT on top of a DHT, for instance. Once our alpha-launch was announced on The H Online, i was hoping to go to the beach. But there is so much discussion on twitter, reddit, HackerNews, tweakers.net, some Albanian site I cannot really read, and now I also need to go check out barrapunto. :) So these few days I think I'll mainly be answering comments and thinking about all the things people say. There are a lot of encouraging replies, and also some really good comments I hadn't thought about. Then when things quiet down a little bit, I will sit down and think about if and how an unhosted storage node could be strictly tahoe-LAFS based.

Cheers!
Michiel
Reply all
Reply to author
Forward
0 new messages