alina sireneva

ctr256 can work in place, we can reduce the number of allocs there. also check if we can use some pre-alloced pool for small chunks

currently @mtcute/tl is basically: - a large map of constructor id -> reader function - a large map of constructor name -> writer function - a large union type in...

https://core.telegram.org/cdn

unlike tdlib, mtcute currently only caches the bare minimum needed to function. however, in many cases it makes sense to cache stuff locally, just like tdlib. - [ ] cache...

bare minimum - accept them in `.start()` method and return them on `.logOut()`

currently when sending messages/stories we expect the server to return `updates` with the actual message. however this might not actually be the case, so we should instead rely on random_id...

add a high-level method `sendTextMulti` which would split the message into multiple if the text turns out to be too long. we should probably also make a util to split...

something similar to what grammy has: ```js await tg.sendText(fmt`hi, ${bold(user.name)}!`) ``` this becomes quite tedious and unreadable though with nested entities: ```js await tg.sendText( fmt`${bold(fmt`hi, ${italic(user.name)}`)}!` ) ``` idk if...

currently dispatcher doesn't have any logging on its own. it would probably be quite useful if it logged events and whether something matched them or not

https://github.com/tdlib/td/blob/56163c2460a65afc4db2c57ece576b8c38ea194b/td/telegram/FileReferenceManager.cpp implement file reference storage like described here: https://core.telegram.org/api/file_reference