fixing headings in Part 5

Author: aphelionz

05_Customizing_OrbitDB/00_Introduction.md

@@ -1,4 +1,4 @@
-# Customizing OrbitDB
+# Part 5: Customizing OrbitDB
 
 In the first chapter of this Field Manual,
 we described how you might create

05_Customizing_OrbitDB/01_Definitions.md

@@ -1,4 +1,4 @@
-# What are Stores, AccessControllers and Indicies.
+## What are Stores, AccessControllers and Indicies.
 
 Before we start to implement
 our custom store, access controller, and index
@@ -7,7 +7,7 @@ notes, we should probably define what a `Store`,
 `AccessController`, and `Index` are and what
 function they have in OrbitDB.
 
-## The Store
+### The Store
 
 You have already worked with several
 Stores in the Tutorial.
@@ -22,7 +22,7 @@ functions to access them, like `get`, `put` or `set`,
 with which you could easily interact with
 the database itself.
 
-## The Index
+### The Index
 
 But a store doesn't actually
 store the current state of the database in the RAM,
@@ -37,7 +37,7 @@ of the current state of the database.
 The index is then used by the `Store`
 to implement its API.
 
-## The Access Controllers
+### The Access Controllers
 
 Access Controllers or short ACL (Access Control List)
 were already discussed [02: Managing Data](../01_Tutorial/02_Managing_Data).

05_Customizing_OrbitDB/02_Choosing_a_data_structure.md

@@ -1,4 +1,4 @@
-# Choosing a data structure
+## Choosing a data structure
 
 Let's start implementing a comment system
 by choosing how we want to represent the
@@ -12,7 +12,7 @@ implementing the Access Controller,
 since the Access Controller is very
 much independent from the Store and Index.
 
-## Requirements
+### Requirements
 
 Our data structure should achieve two things:
 
@@ -25,7 +25,7 @@ Each tree's root would be the Notes pieces and the
 children of that root would be the comments,
 the comments comments and so on and so on.
 
-## Generating the Trees from the `ipfs-log`
+### Generating the Trees from the `ipfs-log`
 
 Before starting to implement this data structure,
 we'll also have to consider, how to generate
@@ -47,17 +47,17 @@ For our purposes there can be these operations:
 
 This seems pretty straight forward.
 
-## What happens when we delete notes or comments, with all those comments referring to them?
+### What happens when we delete notes or comments, with all those comments referring to them?
 
 I propose using a simple rule: If a comment or piece of notes
 is deleted, all those refering to it are deleted too.
 Otherwise this tutorial becomes a complicated mess.
 
-# Implementing the Index.
+## Implementing the Index.
 
 Let's start by adding a new file to your project folder (if you haven't yet created one, do that now).
 
-## Isomorphic Bookends.
+### Isomorphic Bookends.
 
 You know the drill, before starting with the actual implementation
 of the Index, we have to define the bookends, that make our code
@@ -79,7 +79,7 @@ libraries from OrbitDB.
 
 It is using duck typing, instead of inheritance.
 
-## Defining the `NotesIndex` class.
+### Defining the `NotesIndex` class.
 
 Next, let's define the actual class
 of the `NotesIndex`.
