Skip to content
A comparison of mtproto and the http botapi
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
README.md

README.md

HTTP Bot API vs MTProto comparison

This project 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 project 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 open an issue or send a pull request.

MTProto Advantages

Multiple Instances

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.

Get Messages by ID

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.

Full Control of Entity Access Hashes

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.

Resolve anything by username

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.

Bulk Delete and Forward

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).

Get participants of group

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.

Byte Types

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.

Full Control over Text Entities

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.

See More Fields

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.

Faster Updates

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.

Anecdotal Advantages

Things that MTProto might do better than the botapi, but which we have no proof for.

Less Overhead

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.

Update Comparison

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)

You can’t perform that action at this time.