diff --git a/lib.rs b/lib.rs
deleted file mode 100644
index f584e03..0000000
--- a/lib.rs
+++ /dev/null
@@ -1,78 +0,0 @@
-//! # nctalkbot-framework
-//!
-//! `nctalkbot` is a rust implemented framework, that describes a client/server infrastructure
-//! needed to build a scalable chatbot that communicates with Nextcloud.
-//!
-//! ## Overview
-//!
-//! The framework will offer the following components:
-//!
-//! * Server side
-//!
-//!   `nctalkproxyd` implements the server component. This proxy handles all
-//!   the interaction with the Nextcloud API. It will monitor NextCloud Talk
-//!   rooms while listening for new chat requests.
-//!   Incoming requests are processed appropriately and session relevant data
-//!   are exchanged via gRPC message between the proxy and the client side.
-//!   All interaction between the proxy and the Nextcloud server are encapsulated
-//!   inside http2 messages.
-//!   To keep track of the addressed rooms and its participants, it will take
-//!   advantage of an [`in memory database`](https://github.com/mambisi/escanor).
-//!   Communication is handled using the redis protocol.
-//!   New chat responses are advertised to the user as rendered chat messages
-//!   inside its originating room.
-//!
-//! * Client side
-//!
-//!   In order to create a functional chatbot, a client counterpart has to be
-//!   implemented as well. Your client will interact with `nctalkproxyd` while
-//!   sending and recieving gRPC messages.
-//!   You may implemnt it in any supported native languages that support gRPC
-//!   bindings.
-//!
-//!   `nctalkbot-jitsi` is reference implementation, that take advantage of the
-//!   framework to create new jitsi meetings.
-//!   The actual meeting is created in a new window of a supported browser session.
-//!   If a new gRPC meeting request is received, the client will process the
-//!   required steps following the [JitsiMeetExternal API](https://github.com/jitsi/jitsi-meet/blob/master/doc/api.md).
-//!   The framework is taking care to preset the session parameters (eg. Name,
-//!   password), beside participant specicfic options (participant name,
-//!   language, etc).
-//!
-//! ## gRPC Overview
-//!
-//! Like many RPC systems, gRPC is based around the idea of defining a service,
-//! specifying the methods that can be called remotely with their parameters and
-//! return types. By default, gRPC uses protocol buffers as the
-//! Interface Definition Language (IDL) for describing both the service interface
-//! and the structure of the payload messages. It is possible to use other
-//! alternatives if desired.
-//!
-//! gRPC lets you define four kinds of service method:
-//!
-//! * Unary RPCs
-//!   The client sends a single request to the server and gets a single response back
-//! * Server streaming RPCs
-//!   The client sends a request to the server and gets a stream to read a sequence of messages back.
-//! * Client streaming RPCs
-//!   The client writes a sequence of messages and sends them to the server,
-//!   again using a provided stream. Once the client has finished writing the messages,
-//!   it waits for the server to read them and return its response.
-//! * Bidirectional streaming RPCs#
-//!   Both sides send a sequence of messages using a read-write stream.
-//!   The two streams operate independently, so clients and servers can read and write
-//!   in whatever order they like
-//!
-//! Have a look at the following bird's eye illustration of the processes
-//!
-//! ![gRPC-schema.png](../images/gRPC-schema.png)
-//!
-//! ## Workflow visualization
-//!
-//! The following image try to illustrate the major components and its workflow.
-//!
-//! ![nctalkbot-framework.png](../images/nctalkbot-framework.png)
-//!
-
-//#![feature(extern_doc)]
-//#[doc(include="../README.md")]