Lonami
It should probably be `return NEXT_STATE[, data]`. But it gets trickier when we may or not want commands to take priority, and when inline comes into play. It also depends...
This includes traits, structures, enumerations, and modules. Everything should be reviewed after the basics are working, at the very least the public ones.
Use of raw API should be the exception, not the norm. Our client should offer an idiomatic interface for the most commonly used methods. Starting by porting [Telethon's client methods](https://docs.telethon.dev/en/latest/quick-references/client-reference.html)...
Currently, every raw type is owned. This makes it very convenient to use (both for reading, and for creating instances of it, e.g. to send requests). However, it's also pretty...
> `bot_sign_in` sometimes fails with `IO(Kind(UnexpectedEof))` > I'm also getting a few `IO(Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }) and IO(Os { code: 110, kind:...
Every friendly type wrapper should provide means to convert `into_raw`, maybe through a feature gate (to indicate that this will never be "stable"). For this a trait might do.
We should aim for a good test coverage. For example, things like the transports deserve a test (abridged doesn't even work right now!), but ideally we would review the code...
Any product will be useless unless people know how to use it. Once we settle on a stable design, we should document every public module of (at least) the client...
For example, [Quick ack](https://core.telegram.org/mtproto/mtproto-transports#quick-ack) could be a nice-to-have.
See: https://core.telegram.org/mtproto/security_guidelines