create Hole Book

book/.gitignore

@@ -0,0 +1 @@
+book

book/book.toml

@@ -0,0 +1,6 @@
+[book]
+authors = ["Horhik"]
+language = "en"
+multilingual = false
+src = "src"
+title = "Hole Book"

book/src/API.md

@@ -0,0 +1,28 @@
+# Hole Frontend API
+
+## Loginning and Registration
+
+### Registration request
+On base of password will be generted keypair for signing and keypair for encoding.
+``` json
+    {
+    request_type: "registration",
+    username: "user",
+    password: "passwd123",
+    }
+```
+
+
+### Login request
+```json
+    {
+    request_type: login,
+    username: "name",
+    decode_key: "key",
+    sign_key: "key",
+    }
+```
+
+## Adding friends
+Each user have :w
+

book/src/Message-flow.md

@@ -0,0 +1,8 @@
+# Message flow
+*(pseudocode in Bash style)*
+
+Hole receiving messages by looking for new items in "user's bin" (place where new messages arrives). Because of how freenet works, we can't just say "Hey! Do I have new messages?", we can specify messages index like: "Hey! Gimme 15th message". Thus we must remember previous message index and to receive the new message we're requesting for 16th message, if we was able to get 15th message.
+
+That's mean, what interlocutor also have to know the last message index in our bin. But **how he can know it, if there's  a lot of other users who also sending messages to our bin?** Of course, you can try to receive all messages from the index, you had  last remembered, and next index, next, next... until you find the index which does not exist. But it's a freenet, it's take too much time;
+
+The solution is unique Id. User creating and giving his/her unique id to each new interlocutor. And when, if interlocutor sending the message he knows, that last message to us had index `$N` and sends message with index `$N+1`, if be more verbose, the new message index he send to us will look like `"$(ID)_($N+1)"` 

book/src/Protocol.md

@@ -0,0 +1,41 @@
+# Hole Protocol
+
+## Process of messaging
+Each user have kind of a bin among freenet network,in which anyone can put message. And for each user this bin is his `USK insert` key. Each message signed by sender. And user can answer to sender, buy putting message at sender insert key if he know it.
+
+
+## user IDs
+Each user have unique pseudonym for each user whom he communicates. Thos pseudonyms uses by user to identify who is sender end establish message flow.
+The "message flow" is important here.
+
+- [ ] Probably, for each pair of each people we will **not only one** unique  identifier but... I'm not going to do it in further releases. *TODO*
+
+## Message request
+To receive a new message we have to send `ClientGet` to our `USK request` key with URI like `/user_id-message_version`. As well, the identifier is consists of  `user_id-message_number`
+For example:
+```Bash
+ClientGet
+URI=USK@myMessageBinKey/messages/user5678-3 
+Identifier=request-user5678-3
+Verbosity=0
+ReturnType=direct
+EndMessage
+```
+
+## Message sending
+To send a message to a friend we putting it at his `USK insert` key, with URI like`/my_id-$(number_of_messages_to_this_user + 1)`. And identifier like `user_id-$(number_of_messages_to_this_user + 1)`
+For example:
+
+```Bash
+ClientGet
+URI=USK@myFriendBinKey/messages/user3246-5
+Identifier=user3501-5
+Verbosity=0
+ReturnType=direct
+EndMessage
+```
+
+
+## Adding friend
+Hole generates file, which alice have to send to bob somehow, and bob have to do the same. This file will contain unique ID and two keys
+

book/src/SUMMARY.md

@@ -0,0 +1,6 @@
+# Summary
+
+- [How it works](./chapter_1.md)
+    - [Message flow](./Message-flow.md)
+- [Protocol description](./Protocol.md)
+- [Frontend API](./API.md)

book/src/chapter_1.md

@@ -0,0 +1 @@
+# Chapter 1