Collaboration

[BenWiederhake]

Hi, thanks for starting this!

In this issue I want to track how / when / in how far we want to redirect people from telegram-purple to tdlib-purple. (Note: I'm the de facto maintainer of telegram-purple, and would be happy to abandon ship.)

I haven't had the opportunity to look deeply into the code yet, but I will do so in the coming days. Hooray! :D

[ars3niy]

Whoa, what happened to my e-mail software! Didn't see the activity until now.

Anyway, yeah, I made this plugin using unmodified tdlib, hopefully making it more future-proof. I've been using it for two months now, but am hesitant to advertise it because it's still not fully functional. For example, adding contacts has a funny glitch, no support for non-text message content (pictures would be most important), no group chats. But hopefully it will become fully usable in the future.

[ars3niy]

Adding contacts now works correctly.

[ars3niy]

Receiving pictures is now supported, as are group chats to some extent. At this point, I would say it becomes somewhat usable.

[BenWiederhake]

Hell yeah! I'm currently working on various things, I'll try to have a look soon. Awesome work, I hope this can replace telegram-purple one day! :D

[ars3niy]

We just need to set a target for when that can happen, in terms of which features must be implemented. The missing features list from the readme here is my first attempt at that, but I can have missed something. If nothing else, that's what I would like to get help with: what features does telegram-purple have?
From there, I should be able to come up with a release candidate within a few weeks.

[BenWiederhake]

what features does telegram-purple have?

Good question, since I wasn't there from the beginning and honestly never tried to understand the entire codebase ^^'

• Interact with direct conversations, group chats, super groups, channels, and encrypted chats (although encrypted chats are partially broken in tgp, and not very secure due to the lack of secret key validation)
• Receive&send text messages (duh)
• Receive&send images
• Receive-only stickers
• Receive&send arbitrary documents (broken on encrypted chats)
• Receive-only replies and forwards
• Receive-only audio messages (as downloads; it's ugly)
• Receiving the history on first startup (very brittle and barely works), with a configurable upper bound
• Kick users (/kick command)
• View which people are in a group / super group
• Display first/last/full/nick name and "last seen" in info window
• Display people who have been offline for a long time as "offline"
• Display current buddies and chats (and sync on startup)
• Remove buddies and chats (although I recall there being some problems)
• Rename buddies and chats (although having / in a name causes weird issues)
• Join a chat, although I have never used that feature successfully
• Start talking to someone new, although I have never attempted to used that feature
• Password for 2FA
• SMS-fallback for 2FA (although I think there were some issues with that)
• Asking before accepting secret chats (configurable)
• Limiting which files are downloaded by size (configurable)
• Displaying read receipts (configurable)
• Sending read receipts (configurable)
• Typing notifications
• IPv6 use (needs a restart, and people say it works. I'm on an IPv4-only ISP, so I can't test it.)
• Creating multiple telegram accounts – so make sure there are no mutable globals! ;)
• A half-assed attempt to keep chat logs in the same directory (but it only works "meh")
• A half-assed attempt at HTML/Markdown that does more harm than good
• Linebreaks in a message are treated properly (this seems to be difficult with Adium; I recommend that you don't care and let @ksuther fix it, he is an awesome help with Adium support).
• Support of /me
• Translations. I'd be glad to help, I set up the tgp transifex page works quite well.
• Finch compatibility. I know at least two blind users who would be sad if tdlib-purple isn't accessible to them :)
• Windows installers. Again, I can help with that, just like I am the culprit of this monstrosity.
• Development chat. Mostly for people to hang around. From personal experience, I'd recommend either IRC or Telegram, and don't put the link too obviously in the ReadMe, or you'll be flooded by trolls / spambots.

Specifically, tgp does not implement:

• Receiving or sending edited/deleted messages
• Receiving or sending polls
• Receiving or sending geo information, or really any feature introduced after 2016 (!)
• Anything with bots beyond just plain text messages
• Any clever way to deal with spammy downloads

I'll try to install and test tdlib-purple soon-ish. (Might take a while, due to real life.)

You might also want to get in contact with Thorsten "mirabilos" Glaser, I'm sure he'll be glad to get tdlib-purple into Debian, which would get you lots of users: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958828

Btw: You're amazing, thanks for carrying this! :D

EDIT: Now that I look at the list, it seems a lot actually. Don't worry too much if one or two things are missing. :)

[ars3niy]

Display people who have been offline for a long time as "offline"

The official telegram client shows people online only briefly when they interact with the application, and offline the remaning 99% of the time. Or at least that's how all my contacts get treated. Should we not mirror its behaviour?

A half-assed attempt to keep chat logs in the same directory

How so? Does libpurple not just store the logs however it wants (under ~/.purple/logs/telegram/my phone number/their phone number/a bunch of html files)?

Development chat. Mostly for people to hang around.

Should we just re-use the one you already have for telegram-purple? I could join it – as soon as I can do so using my client ;-)

[BenWiederhake]

The official telegram client shows people online only briefly when they interact with the application, and offline the remaning 99% of the time. Or at least that's how all my contacts get treated. Should we not mirror its behaviour?

Both behaviors are fine in my eyes; implement whichever you like better. :)

