minor readme changes in preparation for release

readme.md

@@ -1,15 +1,16 @@
 # Dotnet Telegram forwarder  
-("temporary" generic name from the very start of development that stuck forever)  
-An app providing HTTP API to deliver arbitrary text notifications via Telegram bot from anywhere where making HTTP POST requests is available.  
+("temporary" generic name from the very start of development)  
+An app providing HTTP API to deliver arbitrary text notifications via associated Telegram bot from anywhere where making HTTP POST requests is available.  
 
 ## Status
-Operational. First version has been serving me flawlessly (as I can tell) since mid 2018, and a long overdue refactoring/framework update (spoiler: one of the major updates two planned) is currently underway.
+Operational. First version has been serving me flawlessly (as I can tell) since mid 2018.
 
 ## Description
 Let's try [readme driven development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html) this time. So this app consists of two equally important parts: Telegram bot and a web API.
 
 ### Web API
 Has only one method to send the notification. Its endpoint listens for POST requests with JSON body. Actual endpoint URL will be provided via the bot itself when a new token is created.
+
 #### Request
 Request's body has this structure:
 ```
@@ -20,26 +21,26 @@ Request's body has this structure:
     "silent": (optional) boolean
 }
 ```
-* Token is this service's user identifier, randomly generated per Telegram user, with abilities to withdraw it or replace with a new one anytime. (Implement a cooldown on consequent resets?) It's a 16 characters long string that may contain alphanumerics, and plus and equals signs (So `[0-9a-zA-Z+=]{16}`).  
-* Type is used to select between two supported parse modes: `"plaintext"` for plain text, and `"markdown"` for MarkdownV2 as described in Telegram docs [here](https://core.telegram.org/bots/api#markdownv2-style). If value is not supplied, defaults to `"plaintext"`. These two are separated, because Telegram flavoured Markdown requires escaping for a fairly common plaintext punctuation marks.  
-* Message is the text of the message to be sent via the bot. Maximum length is 4096, and preferred encoding is UTF-8.  
-* Silent is boolean to indicate whether them message from the bot in Telegram will come with a notification. Behaves what you'd expect. If not supplied, defaults to `false`. Please note that the end user is able to mute the bot, effectively rendering this option useless.
+* Token is this service's user identifier, randomly generated per Telegram user, with abilities to withdraw it or replace with a new one anytime. It's a 16 characters long string that may contain alphanumerics, and plus and equals signs (So `[0-9a-zA-Z+=]{16}`).  
+* Type is used to select between two supported parse modes: `"plaintext"` for plain text, and `"markdown"` for MarkdownV2 as described in Telegram docs [here](https://core.telegram.org/bots/api#markdownv2-style). If value is not supplied, defaults to `"plaintext"`. These two are separated, because Telegram flavoured Markdown requires escaping for a fairly common plaintext punctuation marks, and will fail if not formed correctly.  
+* Message is the text of the message to be sent via the bot. Maximum length is 4096 (also happens to be a maximum length of one Telegram message).  
+* Silent is boolean to indicate whether them message from the bot in Telegram will come with a notification with sound. Behaves what you'd expect. If not supplied, defaults to `false`. Please note that the end user is able to mute the bot, effectively rendering this option useless.
 
 #### Response
 API returns an empty HTTP response with any of the following status codes:
 * `200 OK` if everything is indeed OK and message should be expeted to be delivered via the bot  
-No further actions from the client required
+No further actions from the client required.
 * `400 Bad Request` if the user request is malformed and cannot be processed  
-Client should check that the request is well-formed and meet the specifications, and retry with the fixed request
+Client should check that the request is well-formed and meet the specifications, and retry with the fixed request.
 * `404 Not Found` if supplied token is not present in the database  
-Client should check that the token they provided is valid and has not been removed via commands, and retry with the correct one
-* `429 Too Many Requests` if current limit of messages sent is exhausted  
-Client should retry later, after waiting at least one minute (on default throughput config)
+Client should check that the token they provided is valid and has not been removed or changed, and retry with the correct one.
+* `429 Too Many Requests` if current limit of sent messages is exhausted  
+Client should retry later, after waiting at least one minute (on default throughput config).
 * `500 Internal Server Error` in case anything goes wrong  
 Client can try to retry later, but ¯\\\_(ツ)\_/¯
 
 #### Rate limitation
-The API has a rate limitation, preventing large(ish) amount of notifications in a short amount of time. By default (can be adjusted via config files), every user has 20 ...message points, I guess? Every notification sent removes 1 message point, and requests will be refused with `429 Too Many Requests` status code when points are depleted. A single point is regenerated every minute after last message was sent.  
+The API has a rate limitation, preventing large(ish) amount of notifications in a short amount of time. By default (can be adjusted via config files), every user has 20 ...message points, I guess? Every notification sent removes 1 message point, and requests will be refused with `429 Too Many Requests` status code when all points are depleted. A single point is regenerated every minute after last message was sent.  
 For instance, if API is used to send 40 notifications in quick succession, only 20 first messages will be sent to the user. If client waits 5 minutes after API starts responding with 429's, they will be able to send 5 more messages instantenously before hitting the limit again. After 20 minutes of idle time since the last successfully sent message, the API will behave as usual.
 
 ### Telegram bot
@@ -75,5 +76,5 @@ Initial release. More an excercise in ASP.NET Core than an app I needed at the m
 Greatly increased the reliability of Markdown parsing in one of the most **not** straightforward ways you can imagine -- by converting the Markdown to HTML with a few custom convertion quirks.
 * **no version number**, 2020-05-14  
 Shelved attempt to improve the codebase. Consists of one architecture change and is fully ~~included~~ rewritten in the next release.
-* **v 2.0**, not yet released, (hopefully) in development  
-Really proper markdown support this time (Telegram's version with questionable selection of characters to be escaped), option to send a silent notification, async everthing, and probably something else I forgot about.
+* **v 2.0**, 2023-05-06  
+Really proper markdown support this time (Telegram's version with questionable selection of characters to be escaped), option to send a silent notification, async everthing, .NET 7, HTTP status codes instead of custom errors, and probably something else I forgot about.