Formatting of the README

README.md

@@ -40,30 +40,30 @@ that probably matter.
 
 * **Domain fronting**
 
-For years mtg supports domain fronting. This technique means that it fallbacks
-to accessing a real website in case if request fails. It could fail by many
-reasons: anti-replay protection, accidental access to the webserver or
-stale request. Anyway, if mtg rejects this request, it does not break a
-connection. It connects to the websites and replicates everything that client
-has sent, and simply proxies it back as is. Users will see a response from
-the real website, _byte-to-byte identical_ to the response of the real netloc.
+  For years mtg supports domain fronting. This technique means that it fallbacks
+  to accessing a real website in case if request fails. It could fail by many
+  reasons: anti-replay protection, accidental access to the webserver or
+  stale request. Anyway, if mtg rejects this request, it does not break a
+  connection. It connects to the websites and replicates everything that client
+  has sent, and simply proxies it back as is. Users will see a response from
+  the real website, _byte-to-byte identical_ to the response of the real netloc.
 
 * **Doppelganger**
 
-mtg also is a doppelganger of the website it fronts. Sure, with domain fronting
-users will see replies of the real website in case if something will go wrong.
-But what about such cases when _everything is fine_?
+  mtg also is a doppelganger of the website it fronts. Sure, with domain fronting
+  users will see replies of the real website in case if something will go wrong.
+  But what about such cases when _everything is fine_?
 
-In that case mtg mimics TLS connection statistical characteristics as close as
-possible. Different application have different statistics of their patterns.
-Big CDN steadily pumping the data, small websites burst with short easily
-compressiable chunks of traffic.
+  In that case mtg mimics TLS connection statistical characteristics as close as
+  possible. Different application have different statistics of their patterns.
+  Big CDN steadily pumping the data, small websites burst with short easily
+  compressiable chunks of traffic.
 
-mtg artificially emulates those delays to be statistically indistinguishable
-from the real website even if it covers connection of the very specific app.
-It also follows 2 most common patterns of traffic chunking, so censors
-will have to put more resources to find out that we have Telegram here
-but not a hookah webshop served by nginx.
+  mtg artificially emulates those delays to be statistically indistinguishable
+  from the real website even if it covers connection of the very specific app.
+  It also follows 2 most common patterns of traffic chunking, so censors
+  will have to put more resources to find out that we have Telegram here
+  but not a hookah webshop served by nginx.
 
 * **Resource-efficient**