under ~/.purple/logs/telegram/my phone number/their phone number/a bunch of html files

Technically yes, but the "their phone number" is something that your plugin sets somewhere. I don't quite recall the name of the property, it wasn't display_name but something similar. "their phone number" sounds good and stable though, please keep it if that's how tdlib-purple currently works! :D

Should we just re-use the one you already have for telegram-purple?

I'm not sure whether that's a good idea. My expectation is that telegram-purple will continue to be in use for several years after being abandoned. I'll ask a few people.

[ars3niy]

"their phone number" is something that your plugin sets somewhere.

It's name argument to purple_buddy_new. It's supposed to be user's permanent unique identifier as I understand it, like the login name, so for telegram it would be phone number.

Should we just re-use the one you already have for telegram-purple?

I'm not sure whether that's a good idea. My expectation is that telegram-purple will continue to be in use for several years after being abandoned. I'll ask a few people.

Yeah, I meant same chat for both projects: I suspect people will be confusing the two, anyway. But either way is fine.

[BenWiederhake]

It's name argument to purple_buddy_new. It's supposed to be user's permanent unique identifier as I understand it, like the login name, so for telegram it would be phone number.

Ah, now I recall why tgp doesn't do that: The phone number isn't always available.

At least that's how I remember it. Does tdlib always give you access to someone's phone number?

[ars3niy]

Oh. There's this privacy setting for not sharing your phone number with your contacts, which none of my contacts have so I haven't encountered it yet. More work...

[BenWiederhake]

😄 Sorry to rain on your parade, but I hope you can use my "heads-ups" to avoid getting stuck in a design corner.

I think the telegram user-ids are public, and they are "just" huge, unique, otherwise anonymous numbers. Those sound like a good candidate, because they necessarily are revealed with every message, and don't change, right?

[ars3niy]

It's indeed the only choice, because everything else is non-unique or optional. Fortunately, switching should never be too hard.
UPD: I'm not sure user IDs are unique across different accounts (did they never intend to have more than 4 billion users?), but unique within an account must be good enough.

[ars3niy]

Fortunately, this plugin has comprehensive regression testing, so I feel confident making a change like that.

[stokito]

@BenWiederhake could you please enable issues in your fork? https://github.com/BenWiederhake/tdlib-purple

Now we have old TG plugin archived and the new is not actively developed and already forked.
@ars3niy if you a lack of time then maybe you can transfer your plugin to @BenWiederhake or some organization (maybe the @pidgin). Then users will be redirected to the new location.

Even if the plugin has problems it still should be published to repos of all distros because today we simply don't have an alternative to the official client which has a lot of own problems.

[stokito]

It would be great to replace the existing telegram-purple with the new tdlib-purple to keep existing accounts, contacts and chat history.
I do have an old account that even connects but doesn't do anything.
Similarly users who had it installed with a package will be upgraded without a need to install a new package. Debian already have the telegram-purple package and it will be more easily to update it than create a new one.

@EionRobb would it be ok for you? You may unarchive the repo and give a write access to @BenWiederhake so that he can merge the projects.
I can try to do the migration myself, it may be not that complicated.

[EionRobb]

Do I have access to do that? I can try I guess 🙂

Edit: doesn't look I can. Probably not the best idea to effectively 'trick' the package maintainers into pulling a new project's code anyway

[BenWiederhake]

keep existing accounts, contacts and chat history.

Keeping the chat history around would require some very significant effort, it's probably easier to just write in the readme where and how to move your files. Contacts are stored server-side, I believe, so I'm a bit confused: I thought the pidgin-contacts are rewritten on every reload, aren't they? And finally, this hypothetical transition would have to be repeated for each pidgin-account. This does not sound like a good idea.

Debian already have the telegram-purple package

It really shouldn't, it cannot possibly work anymore. Also, it is incorrect: It's only present in bullseye (oldstable) and sid, and therefore not visible to the vast majority of users (stable and testing). Also, it is fundamentally incompatible with the way Debian works: As already discussed, paraphrasing: What should we do when the package is accepted in Debian stable and telegram adds things / changes the API? Do they commit in keeping things working for 5+ years (stable+oldstable+lts or any ubuntu lts release)? Sure, Telegram's API has "layers" and is totally "backwards compatible", and yet here we are, with a broken client a few years later, proving that it is not in fact backwards compatible.

Don't package this software into Debian stable. (testing-only might work, though.)

EDIT: Since this "issue" doesn't track anything completable anymore, I'll close it.

[stokito]

Yeah, you right. Thank you