./telegram.go:51:13: assignment mismatch: 2 variables but bot.GetUpdatesChan returns 1 values

Sometimes, the reply MUD reply to a command is too long, and the telegram user won't ever see it, since the bot gets a sendMessage resp: {"ok":false,"error_code":400,"description":"Bad Request: message is too long"}.

It seems that Telegram has a maximum message length of 4096 characters, so we should check the message size before sending it, and, if it is longer than 4096 characters, split it (in two or more). The split should happen on newlines (if they exist).

Some more tests will need to be done, but it seems that the current model of sender and receiver workers doesn't work as expected when much activity is happening on both fronts: if you try to send a message while still in the process of receiving one, your message might end up not being sent at all. A first glance makes me wonder if a tgbotapi object is ready to be used concurrently at all.

Sometimes there are weird encodings coming from a MUD, resulting in a (silent) "Bad Request: strings must be encoded in UTF-8" failure instead of a message being delivered to the bot user(s).

We should force UTF-8 encoding on every string prior to send it.

MUD connections will often send you data full of ANSI codes (for instance, to color the text). Since telegram won't be able to interpret those, we should strip them off from the data read from the MUD.

MUDs often have ASCII art of some sort (maps, for eg.). It would be useful to send the text entirely monospaced.