Better to split the designs

README.md

@@ -4,11 +4,13 @@ A digital life memoir of your life
 
 ## Design
 
-The main design is to have a Store application, which manages its storage. Then other services are used to capture data from services and throw to Store, or retrieve information for Store to be displayed.
+The main design is to have a [Store](design/store.md) application, which manages its
+storage. Then other services are used to capture data from services and throw
+to Store, or retrieve information for Store to be displayed.
 
 Currently, I'm considering the following Captures (based on my own life):
 
-- [ ] Mastodon
+- [ ] [Mastodon](design/mastodon.md)
 - [ ] RSS
 - [ ] Guild Wars 2
 - [ ] Steam Capturer (?)
@@ -16,35 +18,6 @@ Currently, I'm considering the following Captures (based on my own life):
 - [ ] Deezer
 - [ ] Calendar/CalDav
 
-### Store
-
-The main application that keeps information. We would probably need a design like:
-
-- id: UUID of the record
-- title: String, produced by a Capturer
-- content: Text, produced by a Capturer, must always be Markdown (to avoid having a format that needs to be specially processed by some viewer)
-- source: Name of the Capturer
-- meta: HashMap, with some information the Capturer has about the entry
-
-### Mastodon Capturer
-
-There are two options for a Mastodon Capturer: A pure RSS reader or a full-fledged Mastodon client. A client would probably capture things send in private and such, which seem better.
-
-Need to store, locally:
-
-- id: Toot ID
-
-We need only the ID 'cause we don't want to duplicate content; once the client finds a toot in its own database, it stops reading from the source and don't send it to the Store.
-
-As content send to the Store, we'd use a template like
-
-```
-{% if content_warning %}
-  ({{ content_warning}})
-{% endif %}
-
-{{ content }}
-```
 
 ### RSS Capturer
 

design/mastodon.md

@@ -0,0 +1,23 @@
+# Mastodon
+
+There are two options for a Mastodon Capturer: A pure RSS reader or a
+full-fledged Mastodon client. A client would probably capture things send in
+private and such, which seem better.
+
+Need to store, locally:
+
+- id: Toot ID
+
+We need only the ID 'cause we don't want to duplicate content; once the client
+finds a toot in its own database, it stops reading from the source and don't
+send it to the Store.
+
+As content send to the Store, we'd use a template like
+
+```
+{% if content_warning %}
+  ({{ content_warning}})
+{% endif %}
+
+{{ content }}
+```

design/store.md

@@ -0,0 +1,13 @@
+# Store
+
+The Store is the central point of the application. It is responsible for
+keeping all the information sent by Capturers and providing a search/list
+functionality for Viewers.
+
+We would probably need a design like:
+
+- id: UUID of the record
+- title: String, produced by a Capturer
+- content: Text, produced by a Capturer, must always be Markdown (to avoid having a format that needs to be specially processed by some viewer)
+- source: Name of the Capturer
+- meta: HashMap, with some information the Capturer has about the entry