Bot api server general questions

[Fedorus]

1. Is it right that this is bot-api to client-api proxy for bots?
2. Can we extend this server api with methods that exist in client api and can be called by bots but does not exist in bot api?

[levlam]

1. Yes. And it ever was.
2. No. Bots have access only to methods required for the Bot API implementation.

[Fedorus]

This is list of methods from client api which can be called while logged in as bot:
https://tl.telethon.dev/methods/botindex.html
And among them there is GetFullUser method that does not exist in official bot API... but still can be used by bots...

[giautm]

Hey, Is there an docker version to deploy bot server to any cloud that support docker?

[levlam]

@Fedorus This is not true. GetFullUser is used for getChat implementation. All UserFull fields not included in getChat response are useless for bots: bots don't have peer settings, can't change chat notification settings, can't block users, can't call users, don't have privacy settings, don't have scheduled messages, don't have video calls and can't move chat with the user to Archive.

[levlam]

@giautm No. You need to build the Bot API server yourself using provided build instructions to use.

[gabbhack]

What about limits on sending messages and so on? As far as I know, the limits for bots using the client-api (telethon/pyrogram) are stricter than for bots using official bot-api. Does this depend on whether the app_id is "trusted"? If bot support has increased limits for my bot, will they still apply on my server?

[fskuratov]

So, briefly, as far as I understand no new methods for Bots are available? No Recent actions history, or chat members list, right? Any exclusions maybe, or someone can add them by forking and rewriting the current BotAPI server?

[levlam]

@gabbhack

What about limits on sending messages and so on?

Limits always was server-side and never depended on api_id or something similar.

As far as I know, the limits for bots using the client-api (telethon/pyrogram) are stricter than for bots using official bot-api.

This is false.

If bot support has increased limits for my bot, will they still apply on my server?

Yes.

[levlam]

So, briefly, as far as I understand no new methods for Bots are available?

Briefly, you can run Bot API server locally now.

No Recent actions history, or chat members list, right?

Yes, because that polling of those lists wouldn't work. You can't poll Recent actions for million chats in runtime. Stay tuned for the future updates, though.

Any exclusions maybe, or someone can add them by forking and rewriting the current BotAPI server?
No, it isn't possible to add them currently.

[RememberTheAir]

No. Bots have access only to methods required for the Bot API implementation.

Just a clarification: as far as I remember, using any MTProto client and logging in as a bot account, the server doesn't forbid you to send a channels.getParticipants request. A similar method is not available in the bot api, as the bot api doesn't expose any method to fetch a chat's members list. What is currently stopping someone from forking this project and add a method to the current available methods to request the members list using tdlib's getSupergroupMembers? Maybe tdlib doesn't let you use such methods if you login as a bot - or underneath getSupergroupMembers uses some other mtproto method that is not available to bots (so one would have to fork this project and tdlib to add this functionality)?

[levlam]

@RememberTheAir
Just a clarification: getSupergroupMembers is required for the Bot API implementation, and you can use it with filters not exposed in the Bot API. But flood limits for such usages aren't increased for bots, so you are likely to exceed them very fast.

[RememberTheAir]

@levlam ah, I see. One should expect mtproto/tdlib to accept just method requests strictly required to what the bot api allows to do - getSupergroupMembers is required to the current set of functionalities offered by the bot API (eg, getting a group's administrators), so it's not something Telegram left out "just because". Makes sense, thanks for the clarification. That also means that there are some MTProto methods that can be more broadly extended by a bot api fork (such as getSupergroupMembers), if you take in account the tight limits enforced by telegram's servers

[funnyflowerpot]

Thanks @levlam for proving quick and helpful answers here!

Question: What parts of the data transfer between Telegram client, Telegram bot, and local Bot API server are going through official Telegram servers?

In the previous version of the Bot API the data flows were pretty clear to me, but now I find it more difficult to see which network host is talking to whom and when. I was searching for details or maybe something like a sequence diagram, but I couldn't find related information so far.

I am also asking from a data privacy perspective. So in other words: What data (and metadata) could be still read by official Telegram servers, when a local Bot API server is used? I think including such information in the readme file of this repository would be great in terms of transparency.

[funnyflowerpot]

Here is how I understand the network communication between the relevant hosts Telegram client (C), Telegram bot (B), local Bot API server (BAS), and official Telegram servers (OTS). Is the following outline correct? If I missed a section in official documents describing this, please let me know!

1. BAS starts (no network requests here).
2. B starts and registers with BAS.
3. B tells OTS that it can be reached via BAS.
4. Using C a user attempts to start a chat with B.
5. C asks OTS for information on B.
6. OTS tells C that B's API server is BAS.
7. C sends data to BAS, BAS forwards data to B, and vice versa.

And so:

• All subsequent communication between C and B happen with BAS as a proxy.
• C and B never communicate directly with each other. (This also was the case before local Bot API servers.)
• OTS are only needed to establish communication between C and BAS in the beginning, but not afterwards.
• OTS and BAS never communicate directly with each other.

Is this description correct? Thank you!

[RememberTheAir]

Sorry for the low effort diagram. This is a map of how the various involved entities interact with each other.

Using your abbreviations, C never directly interact with BAS (that is, the user's Telegram app never directly connects to the server where an instance of telegram-bot-api is running). All the communications go through Telegram's servers (OTS), which forwards them to the two mtproto clients involved: the Telegram app the user C is using on their device, and the tdlib instance telegram-bot-api (BAS) is running under the hood.

BAS just acts as a front-end to the Telegram API, which is way more difficult to implement than a common Rest API (which is what BAS is supposed to be - an additional level of abstraction to interact with the Telegram API as a bot account). A rest api is more familiar and friendly to developers, so it's easier to pick up.

Note: in the image above, you can see only one telegram-bot-api instance, but there can be a number of these now, each one of them used by a number of bots. Also, the machine where the api is hosted can also be used to host the actual bot code, of course