Version 0 Progress

Signed-off-by: Harshil Jani <harshiljani2002@gmail.com>

src/SUMMARY.md

@@ -8,4 +8,5 @@
 
 [Community Bonding Period](./chapter_1.md)
 [Creating Concept for Project](./chapter_2.md)
-[Version 0](./chapter_3.md)
+[Version-0 : Matrix Side](./chapter_3.md)
+[Concrete Version-0](./chapter_4.md)

src/chapter_3.md

@@ -1,3 +1,46 @@
-# Coding Version 0 and challenges
+# Coding Version 0 and Challenges Faced
 
-It's night 3 AM and I will find some extra time to start writing with this over the weekend.
+## Kickstarting coding
+
+The very first step in developing the Matrix bridge for qaul was to attempt and create a login functionality into the matrix from the qaul code. As mentioned earlier, By reffering the `examples/` in `matrix-sdk` which was latest at `0.6.2` by the time I am writing this, I wrote a new file inside qaul-matrix-bridge binary called `relay_bot.rs` along with a `connect()` method which will allow us to connect with matrix.
+
+## Dependencies conflicts
+
+With the new `connect()` method and the `relay_bot.rs` code, compiler complaint heavily with list of errors. On debugging, The errors were about dependency version conflict.
+
+With latest `matrix-sdk 0.6.2`, Version mismatched for `libp2p` which at the time has latest `0.51.x` and qaul was using `0.50.0` and `0.52.0` was about to release officially within next upcoming month. The code was compiling if we downgrade `matrix-sdk` to `0.4.0`. But then we lose some methods which connects qaul directly with some abstraction level to matrix.
+
+I reported this to MathJud. He took some time to look at the dependency tree and figured out the exact conflicts. We were using `libp2p` at `0.50.x` and it had `libp2p-swarm-derive`. Now the `matrix-sdk` and `libp2p-swarm-derive` has two packages in common
+
+- quote
+- syn
+
+And the `syn` package had a big version number change 1->2.
+But If `libp2p` `0.52.0` gets released, It would have solved the conflict but it would require us to do some code changes to upgrade qaul to onboard `0.52.0` of libp2p. So, For inital rounds of test, We decided to stick with an older version of matrix-sdk with no change inside qaul.
+
+I have although asked the maintainers of libp2p about when they'd plan their next release in one of their open issues : [Link to discussion on `lib p2p 0.52.0` release](https://github.com/libp2p/rust-libp2p/issues/3647#issuecomment-1559944456)
+
+## Sailing the Boat
+
+I have now started coding with `matrix-sdk 0.4.0` and implemented the very first feature which listens on the room for any messages on matrix and return us back with a simple message.
+
+The `relay_bot::connect()` method were rightly used for login into matrix and listening on the matrix client for any activity or interact with it. Since this process required synchronus listening on the matrix service, It actually blocked the `qaul-cli` and has no meaning as an implementation. We needed to run both the process simultaneously and synchronously.
+
+- Keep checking for messages on matrix
+- Keep checking for messages in qaul
+
+To make both the calls on both side sync, We thought to run the process of matrix login and configuration inside a different thread. This way, the process kept running in new thread without blocking our qaul-cli. Another option was that we may have polled the matrix part inside the loop which runs in qaul for every 10 miliseconds for checking any command line events or RPC events. But, It comes with a problem of overhead since, `relay_bot::connect()` logs in every time we run in a loop and tweaking it was not likely the best option. Running in separate thread was the best thing which we got to see clearly.
+
+```rust
+thread::spawn(|| {
+        // connect the matrix bot with the qaul-cli
+        match relay_bot::connect() {
+            Ok(_) => {
+                println!("Matrix-Bridge connecting");
+            }
+            Err(error) => {
+                println!("{}", error);
+            }
+        }
+    });
+```

src/chapter_4.md

@@ -0,0 +1,28 @@
+# Concrete Version-0 usability plan
+
+## Usability Plan
+
+By the time, I reported back to mentor MathJud about my integration of matrix with qaul with a simple command `!qaul` from matrix and It would return a string saying "I am a message from qaul", We got on another call to discuss more concrete planning for the usability. 
+
+He gave some suggestions :
+### Relay Bot
+
+The bot receives the invite into a qaul-room.
+The bot accepts the invite and opens a public room with the same name in matrix.
+
+#### Public Messaging
+- Forward Public Messages from qaul to specific matrix-room.
+- Forward Public Messages from Matrix to qaul public messages.
+
+#### Group Chats
+The bot will forward messages from the qaul chat room to matrix chat room and vica versa.
+
+### Puppeting
+The puppeting shall create a 1-to-1 communication relation between qaul and matrix. In order to make that happen, The matrix bridge needs to have administrative rights on the matrix server in order to create a matrix user for every qaul user writing a message. The bridge also needs qaul users for matrix users that shall be able to communicate over it. The creation of qaul users should be handled restrictive, as they would be announced in the qaul network and create overhead in the routing table.
+
+## Concerns
+
+- Can our Matrix room use same UUID which we use for qaul rooms ?
+- As there is no concept of open chat room in qaul and all users needs to be invited by the group admin, Whether it makes sense to let the chat-bot open a qaul room as the bot would need to manually invite qaul users in it ?
+- Should we have Auto-Joining for joining any Matrix room willing to do so ? If yes, We may need our own Matrix Homeserver so that we only have trusted people onto the network. [Currently I own the qaul-bot account on my university ID and manually create rooms and accept invites from my another account] If we don't own any homeserver then AutoJoin would not be a good way to do this since the primary concern of qaul may be at risk.
+- Puppeting is a next big story and we would address it later in the journey.

src/preface.md

@@ -19,5 +19,6 @@ Just adding neat information for my this year's project
 ```
 Organization : Freifunk
 Project Name : Qaul.net
+Mentor : Mathias Jud
 Tech Stack : Rust, Go, Protobuf, Matrix APIs
 ```