diff --git a/data/core.telegram.org/api/terms.html b/data/core.telegram.org/api/terms.html deleted file mode 100644 index 20985c7cf7..0000000000 --- a/data/core.telegram.org/api/terms.html +++ /dev/null @@ -1,133 +0,0 @@ - - -
- -We welcome all developers to use our API and source code to create Telegram-like messaging applications on our platform free of charge. In order to ensure consistency and security across the Telegram ecosystem, all third-party client apps must comply with the following Terms of Service.
-1.1. Telegram is a privacy-oriented platform. All client apps must, therefore, guard their users' privacy with utmost care and comply with our Security Guidelines.
1.2. Developers are welcome to add new features or improve and extend existing Telegram features provided that these modifications do not violate these Terms of Service.
1.3. As a client developer, you must make sure that all the basic features of the main Telegram apps function correctly and in an expected way both in your app and when users of your app communicate with other Telegram users. It is forbidden to force users of other Telegram clients to download your app in order to view certain messages and content sent using your app.
1.4. It is forbidden to interfere with the basic functionality of Telegram. This includes but is not limited to: making actions on behalf of the user without the user's knowledge and consent, preventing self-destructing content from disappearing, preventing last seen and online statuses from being displayed correctly, tampering with the 'read' statuses of messages (e.g. implementing a 'ghost mode'), preventing typing statuses from being sent/displayed, etc.
2.1. You must obtain your own api_id for your application.
2.2. We offer our API free of charge, but your users must be aware of the fact that your app uses the Telegram API and is part of the Telegram ecosystem. This fact must be featured prominently in the app's description in the app stores and in the in-app intro if your app has it.
2.3. To avoid confusion, the title of your app must not include the word “Telegram”. An exception can be made if the word “Telegram” is preceded with the word “Unofficial” in the title.
2.4. You must not use the official Telegram logo for your app. Both the Telegram brand and its logo are registered trademarks protected by law in almost every country.
3.1. Developers are allowed to monetize their coding efforts through advertising or other legitimate means.
3.2. If you decide to monetize your app, you must clearly mention all the methods of monetization that are used in your app in all its app store descriptions.
3.3. If your app allows accessing content from Telegram channels, you must include support for official sponsored messages in Telegram channels and may not interefere with this functionality.
4.1. If your app violates these terms, we will notify the Telegram account responsible for the app about the breach of terms.
4.2. If you do not update the app to fix the highlighted issues within 10 days, we will have to discontinue your access to Telegram API and contact the app stores about the removal of your apps that are using the Telegram API in violation of these terms.
We reserve the right to expand these terms and guidelines as the need arises. We will inform client developers of such changes via an in-app notification to their accounts connected to the app in question.
-- --
++The Bot API is an HTTP-based interface created for developers keen on building bots for Telegram.
+
To learn how to create and set up a bot, please consult our Introduction to Bots »
You will find all changes to our Bot API on this page.
+++Subscribe to @BotNews to be the first to know about the latest updates and join the discussion in @BotTalk
+
Bot API 5.6
+Bot API 5.5
+Note: After this update it will become impossible to forward messages from some chats. Use the fields has_protected_content in the classes Message and Chat to check this.
+Note: After this update users are able to send messages on behalf of channels they own. Bots are expected to use the field sender_chat in the class Message to correctly support such messages.
+Note: As previously announced, user identifiers can now have up to 52 significant bits and require a 64-bit integer or double-precision float type to be stored safely.
+Bot API 5.4
+creates_join_request
to the methods createChatInviteLink and editChatInviteLink for managing chat invite links that create join requests (read more about this on our blog).creates_join_request
and pending_join_request_count
to the class ChatInviteLink.name
to the class ChatInviteLink and the parameters name
to the methods createChatInviteLink and editChatInviteLink for managing invite link names.++WARNING!
+
User identifiers will become bigger than2^31 - 1
before the end of this year and it will be no longer possible to store them in a signed 32-bit integer type. User identifiers will have up to 52 significant bits, so a 64-bit integer or double-precision float type would still be safe for storing them. Please make sure that your code can correctly handle such user identifiers.
Bot API 5.3
+Personalized Commands
+scope
and language_code
to the method setMyCommands to allow bots specify different commands for different chats and users.scope
and language_code
to the method getMyCommands.Custom Placeholders
+And More
+kickChatMember
to banChatMember. The old method name can still be used.getChatMembersCount
to getChatMemberCount. The old method name can still be used.file_unique_id
in objects of the type PhotoSize and of the fields small_file_unique_id
and big_file_unique_id
in objects of the type ChatPhoto were changed.++WARNING!
+
After one of the upcoming Bot API updates, user identifiers will become bigger than2^31 - 1
and it will be no longer possible to store them in a signed 32-bit integer type. User identifiers will have up to 52 significant bits, so a 64-bit integer or double-precision float type would still be safe for storing them. Please make sure that your code can correctly handle such user identifiers.
Bot API 5.2
+++WARNING!
+
After the next Bot API update (Bot API 5.3) there will be a one-time change of the value of the fieldfile_unique_id
in objects of the type PhotoSize and of the fieldssmall_file_unique_id
andbig_file_unique_id
in objects of the type ChatPhoto.
++WARNING!
+
Service messages about non-bot users joining the chat will be soon removed from large groups. We recommend using the “chat_member” update as a replacement.
++WARNING!
+
After one of the upcoming Bot API updates, user identifiers will become bigger than2^31 - 1
and it will be no longer possible to store them in a signed 32-bit integer type. User identifiers will have up to 52 significant bits, so a 64-bit integer or double-precision float type would still be safe for storing them. Please make sure that your code can correctly handle such user identifiers.
Bot API 5.1
+Added two new update types
+Improved Invite Links
+Voice Chat Info
+And More
+++WARNING!
+
After one of the upcoming Bot API updates, some user identifiers will become bigger than2^31 - 1
and it will be no longer possible to store them in a signed 32-bit integer type. User identifiers will have up to 52 significant bits, so a 64-bit integer or double-precision float type would still be safe for storing them. Please make sure that your code can correctly handle such user identifiers.
Introducing Bot API 5.0
+Run Your Own Bot API Server
+Transfer Bot Ownership
+Webhooks
+Working with Groups
+Working with Files
+Multiple Pinned Messages
+File Albums
+Live Locations
+Anonymous Admins
+And More
+And Last but not Least
+Bot API 4.9
+Bot API 4.8
+Bot API 4.7
+Bot API 4.6
+Bot API 4.5
+<u>/<ins>
(for underlined text) and <s>/<strike>/<del>
(for strikethrough text) in parse mode HTML.__
(for underlined text) and ~
(for strikethrough text). Parse mode Markdown remains unchanged for backward compatibility.Bot API 4.4
+149.154.160.0/20
and 91.108.4.0/22
. Most users won't need to do anything to continue receiving webhooks. If you control inbound access with a firewall, you may need to update your configuration. You can always find the list of actual IP addresses of servers used to send webhooks there: https://core.telegram.org/bots/webhooks.Bot API 4.3
+Also in this update:
+reply_markup
to the Message object, containing the inline keyboard attached to the message.149.154.160.0/20
and 91.108.4.0/22
. Most users won't need to do anything to continue receiving webhooks. If you control inbound access with a firewall, you may need to update your configuration. You can always find the list of actual IP addresses of servers used to send webhooks there: https://core.telegram.org/bots/webhooks.Bot API 4.2
+149.154.160.0/20
and 91.108.4.0/22
. Most users won't need to do anything to continue receiving webhooks. If you control inbound access with a firewall, you may need to update your configuration. You can always find the list of actual IP addresses of servers used to send webhooks there: https://core.telegram.org/bots/webhooks.Bot API 4.1
+Bot API 4.0.
+tg://
URLs now can be used in inline keyboard url buttons and text_link
message entities. Retry-After
response header to configure the delay after which the Bot API will retry the request after an unsuccessful response from a webhook.410 Gone
for all requests for more than 23 hours successively, it can be automatically removed.Bot API 3.6.
+Bot API 3.5.
+Bot API 3.4.
+Bot API 3.3.
+Bot API 3.2. Teach your bot to handle stickers and sticker sets.
+Bot API 3.1. Build your own robotic police force for supergoups with these new methods for admin bots:
+Introducing Bot API 3.0.
+NEW Payment Platform
+See Introduction to Bot Payments for a brief overview. If you're not a developer, you may like this user-friendly blog post better.
+NEW Video Messages
+NEW Multilingual Bots
+More power to admin bots
+Minor Changes
+Introducing Bot API 2.3.1, a nifty little update that will give you more control over how your bot gets its updates.
+Bot API 2.3
+Your bot can now get updates about posts in channels. Added new fields channel_post and edited_channel_post to Update.
+You can now update high scores to a lower value by using the new force parameter in setGameScore. Handy for punishing cheaters or fixing errors in your game's High Score table.
+Bot API 2.2. Introducing a new Gaming Platform! See this introduction for a brief overview.
If you're not a developer, you may like this user-friendly blog post better.
Other changes
+New method getWebhookInfo to check current webhook status.
+Added the option to specify an HTTP URL for a file in all methods where InputFile or file_id can be used (except voice messages). Telegram will get the file from the specified URL and send it to the user. Files must be smaller than 5 MB for photos and smaller than 20 MB for all other types of content.
+Introducing Bot API 2.0. Check out this page for a review of this major update.
+Inline bots
+/setinlinegeo
, added field location to the InlineQuery object, added fields location and inline_message_id to the ChosenInlineResult object.Miscellaneous
+setinlinefeedback
command for Botfather, new type ChosenInlineResult, new field chosen_inline_result to the Update object./setinline
to @BotFather.@channelusername
) in the place of chat_id in all methods (and instead of from_chat_id in forwardMessage). For this to work, the bot must be an administrator in the channel (and that's exactly what Telegram clients don't support yet — adding bots as administrators coming soon).The bot platform was officially launched.
++ ++
Deleted messages.
+===8===
+decryptedMessageActionDeleteMessages#65614304 random_ids:Vector<long> = DecryptedMessageAction;
+Name | +Type | +Description | +
---|---|---|
random_ids | +Vector<long> | +List of deleted message IDs | +
Messages marked as read.
+===8===
+decryptedMessageActionReadMessages#c4f40be random_ids:Vector<long> = DecryptedMessageAction;
+Name | +Type | +Description | +
---|---|---|
random_ids | +Vector<long> | +List of message IDs | +
++This document describes MTProto v.1.0, its status is DEPRECATED. +For information on encryption used in up-to-date Telegram clients, kindly see this document.
+
Prior to a message (or a multipart message) being transmitted over a network using a transport protocol, it is encrypted in a certain way, and an external header is added at the top of the message which is: a 64-bit key identifier (that uniquely identifies an authorization key for the server as well as the user) and a 128-bit message key.
+A user key together with the message key define an actual 256-bit key and a 256-bit initialization vector, which is what encrypts the message using AES-256 encryption with infinite garble extension (IGE). Note that the initial part of the message to be encrypted contains variable data (session, message ID, sequence number, server salt) that obviously influences the message key (and thus the AES key and iv). The message key is defined as the 128 lower-order bits of the SHA1 of the message body (including session, message ID, etc.) Multipart messages are encrypted as a single message.
+ +a 2048-bit key shared by the client device and the server, created upon user registration directly on the client device be exchanging Diffie-Hellman keys, and never transmitted over a network. Each authorization key is user-specific. There is nothing that prevents a user from having several keys (that correspond to “permanent sessions” on different devices), and some of these may be locked forever in the event the device is lost. See also Creating an Authorization Key.
+a 2048-bit RSA key used by the server digitally to sign its own messages while registration is underway and the authorization key is being generated. The application has a built-in public server key which can be used to verify a signature but cannot be used to sign messages. A private server key is stored on the server and changed very infrequently.
+The 64 lower-order bits of the SHA1 hash of the authorization key are used to indicate which particular key was used to encrypt a message. Keys must be uniquely defined by the 64 lower-order bits of their SHA1, and in the event of a collision, an authorization key is regenerated. A zero key identifier means that encryption is not used which is permissible for a limited set of message types used during registration to generate an authorization key based on a Diffie-Hellman exchange.
+a (random) 64-bit number generated by the client to distinguish between individual sessions (for example, between different instances of the application, created with the same authorization key). The session in conjunction with the key identifier corresponds to an application instance. The server can maintain session state. Under no circumstances can a message meant for one session be sent into a different session. The server may unilaterally forget any client sessions; clients should be able to handle this.
+a (random) 64-bit number periodically (say, every 24 hours) changed (separately for each session) at the request of the server. All subsequent messages must contain the new salt (although, messages with the old salt are still accepted for a further 300 seconds). Required to protect against replay attacks and certain tricks associated with adjusting the client clock to a moment in the distant future.
+a (time-dependent) 64-bit number used uniquely to identify a message within a session. Client message identifiers are divisible by 4, server message identifiers modulo 4 yield 1 if the message is a response to a client message, and 3 otherwise. Client message identifiers must increase monotonically (within a single session), the same as server message identifiers, and must approximately equal unixtime*2^32. This way, a message identifier points to the approximate moment in time the message was created. A message is rejected over 300 seconds after it is created or 30 seconds before it is created (this is needed to protect from replay attacks). In this situation, it must be re-sent with a different identifier (or placed in a container with a higher identifier). The identifier of a message container must be strictly greater than those of its nested messages.
+Important: to counter replay-attacks the lower 32 bits of msg_id passed by the client must not be empty and must present a fractional part of the time point when the message was created. At some point in the nearest future the server will start ignoring messages, in which the lower 32 bits of msg_id contain too many zeroes.
+A message requiring an explicit acknowledgment. These include all the user and many service messages, virtually all with the exception of containers and acknowledgments.
+a 32-bit number equal to twice the number of “content-related” messages (those requiring acknowledgment, and in particular those that are not containers) created by the sender prior to this message and subsequently incremented by one if the current message is a content-related message. A container is always generated after its entire contents; therefore, its sequence number is greater than or equal to the sequence numbers of the messages contained in it.
+The lower-order 128 bits of the SHA1 hash of the part of the message to be encrypted (including the internal header and excluding the alignment bytes).
+A header (16 bytes) added before a message or a container before it is all encrypted together. Consists of the server salt (64 bits) and the session (64 bits).
+A header (24 bytes) added before an encrypted message or a container. Consists of a key identifier (64 bits) and a message key (128 bits).
+External header + encrypted message or container.
+The 2048-bit authorization key (auth_key) and the 128-bit message key (msg_key) are used to compute a 256-bit AES key (aes_key) and a 256-bit initialization vector (aes_iv) which are subsequently used to encrypt the part of the message to be encrypted (i. e. everything with the exception of the external header which is added later) with AES-256 in infinite garble extension (IGE) mode.
+The algorithm for computing aes_key and aes_iv from auth_key and msg_key is as follows:
+where x = 0 for messages from client to server and x = 8 for those from server to client.
+The lower-order 1024 bits of auth_key are not involved in the computation. They may (together with the remaining bits or separately) be used on the client device to encrypt the local copy of the data received from the server. The 512 lower-order bits of auth_key are not stored on the server; therefore, if the client device uses them to encrypt local data and the user loses the key or the password, data decryption of local data is impossible (even if data from the server could be obtained).
+When AES is used to encrypt a block of data of a length not divisible by 16 bytes, the data is padded with random bytes to the smallest length divisible by 16 bytes immediately prior to being encrypted.
+When an encrypted message is received, it must be checked that msg_key is in fact equal to the 128 lower-order bits of the SHA1 hash of the previously encrypted portion, and that msg_id has even parity for messages from client to server, and odd parity for messages from server to client.
+In addition, the identifiers (msg_id) of the last N messages received from the other side must be stored, and if a message comes in with msg_id lower than all or equal to any of the stored values, the message is to be ignored. Otherwise, the new message msg_id is added to the set, and, if the number of stored msg_id values is greater than N, the oldest (i. e. the lowest) is forgotten.
+In addition, msg_id values that belong over 30 seconds in the future or over 300 seconds in the past are to be ignored. This is especially important for the server. The client would also find this useful (to protect from a replay attack), but only if it is certain of its time (for example, if its time has been synchronized with that of the server).
+Certain client-to-server service messages containing data sent by the client to the server (for example, msg_id of a recent client query) may, nonetheless, be processed on the client even if the time appears to be “incorrect”. This is especially true of messages to change server_salt and notifications of invalid client time. See Mobile Protocol: Service Messages.
+It may be suggested to users concerned with security that they password protect the authorization key in approximately the same way as in ssh. This is accomplished by adding the SHA1 of the key to the front of the key, following which the entire string is encrypted using AES in CBC mode and a key equal to the user’s (text) password. When the user inputs the password, the stored protected password is decrypted and verified by being compared with SHA1. From the user’s standpoint, this is practically the same as using an application or a website password.
+Special plain-text messages may be used to create an authorization key as well as to perform a time synchronization. They begin with auth_key_id = 0 (64 bits) which means that there is no auth_key. This is followed directly by the message body in serialized format without internal or external headers. A message identifier (64 bits) and body length in bytes (32 bytes) are added before the message body.
+Only a very limited number of messages of special types can be transmitted as plain text.
+auth_key_id int64 |
+msg_key int128 |
+encrypted_data bytes |
+
Contains the cypher text for the following data:
+salt int64 |
+session_id int64 |
+message_id int64 |
+seq_no int32 |
+message_data_length int32 |
+message_data bytes |
+padding 0..15 bytes |
+
auth_key_id = 0 int64 |
+message_id int64 |
+message_data_length int32 |
+message_data bytes |
+
An authorization key is normally created once for every user during the application installation process immediately prior to registration. Registration itself, in actuality, occurs after the authorization key is created. However, a user may be prompted to complete the registration form while the authorization key is being generated in the background. Intervals between user key strokes may be used as a source of entropy in the generation of high-quality random numbers required for the creation of an authorization key.
+See Creating an Authorization Key.
+During the creation of the authorization key, the client obtains its server salt (to be used with the new key for all communication in the near future). The client then creates an encrypted session using the newly generated key, and subsequent communication occurs within that session (including the transmission of the user's registration information and phone number validation) unless the client creates a new session. The client is free to create new or additional sessions at any time by choosing a new random session_id.