-
Notifications
You must be signed in to change notification settings - Fork 1.4k
MTProto vs HTTP Bot API
This page aims to show that MTProto is superior to the HTTP Bot API (from now on referred to as "botapi") when developing bots for Telegram.
This page is in its early stages and needs a lot more work before being complete, so it's subject to major refactoring. If you have more information, please edit the page!
Status: Needs testing.
When you try to run multiple instances of a botapi bot, the old one will no longer receive updates from the server. MTProto lets you have multiple sessions active at the same time.
Status: Tested manually.
The botapi doesn't let you get any message by its ID. Instead, this is handled for you so that things like reply messages can always be provided.
In MTProto, bots can call messages.getMessages or channels.getMessages to get any message by its ID.
Status: Needs testing.
Usually in Telegram, you need an entity ID and an access hash to be able to do something with that entity (like send a message to a user).
The botapi stores the access hashes for a limited amount of time, after which it can no longer implicitly provide the access hash to you, so calls such as getChat will fail after your bot no longer has contact with the user for a while.
With MTProto you have full control over the access hashes, which allows you to perform tasks with the entity without relying on the server to store your access hashes.
Status: Tested manually.
The botapi has implicit resolving of channel usernames when making requests like sendMessage.
In MTProto bots can use contacts.resolveUsername to resolve anything by username.
Status: Tested manually.
The botapi lets you delete a single message with deleteMessage or forwardMessage.
MTProto lets you bulk delete or forward up to 100 messages at a time (messages.deleteMessages/channels.deleteMessages and messages.forwardMessages).
Status: Tested manually.
The botapi only allows getting a subset of the participants in a group, with getChatAdministrators to get administrators.
With MTProto, bots can use channels.getParticipants with plenty of different filters, which means you can fetch not only administrators but also banned people, kicked members, etc.
Status: Tested manually.
The botapi uses JSON to serialize data. JSON does not have a byte type,
only strings. This means that fields like callback_data in a
InlineKeyboardButton
can't accept arbitrary bytes like the description would have you
believe.
In MTProto you can use arbitrary bytes in this field: KeyboardButtonCallback.
Status: Tested manually.
The botapi only lets you use either HTML or Markup for adding text entities to your messages (eg: bold, links, etc).
With MTProto, entities are an entirely optional field in calls like messages.SendMessageRequest. This allows you to easily do things like making the entire message monospace without having to worry about escaping the text.
Status: Needs testing.
An example of this is when a user sends a message using an inline bot, the botapi does not provide the via_bot_id field of the message object, so you cannot tell which bot was used to send the message.
Status: Needs testing.
The botapi will inevitably need more work to be up and running after an update, while updating a MTProto based library can be done as soon as a layer change is published. Even if the botapi gets this change first, MTProto libraries can grab their layer. This is especially important in some cases:
For all the adminbot devs:
Bots can not see messages with animated stickers but clients already show them or show the "This message is not supported...." message. Which means groups can be spammed.
Status: Manual testing.
Using BotAPI, it has a maximum limit of 20MiB for downloading and 50MiB for uploading. Telethon has no such of limitations, you can upload and download files up to 2GiB.
Things that MTProto might do better than the botapi, but which we have no proof for.
Since the botapi servers use MTProto under the hood (through TDLib), using MTProto directly would give you less overhead.
This doesn't really mean much unless the botapi server goes down or starts being slow. In that case, calls like answerCallbackQuery can fail because you have a limited time to respond to it.
The botapi does not send certain updates to your bot, for example messages being deleted.
(TODO: Add table comparing the updates from MTProto and botapi)