On the 10th of February, Telegram sent the following message to
those with an application registered on https://my.telegram.org.
--
Telegram API Update. Hello [REDACTED]. Thank you for contributing to the
open Telegram ecosystem by developing your app, [REDACTED].
Please note that due to recent updates to Telegram's handling of SMS and
the integration of new SMS providers like Firebase, we are changing the
way login codes are handled in third-party apps based on the Telegram API.
Starting on 18.02.2023, users logging into third-party apps will only be
able to receive login codes via Telegram. It will no longer be possible
to request an SMS to log into your app - just like when logging into
Telegram's own desktop and web clients.
Exactly like with the Telegram Desktop and Web apps, if a user doesn't
have a Telegram account yet, they will need to create one first using
an official mobile Telegram app.
We kindly ask you to update your app's login and signup interfaces to
reflect these changes before they go live on 18.02.2023 at 13:00 UTC.
This change will not significantly affect users since, according to our
research, the vast majority of third-party app users also use official
Telegram apps. In the coming months, we expect to offer new tools for
third-party developers that will help streamline the login process.
This way it is easy and cheap to copy the two required values
to all incoming updates in case we need to getDifference since
the previous pts/date to fetch entities.
This is still a work in progress.
It's the only way to properly clean all background tasks,
which the library makes heavy use for in MTProto/Connection
send and receive loops.
Some parts of the code even relied on the fact that it was
asynchronous (it used to return a future so you could await
it and not be breaking).
It's automatically syncified to reduce the damage of being
a breaking change.
This one in particular may happen when iterating over messages,
perhaps more likely to happen if the group was created in a
different data center.
A small sleep of a few seconds also greatly increases the
chances of the error going away.
Things like SQLAlchemy work correctly only for timezone-aware datetimes.
The returned TLObjects all have them, but those that are manually created
were missing them, so serializing the state into SQLAlchemy sessions failed.
The salt1 that is sent to the server requires an additional 32 bytes
of random data. It's easy to miss this requirement from reading the
tdesktop source, because this extension is done in a function called
`ValidateNewCloudPasswordAlgo`.
https://github.com/telegramdesktop/tdesktop/blob/2e5a0e056cdb40d61d487c6062bffe1a835f
6ddd/Telegram/SourceFiles/core/core_cloud_password.cpp#L210-L211
