summaryrefslogtreecommitdiff
path: root/docs/mail
diff options
context:
space:
mode:
authorKali Kaneko (leap communications) <kali@leap.se>2017-04-21 14:32:51 +0200
committerKali Kaneko (leap communications) <kali@leap.se>2017-04-21 14:32:51 +0200
commitbdbaebef8e9bc6e0ef58252a790d8433d5c67fe6 (patch)
tree02ba27acc308d5dd8e08f68a0c603060ef6f817e /docs/mail
parentf31b9cab88c543f6b2b3910411a872ab0636e508 (diff)
[docs] several doc updates
Diffstat (limited to 'docs/mail')
-rw-r--r--docs/mail/index.rst18
1 files changed, 9 insertions, 9 deletions
diff --git a/docs/mail/index.rst b/docs/mail/index.rst
index bd5cfa1..d906c51 100644
--- a/docs/mail/index.rst
+++ b/docs/mail/index.rst
@@ -44,20 +44,18 @@ All the underlying data storage and sync is handled by a library called
documents are stored locally as local ``sqlcipher`` tables, and syncs against
the soledad sync service in the provider.
-OpenPGP key generation and keyring management are handled by another leap
-python library: `keymanager`_.
+OpenPGP key generation, discovery, validation, and keyring management are
+handled by the ``leap.bitmask.keymanager`` module.
-See :ref:`the life cycle of a leap email <mail_journey>` for an overview of the life cycle
-of an email through ``LEAP`` providers.
.. _`Soledad`: https://leap.se/en/docs/design/soledad
.. _`u1db`: https://en.wikipedia.org/wiki/U1DB
-.. _`keymanager`: https://github.com/leapcode/keymanager/
The life cycle of a LEAP Email
------------------------------
-For a better picture, you are invited to read about :ref:`the whole journey of a mail in the LEAP system <journey>`.
+See :ref:`the life cycle of a leap email <mail_journey>` for an overview of the life cycle
+of an email through ``LEAP`` providers.
Data model
@@ -65,9 +63,11 @@ Data model
.. TODO clear document types documentation.
-The data model at the present moment consists of several *document types* that split email into different documents that are stored in ``Soledad``. The idea behind this is to
-keep clear the separation between *mutable* and *inmutable* parts, and still being able to
-reconstruct arbitrarily nested email structures easily.
+The data model at the present moment consists of several *document types* that
+split email into different documents that are stored in ``Soledad``. The idea
+behind this is to keep clear the separation between *mutable* and *inmutable*
+parts, and still being able to reconstruct arbitrarily nested email structures
+easily.
Authentication
---------------------