Expose MTProto Methods, which are used by Bot API anyway

[Bibo-Joshi]

Hi there!

This issue is basically a follow up on a few comments from #1 (here, here, here), but as that's closed and discusses a lot of other topics, I'm opening a new issue.

What I understand from above comments: MTProto exposes some methods to Bots, while not directly exposing them through the Bot API, because the Bot API uses them internally. Not all of what MTProto provides via those methods is useful for bots.

My question would be, if it would be possible to fully expose those methods through the Bot API or at least reevaluate which of those can be useful for bots. Specifically, in the usergroup of python-telegram-bot, we get many questions on how to access a message by chat- and message_id. This is currently not possible through the Bot API, while getMessages is accessible by bots.

If I'm getting this all wrong, please correct me. Otherwise I'd be happy for a short response or - ideally - a future extension of Bot API.

Cheers!
A happy Bot API user :)

[levlam]

Exposing getMessage method will affect all the methods, which uses it internally, breaking a lot of other methods when flood limits are exceeded. Flood limits for direct usages of the method aren't increased for bots, so they will exceed the limits very fast.

From the other side, bots receive replied and other context messages directly in updates. There is no place in Bot API where bot receives a message identifier without the message except respose of the method copyMessage (which is intentional) and the field Message.forward_from_message_id (where both messages are exactly the same). If the bot received a message identifier previously, it can save all the needed data along with message identifier. Accessing local data is much more efficient then sending a request to Bot API and it isn't subject to flood limits.

[Bibo-Joshi]

Thanks for the fast reply!

Flood limits for direct usages of the method aren't increased for bots, so they will exceed the limits very fast.

Just to clarify: Your point is that using getMessage will lead to hitting flood limits quickly, because there are many other methods that use it internally?
If that the case: Okay, I see the point. On the other hand, users need to care about flood limits anyway.

Accessing local data is much more efficient then sending a request to Bot API and it isn't subject to flood limits.

True. However, there certainly are use cases, where you would only need to call getMessage once in a while, or only do very few of such calls (like getting the message, the reply_to_message was a reply to for very specific updates). In those cases, keeping a local database would require much more effort than just accepting to make one more request.

Also, there is currently no proper way to know if a message was already deleted or not: You can try-except copyMessage or sending a reply to it, but that will lead to a new message, if it in fact still exists. try-excepting getMessage would be much cleaner.
A similar problem is checking if a user has blocked the bot, btw (currently one has to try-except sendChatAction or getUserProfilePictures, if the user should not be pinged in case of success). I'm not too familiar with MTProto, but my guess would be, that this info is somehow available, and it would be a great help, if it was exposed through the API.

[levlam]

Your point is that using getMessage will lead to hitting flood limits quickly, because there are many other methods that use it internally?

Yes. Also, not only getMessage requests will fail, but a lot of other requests depending on getMessage, such as deleteMessages or sendMessage with reply_to_message_id, will fail too.

However, there certainly are use cases, where you would only need to call getMessage once in a while, or only do very few of such calls (like getting the message, the reply_to_message was a reply to for very specific updates).

Bots receive all message edits, so it shouldn't need to call getMessage to receive current state of a message.
Bots receive all replied messages, to this shouldn't be a case either.

Also, there is currently no proper way to know if a message was already deleted or not:

True, but check of message existence by constant regetting of all the messages wouldn't work anyway. Such approach needs enormous number of requests and will immediately lead to exceeding of flood limits.

A similar problem is checking if a user has blocked the bot.

There are no reasons to know that except some statistics. It doesn't matter how often bot checks whether user blocked it, it must handle 403th error, because user can block the bot in-between the check and a request. Bots just need to properly handle 403th error for send message requests.

I'm not too familiar with MTProto, but my guess would be, that this info is somehow available, and it would be a great help,

No, this information isn't available. Moreover, only bots receive an error and non-bots has no way to know that the other user blocked them.

[Bibo-Joshi]

All right, thanks for the detailed replies. From my point of view, getMessage would still be convenient for some use cases, but I can totally understand that if you don't to expose them with the risk of users requesting increased flood limits.

Apart from the two examples getMessage and bot-was-blocked, the intend of my original post was to have a general look, if some useful information can be exposed by methods allowed for bots anyway. E.g. the Pyrogram docs list that via MTProto bots can retrieve the whole chat members list of either public or private chats and get updates on e.g. user name changes.

Anyway, I'm happy to have the already great Bot API and the updates it already gets. It just seemed to me that it was worth asking, if double checking if some more helpful info could be exposed is an option :) Feel free to close, if you disagree on that.

[Muaath5]

I suggest method getChatUsers, And support pagination.

[levlam]

@Muaath5 Bots should use chat_member updates instead.

[Muaath5]

@Muaath5 Bots should use chat_member updates instead.

@levlam
Why bots should store all updates? It's bad that almost all bots needs a database.

[levlam]

@Muaath5
Its much worse to fetch the whole chat member list all the time.

[Bibo-Joshi]

I'd like to add that bots are not always added on chat creation and thus can't know about users that are already in the chat, so calling such a method once per chat sounds like a reasonable use case to me. (The (my_)chat_member updates are awesome btw 🙂 )

[levlam]

@Bibo-Joshi Bots aren't supposed to have access to past events. For example, this is never needed to handle chat_member or my_chat_member updates.

[Bibo-Joshi]

IMHO there is a difference between "past event" and "current state". E.g. get_chat existed before the (my_)chat_member updates existed, so you could/can get the current state without tracking the event. I guess the main point again is, that this info is avaible for bots anyway (through MTProto), so exposing the info through the Bot API doesn't imply that bots would get additional permissions.