tdlib/td

UPDATE_APP_TO_LOGIN

Mubo-412 opened this issue ยท 35 comments

My app was running very well, until today when I logged out and logged in again I get the message "UPDATE_APP_TO_LOGIN". Should I only update Tdlib?

Yes, update to the latest tdlib version.

Latest release ?
version 1.7.0 ?

Ah, sorry 1.7.0 is last release and it is outdated.
1.7.9 from last tdlib github commit.
Clone the repo and build it.

So there is not a prebuilt stable version for android ?

Please, can you provide latest prebuilt stable version for Android? https://core.telegram.org/tdlib/tdlib.zip this prebuilt is not latest version

So there is not a prebuilt stable version for android ?

Check: https://t.me/tdlibchat/28688 .

Thanks a lot

@levlam thats not how it should be: We were preparing now for 1st of Jan to be updated to 1.7.9, which is still a time pressure for a small project, and now suddenly new logins are banned all of a sudden without warning? Where was this date published? Our userbase might be very upset if we have to tell them that maybe for another 2 weeks or so they cannot log in anymore to their accounts, if logged out.
Please, we need a longer grace period on this.

Also you are locking out the official stable versions up to 1.7.0 without providing a new stable release with release notes etc.

Logins are still possible in 1.7.0, but only to existing accounts via QR code scanning. It is not possible to enable logins via phone number in old versions, because they can result in registration of a new user with 64-bit ID, which is unsupported by old clients.

Ok still a migration date would have been nice plus warning.

Noone knew exact migration date, which was dependent on the number of new users.

Telegram started to notify bot developers about migration to 64-bit identifiers in March. The corresponding warning was added to all Bot API updates since Bot API 5.1. Client developers are expected to use the latest TDLib version and had no issues with 64-bit identifiers because of this.

@levlam is it safe to just pick the latest untagged commit from master branch to generate new bindings for 1.7.9?

Yes, it is absolutely safe. The master version is more stable than 1.7.0.

I can confirm that after upgrading to latest Git HEAD version registration is working for us again. We are now fixing up the expected regression bugs, but overall it should not take longer than 2 days of effort maybe. Just to give other projects a perspective about the needed effort :)

I can confirm that after upgrading to latest Git HEAD version registration is working for us again. We are now fixing up the expected regression bugs, but overall it should not take longer than 2 days of effort maybe. Just to give other projects a perspective about the needed effort :)

can ilustrate to non experts coders some of hints or wich commits to made some backports in other cases..??? telegram api mess up many things with the change of the api to login in 64bit id's puff

because they can result in registration of a new user with 64-bit ID, which is unsupported by old clients.

I don't get how is it worse than not allowing to log in at all.

@levlam I am getting very frustrated now, so we are rushing our update to allow logins again, and while we are testing our new version users start complaining that logged in tdlib Apps start failing, not receiving updates and so on. Please, on Ubuntu Touch this is the only usable mass messaging facility, and suddenly today it started to disconnect random people that did 100% NOT log out, including myself.
You are breaking a public API overnight without notice and transition period, thats what I see here.

409690

LOL.

The day GitHub was conquered by ordinary users.

@mckaygerhard all I can do is to show you our MR and what we had to change: https://gitlab.com/ubports/apps/teleports/-/merge_requests/420 - mainly int64 changes, and the chat list position thingies. Rest will come later, as this is only the needed fixes to get it running again.

Are there compiled binaries for Debian 10+ available?

@ForNeVeR if you don't get it: @0823969789 got a link to the issue somewhere when they encountered the login problem, and started putting their authorization code here and there in hope it helps. Would a developer do that?

Poor users, they got suddenly and unduly locked out with no any adequate warning. Even old official clients are affected. Just imagine what fuss did it make for users who lost credentials for their Play Store accounts and so. Will Telegram survive this reputational blow? They surely will, but barely would be able to oppose themselves to evil corps anymore. Even WhatsApp had given an honest deadline when abandoning old platforms.

