From acfe776f00f10a4ad700796993eef1b989432e91 Mon Sep 17 00:00:00 2001
From: drebs <drebs@riseup.net>
Date: Tue, 3 Oct 2017 12:53:17 -0300
Subject: [doc] add intro section with reviwed content from old doc

---
 docs/intro/goals.rst | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)
 create mode 100644 docs/intro/goals.rst

(limited to 'docs/intro/goals.rst')

diff --git a/docs/intro/goals.rst b/docs/intro/goals.rst
new file mode 100644
index 00000000..0429e44b
--- /dev/null
+++ b/docs/intro/goals.rst
@@ -0,0 +1,72 @@
+Goals
+=====
+
+Security goals
+--------------
+
+* **Client-side encryption:** Before any data is synced to the cloud, it should
+  be encrypted on the client device.
+
+* **Encrypted local storage:** Any data cached in the client should be stored
+  in an encrypted format.
+
+* **Resistant to offline attacks:** Data stored on the server should be highly
+  resistant to offline attacks (i.e. an attacker with a static copy of data
+  stored on the server would have a very hard time discerning much from the
+  data).
+
+* **Resistant to online attacks:** Analysis of storing and retrieving data
+  should not leak potentially sensitive information.
+
+* **Resistance to data tampering:** The server should not be able to provide
+  the client with old or bogus data for a document.
+
+Synchronization goals
+---------------------
+
+* **Consistency:** multiple clients should all get sync'ed with the same data.
+
+* **Selective sync:** the ability to partially sync data. For example, so
+  a mobile device doesn’t need to sync all email attachments.
+
+* **Multi-platform:** supports both desktop and mobile clients.
+
+* **Quota:** the ability to identify how much storage space a user is taking up.
+
+* **Scalable cloud:** distributed master-less storage on the cloud side, with
+  no single point of failure.
+
+* **Conflict resolution:** conflicts are flagged and handed off to the
+  application logic to resolve.  Usability goals
+
+* **Availability:** the user should always be able to access their data.
+
+* **Recovery:** there should be a mechanism for a user to recover their data
+  should they forget their password.
+
+Known limitations
+-----------------
+
+These are currently known limitations:
+
+* The server knows when the contents of a document have changed.
+
+* There is no facility for sharing documents among multiple users.
+
+* Soledad is not able to prevent server from withholding new documents or new
+  revisions of a document.
+
+* Deleted documents are never deleted, just emptied. Useful for security reasons, but could lead to DB bloat.
+
+Non-goals
+---------
+
+* Soledad is not for filesystem synchronization, storage or backup. It provides
+  an API for application code to synchronize and store arbitrary schema-less
+  JSON documents in one big flat document database. One could model
+  a filesystem on top of Soledad, but it would be a bad fit.
+
+* Soledad is not intended for decentralized peer-to-peer synchronization,
+  although the underlying synchronization protocol does not require a server.
+  Soledad takes a cloud approach in order to ensure that a client has quick
+  access to an available copy of the data.
-- 
cgit v1.2.3