@@ -96,7 +96,7 @@ class NotesIndex {
 We initialize the index to an empty object at first, because
 we don't yet have any data.
 
-## Defining the `TreeNode` helper class.
+### Defining the `TreeNode` helper class.
 
 After this, let's first implement our own `TreeNode` data type,
 that'll be used to represent the trees mentioned above.

05_Customizing_OrbitDB/03_Defining_the_Index.md

@@ -1,4 +1,4 @@
-# Defining the Index
+## Defining the Index
 
 In the last chapter we
 considered how we
@@ -19,7 +19,7 @@ actually define the Index
 or what makes the `NotesIndex`
 class an `Index`.
 
-## A few utility functions.
+### A few utility functions.
 
 Let's first define a few
 utility functions for fetching content from
@@ -33,7 +33,7 @@ The last will be very helpful to UI Designers
 who have the crucial task of translating this data structure into
 pleasant UI.
 
-### `getNotes`
+#### `getNotes`
 
 But let's start with a simple `NotesIndex.getNotes` function.
 
@@ -47,7 +47,7 @@ We fetch the tree with that CID and then only
 care for the `data` field of the `TreeNode`, because
 that's where the sheet music is actually stored.
 
-### `getComments`
+#### `getComments`
 
 Now implement the `NotesIndex.getComments(cid)` function like this:
 
@@ -61,7 +61,7 @@ Get comments is almost entirely identical to `getNotes`, except
 that we don't return the `data`, but the `children` field of
 the `TreeNode`.
 
-### `getComments` with chronological order
+#### `getComments` with chronological order
 
 Now, let's get to our third and final `get` functions: `getComments`,
 but now with an argument: `flat = true`.
@@ -90,7 +90,7 @@ getComments(cid, flat = true) {
 
 Replace the `getComments` function above, by this.
 
-#### What happens here?
+##### What happens here?
 
 We first define a helper function `flatten`, which goes
 through the array of children and adds each node
@@ -99,7 +99,7 @@ Then we sort it based on an id field in ascending order.
 If you pass in `flat = false`, you'll still get the old
 behavior.
 
-### The `updateIndex` function
+#### The `updateIndex` function
 
 Up until this point, we have been
 writing utility functions that are
@@ -168,7 +168,7 @@ Index can handle:
 - `ADDCOMMENT` to add a comment to a piece of notes or some other comments.
 - `DELETECOMMENT` to delete a comment.
 
-### Implementing `ADDNOTES` handling
+#### Implementing `ADDNOTES` handling
 
 Add notes is by far the simplest operation to handle,
 since we just need to add a new `TreeNode` to the `_index`.
@@ -180,7 +180,7 @@ case "ADDNOTES":
   break;
 ```
 
-### Implementing `DELETENOTES` handling
+#### Implementing `DELETENOTES` handling
 
 And deleting notes is the inverse:
 
@@ -191,7 +191,7 @@ case "DELETENOTES":
   break;
 ```
 
-### Implementing `ADDCOMMENT` handling
+#### Implementing `ADDCOMMENT` handling
 
 Adding comments is a little more complicated.
 We first have to find the parent of the comment in the notes
@@ -254,7 +254,7 @@ After this, the `TreeNode` that is referred to by the Operator's
 And at last, we store the created `TreeNode`, in `_comments`
 for later.
 
-### Implementing `DELETECOMMENT` handling
+#### Implementing `DELETECOMMENT` handling
 
 After the monster of a branch above, this case is
 pretty relaxing in comparison:
@@ -267,7 +267,7 @@ case "DELETECOMMENT":
   break;
 ```
 
-## Conclusion
+### Conclusion
 
 We have now defined the complete
 `Index` for the comment system.

05_Customizing_OrbitDB/04_Defining_the_Store.md

@@ -1,4 +1,4 @@
-# Defining the Store
+## Defining the Store
 
 We now have our own
 `Index` in `NotesIndex.js`.
@@ -29,12 +29,12 @@ Tutorial in this Manual.
 Because there are five built-in
 stores, which will I not bother recounting here.
 
-# The `NotesStore` class
+### The `NotesStore` class
 
 You should now add a new JavaScript file
 and call it `NotesStore.js`.
 
-## Isomorphic Bookends
+#### Isomorphic Bookends
 
 For the third time in this Manual:
 Let's define an isomorphic bookend:
@@ -58,7 +58,7 @@ try {
 
 We'll from now on be working inside the `notesStore` function.
 
-## Defining the `NotesStore` class
+### Defining the `NotesStore` class
 
 To define a Store, we have to extend
 an existing Store class.
@@ -84,7 +84,7 @@ class NoteStore extends OrbitDB.EventStore {
 return NoteStore
 ```
 
-### What is happening here?
+#### What is happening here?
 
 The Store receives four parameters in it's `constructor`:
 
@@ -101,7 +101,7 @@ the options already has an `Index` specified.
 Besides this, all stores have to have a `type` property,
 to uniquely identify the `NotesStore`.
 
-## Defining a `getNotes` and `getComments`
+### Defining a `getNotes` and `getComments`
 
 We should probably implement a few get
 functions. But this is really low effort,
@@ -123,7 +123,7 @@ As you can see, `this._index` is an instance of the `NotesIndex`,
 if no other Index was passed in to the constructor,
 and we can easily access the methods we defined in the Index.
 
-## Adding Data to the Store
+### Adding Data to the Store
 
 Now, let's finally add some data
 to our Store.
@@ -203,7 +203,7 @@ prior to adding an operation:
 - Formatting (with Protobuf)
 - Encryption and Decryption
 
-### Adding Comments
+#### Adding Comments
 
 After a user added their
 musical notes to their Database,
@@ -239,7 +239,7 @@ information about the auther.
 See the [Implementing `ADDCOMMENT` handling](03_Defining_the_Index.md#Implementing-ADDCOMMENT-handling)
 section of the previous chapter.
 
-# Other Stores
+## Other Stores
 
 You might note that this is a very complicated
 custom store and index.
@@ -256,7 +256,7 @@ can be very illuminating and inspiring.
 I would advice reading the [`EventIndex.js`](https://github.com/orbitdb/orbit-db-eventstore/blob/main/src/EventIndex.js)
 and the [KVStore's Store and Index files](https://github.com/orbitdb/orbit-db-kvstore/blob/main/src/).
 
-# Key Takeaways
+## Key Takeaways
 
 - Stores inherit from each other. So you can extend built-in stores.
 - Stores work with the `Index` and the `this._addOperation` mostly.

05_Customizing_OrbitDB/05_Conclusion.md

@@ -1,4 +1,4 @@
-# On Customizing OrbitDB
+## On Customizing OrbitDB
 
 In conclusion this
 part of the Field
@@ -35,7 +35,7 @@ and has no time to bother
 about CRDTs, `oplogs` and
 other such complexities.
 
-# Where to go from here?
+### Where to go from here?
 
 The source code in this
 tutorial is incomplete

05_Customizing_OrbitDB/06_AccessControllers.md

@@ -1,4 +1,4 @@
-# Moderating your Comment Threads.
+## Moderating your Comment Threads.
 
 We have now gotten a store that
 you can publish notes and comments with.

05_Customizing_OrbitDB/07_Implementing_a_custom_AccessController.md

@@ -1,4 +1,4 @@
-# Implementing a custom Access controllers
+## Implementing a custom Access controllers
 
 And after these things, let us now consider
 how we might implement a custom access controller.
@@ -11,10 +11,12 @@ to implement:
 - The author of a comment and the creator can delete a comment.
 - The creator can ban somebody from commenting on the entire database.
 
-## Implementation
+### Implementation
 
 Similarly to the `Store`s,
 Access Controllers are implemented
 using inherited classes.
 Let's implement a `NotesAccessController.js`
 file with these Isomorphic bookends:
+
+**Note:** TBD