I've got to agree with @Flohack74 , this update was not handled properly. I get that the 64-bit id issue's date-of-impact was unknown until the day it happened, but people were not adaquetly warned. I recently looked at this repository before old versions died and I saw the latest tag version was v1.7.0 so I assumed that was the version to use. There was nothing warning of the impending issue or suggesting to use v1.7.9/master. I never would have thought using master was a better option, after all master is being constantly updated so that suggests it would be less stable than an official, and seemingly stable, release/tag. Further more the error message UPDATE_APP_TO_LOGIN is rather vague, my first thought was that it meant upgrade to v1.7.0. I also googled this error on the day it first occurred and I only got 3 results, none related to Telegram. There should have at least been a blog post with that exact error and explaining what it meant, but instead a large portion of users were left in the dark and ended up discussing with each other trying to figure out what was going on. Not everyone is on the BotApi mailing list @levlam .

Furthermore, the TDLib API methods and public interfaces are no longer fully documented. For example, the class GetMessageLink has changed between v1.7.0 and v1.7.9. There is now a new field called mediaTimestamp, but the documentation fails to mention it. And this isn't a simple parameter where its purpose is obvious, not all messages have media so what about them? Why does this parameter matter? This rust doc at least mentions it, but it doesn't explain how to use the parameter because that's the job of the TdLib documentation. What are we actually supposed to use for v1.7.9 documentation?

but @Drumbard8 You place the developers as guilty, and you don't see that Telegram has forced its entire population to change (a consecuence of the api upgrade.. ), honestly I prefer to change at the shit of guasap instead of seeing how Telegram forces me to use new things when the old ones work for me good ! people just dont care about "new featrures of 64bit id's" .. why telegram doe snot provide compatibility api? puff fucking enterprices..

This happens due using closed privative services, although nowadays in open source and free software projects there are so many windosers and hypocrits with their updating fashion that they are the same issue

@mckaygerhard I didn't understand most of that, but I was under the impression that this library and the docs were maintained by Telegram itself. I didn't realise there were multiple groups at play here. Which parts are maintained by who?

@mckaygerhard even though I understand your frustration please stop using cursewords in such a thread. It is to the benefit of no one and you will get probably moderated. Stay with the facts, reduce emotions, be constructive. Errors happen, we are all humans, and since we all do not pay for Telegram they are not obliged to contractual terms with us. And this change is not the end of the world, after all fixing it took 2 days for us (mainly due to setting up an upgrade branch, provision CI etc.)

@mckaygerhard

new featrures of 64bit id's

Excuse me? It's not about "features", it's just about the ability for new users to register and for others to communicate with them.

Would you like to make a club of proud oldfags able to use outdated clients, and selling old 32-bit accounts like it happened with ICQ UINs, lol?

You still may run your own isolated Telegram server and patch any abandoned client to use it, just like OSCAR lovers did for AIM/ICQ, hehe. Only if that would make any purpose besides of museum ones...

You still may run your own isolated Telegram server and patch any abandoned client to use it, just like OSCAR lovers did for AIM/ICQ, hehe. Only if that would make any purpose besides of museum ones...

its not funny when you are the FORCED one.. right? some one will give you one! maybe already done in your healt! have you a stable family ๐Ÿ˜ˆ

i repeat.. i will not change a complete OS only due a stupid app forces to.. lot of gigs already working due only one does not! real nonsense

he best way to mantain interes.. forcing changes! great ! what a nasty

Okay, to get this discussion drained: It is okay to make breaking changes from time to time. Thats whats happening everyday out there. Not being able to make breaking changes will prevent from fixing security leaks, performance problems or scalability. It would mean the end of the IT world we know today.
The only difficulty is how you introduce breaking changes correctly. Thats all what the people probably wanted to stress, the int64 ID breakage was not clearly communicated and enforced suddenly, and that brought some upset.
Please do not comment more emotions and curses, stay with the facts.

@mckaygerhard

its not funny when you are the FORCED one.. right? some one will give you one! maybe already done in your healt! have you a stable family

