-======================
+.. -*- coding: utf-8-with-signature -*-
+
Welcome to Tahoe-LAFS!
======================
-Welcome to `Tahoe-LAFS <https://tahoe-lafs.org>`_, the first decentralized
-storage system with *provider-independent security*.
+Welcome to Tahoe-LAFS_, the first decentralized storage system with
+*provider-independent security*.
+
+.. _Tahoe-LAFS: https://tahoe-lafs.org
What is "provider-independent security"?
========================================
another customer or to the public, or can corrupt your data. Criminals
routinely gain illicit access to corporate servers. Even more insidious is
the fact that the employees themselves sometimes violate customer privacy out
-of carelessness, avarice, or mere curiousity. The most conscientious of
+of carelessness, avarice, or mere curiosity. The most conscientious of
these service providers spend considerable effort and expense trying to
mitigate these risks.
What we mean by "security" is something different. *The service provider
-never has the ability to read or modify your data in the first place --
-never.* If you use Tahoe-LAFS, then all of the threats described above are
-non-issues to you. Not only is it easy and inexpensive for the service
-provider to maintain the security of your data, but in fact they couldn't
-violate its security if they tried. This is what we call
-*provider-independent security*.
+never has the ability to read or modify your data in the first place: never.*
+If you use Tahoe-LAFS, then all of the threats described above are non-issues
+to you. Not only is it easy and inexpensive for the service provider to
+maintain the security of your data, but in fact they couldn't violate its
+security if they tried. This is what we call *provider-independent
+security*.
This guarantee is integrated naturally into the Tahoe-LAFS storage system and
doesn't require you to perform a manual pre-encryption step or cumbersome key
management. (After all, having to do cumbersome manual operations when
storing or accessing your data would nullify one of the primary benefits of
-using cloud storage in the first place -- convenience.)
+using cloud storage in the first place: convenience.)
Here's how it works:
-.. image:: https://tahoe-lafs.org/~zooko/network-and-reliance-topology.png
+.. image:: network-and-reliance-topology.svg
A "storage grid" is made up of a number of storage servers. A storage server
has direct attached storage (typically one or more hard disks). A "gateway"
-uses the storage servers and provides access to the filesystem over HTTP(S)
-or (S)FTP.
+communicates with storage nodes, and uses them to provide access to the
+file store over protocols such as HTTP(S), SFTP or FTP.
+
+Note that you can find "client" used to refer to gateway nodes (which act as
+a client to storage servers), and also to processes or programs connecting to
+a gateway node and performing operations on the grid -- for example, a CLI
+command, Web browser, SFTP client, or FTP client.
Users do not rely on storage servers to provide *confidentiality* nor
*integrity* for their data -- instead all of the data is encrypted and
the user connects to it over HTTPS or SFTP. This means that the operator of
the gateway can view and modify the user's data (the user *relies on* the
gateway for confidentiality and integrity), but the advantage is that the
-user can access the filesystem with a client that doesn't have the gateway
+user can access the file store with a client that doesn't have the gateway
software installed, such as an Internet kiosk or cell phone.
Access Control
==============
-There are two kinds of files: immutable and mutable. Immutable files have
-the property that once they have been uploaded to the storage grid they can't
-be modified. Mutable ones can be modified. A user can have read-write
-access to a mutable file or read-only access to it (or no access to it at
-all).
+There are two kinds of files: immutable and mutable. When you upload a file
+to the storage grid you can choose which kind of file it will be in the
+grid. Immutable files can't be modified once they have been uploaded. A
+mutable file can be modified by someone with read-write access to it. A user
+can have read-write access to a mutable file or read-only access to it, or no
+access to it at all.
A user who has read-write access to a mutable file or directory can give
another user read-write access to that file or directory, or they can give
link, then anyone who has either read-write or read-only access to the parent
directory can gain read-only access to the child.
-For more technical detail, please see the `the doc page
-<https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc>`_ on the Wiki.
+For more technical detail, please see the `the doc page`_ on the Wiki.
+
+.. _the doc page: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Doc
Get Started
===========
-To use Tahoe-LAFS, please see `quickstart.rst <quickstart.rst>`_.
+To use Tahoe-LAFS, please see quickstart.rst_.
+
+.. _quickstart.rst: quickstart.rst
License
=======
-You may use this package under the GNU General Public License, version 2 or,
-at your option, any later version. See the file `COPYING.GPL
-<../COPYING.GPL>`_ for the terms of the GNU General Public License, version
-2.
-
-You may use this package under the Transitive Grace Period Public Licence,
-version 1 or, at your option, any later version. The Transitive Grace Period
-Public Licence has requirements similar to the GPL except that it allows you
-to wait for up to twelve months after you redistribute a derived work before
-releasing the source code of your derived work. See the file `COPYING.TGGPL
-<../COPYING.TGPPL.rst>`_ for the terms of the Transitive Grace Period Public
-Licence, version 1.
-
-(You may choose to use this package under the terms of either licence, at
-your option.)
+Tahoe-LAFS is an open-source project; please see README.rst_ for details.
+
+.. _README.rst: ../README.rst
projects / tahoe-lafs / tahoe-lafs.git / blobdiff