Shit happens, and it happens unexpectedly. And a person can barely be considered mature if they cannot handle this.

i will not change a complete OS only due a stupid app forces to..

How is that even related? What is you problem exactly?

I successfully use Telegram even on an embedded OS that was abandoned 10 years ago, via a Jabber transport.

Is there a Jabber client for your OS? If not, make an IRC one; the protocol is simple as heck, basically just plain text over a socket. Bitlbee + tdlib-purple = perfect, many of people use it this way already.

@Flohack74

prevent from fixing security leaks, performance problems or scalability

Not everyone cares about the security paranoia and the maximum performance. Just like not every house is as armed as banks are, and not everyone drives a racing car on public roads.

Just remember that many things that were considered a "progress" before eventually brought us health, social and environmental issues. And e-waste is a part of that.

Please do not comment more emotions and curses, stay with the facts.

It would be reasonable if @levlam had proven that the decision to break the compatibility was not emotional itself. I still have not seen yet, neither here nor in the TDlib chat, any strong explanation of why it had to be done exactly this way: before the deadline and by disconnecting users with 32-bit IDs as well. Moreover, they had assured me that old clients will keep working, right while first users were experiencing login issues already.

Right now it just looks like the team, tired by a compatibility burden, had made an unpopular decision but tries to hide that behind vague and polite excuses to soothe the public. It would be expected from a typical evil corp that just honestly makes money and does not give a shit for anything else unless demanded โ€” but not from a company that has chosen the users' trust as a marketing strategy. Trust means being honest about any decisions, both popular and unpopular. The introduction of ads is justified well; the API breakage is not: that's the fact :)

@mckaygerhard

its not funny when you are the FORCED one.. right? some one will give you one! maybe already done in your healt! have you a stable family
Shit happens, and it happens unexpectedly. And a person can barely be considered mature if they cannot handle this.
i will not change a complete OS only due a stupid app forces to..
How is that even related? What is you problem exactly?

i have a fully 32bit only machine pefectly working but now i cant compile any app tdlib does not compiles into debian 8 the currently working os here.. i cannot upgrade due the devices that are in use (older PIC cars for cameras) i not will buy 4 cards only due i will upgrade gcc and a couple of software

I successfully use Telegram even on an embedded OS that was abandoned 10 years ago, via a Jabber transport.
Is there a Jabber client for your OS? If not, make an IRC one; the protocol is simple as heck, basically just plain text over a socket. Bitlbee + tdlib-purple = perfect, many of people use it this way already.

umm it sounds interesting.. @bodqhrohro .. this is pretty now off topic but give some hints please! i already liked irc and jabber protocol also..

, they had assured me that old clients will keep working, right while first users were experiencing login issues already.

false, some disconnected suddently and in telegram desktop craps now a screen will cover all your older client forced you to upgrade ! many users are very angry with the current telegram api changes

@mckaygerhard @bodqhrohro
Only users that can upgrade should be forced to upgrade right now. If you have some other example, i.e. an app doesn't have new version or there is no way to install it, but its users are forced to update, please report such cases.

@mckaygerhard

but give some hints please!

What hints? I have pointed you to the Bitlbee + tdlib-purple stack already :P Set it up on a modern remote server or any other everrunning machine, and be happy.

For Jabber, you can use Spectrum2 instead of Bitlbee, with any XMPP server of choice (I use Prosody).

some disconnected suddently

AFAIK, disconnects of running sessions started several hours later, but there could be earlier cases of course.

@levlam, I know at least two examples of abandoned, non-TDlib-based clients:

  • https://github.com/majn/telegram-purple: abandoned, as well as the tgl library it's based on. Some users complain they have left out of their existing secret chats because they cannot be migrated to any other client.

  • https://github.com/fabianonline/telegram_backup: not sure if someone still used it as the author had locked the communication both in the repository and in the group, still it's likely as the tool had advantages over the builtin backup mechanism like flexibility and incremental backups.