diff --git a/data/core.telegram.org/api/payments.html b/data/core.telegram.org/api/payments.html deleted file mode 100644 index bae6a2988a..0000000000 --- a/data/core.telegram.org/api/payments.html +++ /dev/null @@ -1,366 +0,0 @@ - - - - - Payments API - - - - - - - - - - - - - -
- -
-
-
- -

Payments API

- -
- -

You can accept payments from Telegram users via Telegram Bots.

-
-

Note: This article is intended for MTProto API developers. If you're looking for a general overview of Telegram Payments, check out the Telegram blog and the bot API payment manual.

-
-

Introducing Payments

-

Telegram bots can accept payments for goods and services from users. -For more info on how payments work, check out the Telegram Blog and the bot API payment manual.

-

This page will elaborate on the actions required to work with payments using the MTProto API.

-
-

A simplified version of the process is available only for bots using the bot API.

-
-

The first step for bots is enable payments as described here ».

-

Then, we work with payments as follows.

-

1. Create Invoice

-
inputWebDocument#9bed434d url:string size:int mime_type:string attributes:Vector<DocumentAttribute> = InputWebDocument;
-
-labeledPrice#cb296bf8 label:string amount:long = LabeledPrice;
-
-invoice#cd886e0 flags:# test:flags.0?true name_requested:flags.1?true phone_requested:flags.2?true email_requested:flags.3?true shipping_address_requested:flags.4?true flexible:flags.5?true phone_to_provider:flags.6?true email_to_provider:flags.7?true currency:string prices:Vector<LabeledPrice> max_tip_amount:flags.8?long suggested_tip_amounts:flags.8?Vector<long> = Invoice;
-
-inputMediaInvoice#d9799874 flags:# title:string description:string photo:flags.0?InputWebDocument invoice:Invoice payload:bytes provider:string provider_data:DataJSON start_param:flags.1?string = InputMedia;
-
----functions---
-
-messages.sendMedia#3491eba9 flags:# silent:flags.5?true background:flags.6?true clear_draft:flags.7?true peer:InputPeer reply_to_msg_id:flags.0?int media:InputMedia message:string random_id:long reply_markup:flags.2?ReplyMarkup entities:flags.3?Vector<MessageEntity> schedule_date:flags.10?int = Updates;
-

The user contacts the bot and requests to purchase something. -The bot forms an inputMediaInvoice with an invoice constructor with a description of the goods or service, amount to be paid, as well as requested shipping info. -The provider parameter of the inputMediaInvoice constructor is where you put the token value that you've obtained earlier via Botfather. It is possible for one merchant bot to use several different tokens for different users or different goods and services.

-

Use the messages.sendMedia method to send the invoice. -You can also attach an inline keyboard to the message using the reply_markup field: if provided, the first button must be a keyboardButtonBuy button. Otherwise, an inline keyboard will be generated automatically, with a Pay 'total price' keyboardButtonBuy as only button.

-

An invoice message with a pay button can only be sent to a private chat with the user. Groups and channels are not supported.

-

2. Order information

-

2.1 Invoice message

-
keyboardButtonBuy#afd93fbb text:string = KeyboardButton;
-
-keyboardButtonRow#77608b83 buttons:Vector<KeyboardButton> = KeyboardButtonRow;
-replyInlineMarkup#48a30254 rows:Vector<KeyboardButtonRow> = ReplyMarkup;
-
-webDocument#1c570ed1 url:string access_hash:long size:int mime_type:string attributes:Vector<DocumentAttribute> = WebDocument;
-webDocumentNoProxy#f9c8bcc6 url:string size:int mime_type:string attributes:Vector<DocumentAttribute> = WebDocument;
-
-messageMediaInvoice#84551347 flags:# shipping_address_requested:flags.1?true test:flags.3?true title:string description:string photo:flags.0?WebDocument receipt_msg_id:flags.2?int currency:string total_amount:long start_param:string = MessageMedia;
-
-message#85d6cbe2 flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true from_scheduled:flags.18?true legacy:flags.19?true edit_hide:flags.21?true pinned:flags.24?true id:int from_id:flags.8?Peer peer_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?long reply_to:flags.3?MessageReplyHeader date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int forwards:flags.10?int replies:flags.23?MessageReplies edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long restriction_reason:flags.22?Vector<RestrictionReason> ttl_period:flags.25?int = Message;
-
-updateNewMessage#1f2b0afd message:Message pts:int pts_count:int = Update;
-

The user receives an updateNewMessage constructor from the bot, containing a messageMediaInvoice constructor with basic info about the product.

-

The message will also have a replyInlineMarkup keyboard attached to it. -The the first button of the keyboard will always be a keyboardButtonBuy button.

-

2.2 Getting invoice info about the product

-
invoice#cd886e0 flags:# test:flags.0?true name_requested:flags.1?true phone_requested:flags.2?true email_requested:flags.3?true shipping_address_requested:flags.4?true flexible:flags.5?true phone_to_provider:flags.6?true email_to_provider:flags.7?true currency:string prices:Vector<LabeledPrice> max_tip_amount:flags.8?long suggested_tip_amounts:flags.8?Vector<long> = Invoice;
-
-paymentRequestedInfo#909c3f94 flags:# name:flags.0?string phone:flags.1?string email:flags.2?string shipping_address:flags.3?PostAddress = PaymentRequestedInfo;
-
-paymentSavedCredentialsCard#cdc27a1f id:string title:string = PaymentSavedCredentials;
-
-payments.paymentForm#1694761b flags:# can_save_credentials:flags.2?true password_missing:flags.3?true form_id:long bot_id:long invoice:Invoice provider_id:long url:string native_provider:flags.4?string native_params:flags.4?DataJSON saved_info:flags.0?PaymentRequestedInfo saved_credentials:flags.1?PaymentSavedCredentials users:Vector<User> = payments.PaymentForm;
-
----functions---
-
-payments.getPaymentForm#8a333c8d flags:# peer:InputPeer msg_id:int theme_params:flags.0?DataJSON = payments.PaymentForm;
-

If the user clicks on the keyboardButtonBuy button, the client proceeds to call payments.getPaymentForm with the message ID of the invoice preview message to get the payment form.

-

The returned form will contain fields that should be passed to the payment provider along with the full invoice. -The payment form also contains info about previously saved payment credentials and order information (name, phone number, email, shipping address & so on).

-

The full invoice contains info about the information required for the order, the price and the currency, and whether this is a test order.

-

2.3 Verifying information

-
invoice#cd886e0 flags:# test:flags.0?true name_requested:flags.1?true phone_requested:flags.2?true email_requested:flags.3?true shipping_address_requested:flags.4?true flexible:flags.5?true phone_to_provider:flags.6?true email_to_provider:flags.7?true currency:string prices:Vector<LabeledPrice> max_tip_amount:flags.8?long suggested_tip_amounts:flags.8?Vector<long> = Invoice;
-
-postAddress#1e8caaeb street_line1:string street_line2:string city:string state:string country_iso2:string post_code:string = PostAddress;
-
-paymentRequestedInfo#909c3f94 flags:# name:flags.0?string phone:flags.1?string email:flags.2?string shipping_address:flags.3?PostAddress = PaymentRequestedInfo;
-
-payments.validatedRequestedInfo#d1451883 flags:# id:flags.0?string shipping_options:flags.1?Vector<ShippingOption> = payments.ValidatedRequestedInfo;
-
----functions---
-
-payments.validateRequestedInfo#db103170 flags:# save:flags.0?true peer:InputPeer msg_id:int info:PaymentRequestedInfo = payments.ValidatedRequestedInfo;
-

If any data at all is requested by the invoice (name_requested, phone_requested, email_requested, shipping_address_requested), the user must call payments.validateRequestedInfo, providing the required data (as usual, msg_id is the ID of the invoice message). -The user can choose to save order information for future use by setting the save flag. -Data can be autofilled as described in autofill.

-

If no errors are found in the submitted info, the response of the method will contain an id flag, to be used later to complete the payment.

-

If the flexible flag of the invoice is set, calling the payments.validateRequestedInfo method will send a shipping query update to the bot, to which the bot will reply with the available shipping options for the specified address as described here ». -The return value in this case will also contain a shipping_options field with the available shipping options.

-

If any errors are found in the submmitted data, a service notification will be sent to the user, with a description of the error from the bot.

-

2.3.1 Autofill

-
payments.savedInfo#fb8fe43c flags:# has_saved_credentials:flags.1?true saved_info:flags.0?PaymentRequestedInfo = payments.SavedInfo;
-
----functions---
-
-payments.getSavedInfo#227d824b = payments.SavedInfo;
-payments.clearSavedInfo#d83d70c1 flags:# credentials:flags.0?true info:flags.1?true = Bool;
-

The requested fields can be autofilled with the info provided in the saved_info field of the payment form, or with the info fetched manually using payments.getSavedInfo.

-

Saved order information can also be cleared using payments.clearSavedInfo.

-

2.4 Select delivery option

-
labeledPrice#cb296bf8 label:string amount:long = LabeledPrice;
-
-shippingOption#b6213cdf id:string title:string prices:Vector<LabeledPrice> = ShippingOption;
-
-updateBotShippingQuery#b5aefd7d query_id:long user_id:long payload:bytes shipping_address:PostAddress = Update;
-
----functions---
-
-messages.setBotShippingResults#e5f672fa flags:# query_id:long error:flags.0?string shipping_options:flags.1?Vector<ShippingOption> = Bool;
-

If a shipping address was requested and the bot included the parameter flexible, when the user validates order information the Telegram API will send an updateBotShippingQuery to the bot. -The bot must respond using messages.setBotShippingResults either with a list of possible delivery options and the relevant delivery prices, or with an error (for example, if delivery to the specified address is not possible).

-

The returned shipping options or the shipping error will be returned to the user while validating order information.

-

3. Payment

-
inputPaymentCredentialsSaved#c10eb2cf id:string tmp_password:bytes = InputPaymentCredentials;
-inputPaymentCredentials#3417d728 flags:# save:flags.0?true data:DataJSON = InputPaymentCredentials;
-inputPaymentCredentialsApplePay#aa1c39f payment_data:DataJSON = InputPaymentCredentials;
-inputPaymentCredentialsGooglePay#8ac32801 payment_token:DataJSON = InputPaymentCredentials;
-
-
-payments.paymentForm#1694761b flags:# can_save_credentials:flags.2?true password_missing:flags.3?true form_id:long bot_id:long invoice:Invoice provider_id:long url:string native_provider:flags.4?string native_params:flags.4?DataJSON saved_info:flags.0?PaymentRequestedInfo saved_credentials:flags.1?PaymentSavedCredentials users:Vector<User> = payments.PaymentForm;
-

3.1 Web payment

-
inputPaymentCredentials#3417d728 flags:# save:flags.0?true data:DataJSON = InputPaymentCredentials;
-
-payments.paymentForm#1694761b flags:# can_save_credentials:flags.2?true password_missing:flags.3?true form_id:long bot_id:long invoice:Invoice provider_id:long url:string native_provider:flags.4?string native_params:flags.4?DataJSON saved_info:flags.0?PaymentRequestedInfo saved_credentials:flags.1?PaymentSavedCredentials users:Vector<User> = payments.PaymentForm;
-

Typically, payment takes place by opening the url in the specified payment form, which leads to a payment form on the website of the payment gateway. -Once the user finishes entering their payment credentials, a payment_form_submit web event is generated by the payment gateway, containing data and title JSON fields.

-

The title is used by the client app to represent the payment credentials (typically a censored version of credit card information). -The data is used to generate an inputPaymentCredentials constructor. -Eventually, you can set the save flag to save the credit card info for future use, only if 2FA is enabled.

-

Telegram does not have access to your card information. Credit card details will be handled only by the payment system.

-

3.2 Native payment

-
inputPaymentCredentials#3417d728 flags:# save:flags.0?true data:DataJSON = InputPaymentCredentials;
-
-payments.paymentForm#1694761b flags:# can_save_credentials:flags.2?true password_missing:flags.3?true form_id:long bot_id:long invoice:Invoice provider_id:long url:string native_provider:flags.4?string native_params:flags.4?DataJSON saved_info:flags.0?PaymentRequestedInfo saved_credentials:flags.1?PaymentSavedCredentials users:Vector<User> = payments.PaymentForm;
-

Most telegram apps support working natively with the native APIs of some payment providers, without opening the website of the payment and receiving a JS event.

-

This is done using the JSON native_params parameters field of the payments.paymentForm constructor, which contains an object, which can contain one or more of the following fields:

-
    -
  • publishable_key: Stripe API publishable key
  • -
  • apple_pay_merchant_id: Apple Pay merchant ID
  • -
  • android_pay_public_key: Android Pay public key
  • -
  • android_pay_bgcolor: Android Pay form background color
  • -
  • android_pay_inverse: Whether to use the dark theme in the Android Pay form
  • -
  • need_country: True, if the user country must be provided,
  • -
  • need_zip: True, if the user ZIP/postal code must be provided,
  • -
  • need_cardholder_name: True, if the cardholder name must be provided
  • -
-

The payment gateway to use is decided based on the value of the native_provider field.

-
3.2.1 Stripe
-
inputPaymentCredentials#3417d728 flags:# save:flags.0?true data:DataJSON = InputPaymentCredentials;
-
-payments.paymentForm#1694761b flags:# can_save_credentials:flags.2?true password_missing:flags.3?true form_id:long bot_id:long invoice:Invoice provider_id:long url:string native_provider:flags.4?string native_params:flags.4?DataJSON saved_info:flags.0?PaymentRequestedInfo saved_credentials:flags.1?PaymentSavedCredentials users:Vector<User> = payments.PaymentForm;
-

If the native_provider field is set and equal to stripe, the client can make use of the native Stripe token APIs with the publishable_key from the native_params to add a payment method to Stripe, and then use the token type and id to generate a JSON object:

-
{"type":"token.type", "id":"token.id"}"
-

The generated JSON object can then be passed to the data field of the inputPaymentCredentials. -Eventually, you can set the save flag to save the credit card info for future use, only if 2FA is enabled.

-

Telegram does not have access to your card information. Credit card details will be handled only by the payment system.

-

Example implementation: Telegram for Android.

-

3.3 Apple pay

-
inputPaymentCredentialsApplePay#aa1c39f payment_data:DataJSON = InputPaymentCredentials;
-

On iOS devices, Apple Pay can be used to generate payment data, which is then sent using the inputPaymentCredentialsApplePay constructor.

-

Example implementation: Telegram for iOS.

-

3.4 Android pay

-
inputPaymentCredentialsGooglePay#8ac32801 payment_token:DataJSON = InputPaymentCredentials;
-

On Android devices, Google Pay can be used to generate payment data, which is then sent using the inputPaymentCredentialsGooglePay constructor.

-

Example implementation: Telegram for Android.

-

3.5 Using saved payment credentials

-
inputPaymentCredentialsSaved#c10eb2cf id:string tmp_password:bytes = InputPaymentCredentials;
-
-paymentSavedCredentialsCard#cdc27a1f id:string title:string = PaymentSavedCredentials;
-
-payments.paymentForm#1694761b flags:# can_save_credentials:flags.2?true password_missing:flags.3?true form_id:long bot_id:long invoice:Invoice provider_id:long url:string native_provider:flags.4?string native_params:flags.4?DataJSON saved_info:flags.0?PaymentRequestedInfo saved_credentials:flags.1?PaymentSavedCredentials users:Vector<User> = payments.PaymentForm;
-
-account.tmpPassword#db64fd34 tmp_password:bytes valid_until:int = account.TmpPassword;
-
----functions---
-
-account.getTmpPassword#449e0b51 password:InputCheckPasswordSRP period:int = account.TmpPassword;
-

To reuse saved payment methods, the saved_credentials field of the payment form is used. -The title of the paymentSavedCredentialsCard can be used to preview a censored version of credit card info. -The id field is provided by the payment provider directly to the Telegram servers when saving the payment method, and identifies the payment method. -Full credit card info is not saved on Telegram Servers, and cannot be fetched by the user.

-

In order to use the saved payment method, 2FA must be enabled: the user must verify their identity by entering their 2FA password, which is then used as described in the SRP docs to generate SRP parameters which must be passed to account.getTmpPassword.

-

The generated temporary password can then be used to make payments using the saved credentials using the inputPaymentCredentialsSaved constructor.

- -

Example implementation: Telegram for Android.

-

4. Pre-Checkout

-
inputPaymentCredentialsSaved#c10eb2cf id:string tmp_password:bytes = InputPaymentCredentials;
-inputPaymentCredentials#3417d728 flags:# save:flags.0?true data:DataJSON = InputPaymentCredentials;
-inputPaymentCredentialsApplePay#aa1c39f payment_data:DataJSON = InputPaymentCredentials;
-inputPaymentCredentialsGooglePay#8ac32801 payment_token:DataJSON = InputPaymentCredentials;
-
-payments.paymentResult#4e5f810d updates:Updates = payments.PaymentResult;
-payments.paymentVerificationNeeded#d8411139 url:string = payments.PaymentResult;
-
----functions---
-
-payments.sendPaymentForm#30c3bc9d flags:# form_id:long peer:InputPeer msg_id:int requested_info_id:flags.0?string shipping_option_id:flags.1?string credentials:InputPaymentCredentials tip_amount:flags.2?long = payments.PaymentResult;
-

After verifying order information, the final step for the client is to call payments.sendPaymentForm, with the following parameters:

-
    -
  • The msg_id is set to the ID of the invoice message
  • -
  • requested_info_id is set to the id of the verified order information, if it was requested
  • -
  • shipping_option_id is set to the selected delivery option, if shipping was requested.
  • -
  • credentials are the payment credentials generated by the payment provider, required to complete the order.
  • -
-

Payment method info can also be saved to the Telegram Servers and reused, by setting the save flag of inputPaymentCredentials when sending the form. -This is only possible on accounts with 2FA enabled.

-

The bot then replies to the received precheckout query, finally the user proceeds to checkout.

-

Please note that if the result of the method is a payments.paymentVerificationNeeded, before proceeding to checkout the payment provider requires the user to verify his identity by opening the provided url and following instructions. -Once the user finishes working with the webpage, the client can proceed to checkout.

-

Eventual errors are returned in the form of RPC errors, with the description of the error by the bot contained in service updates.

-

4.1 Receiving pre-checkout query

-
paymentRequestedInfo#909c3f94 flags:# name:flags.0?string phone:flags.1?string email:flags.2?string shipping_address:flags.3?PostAddress = PaymentRequestedInfo;
-
-updateBotPrecheckoutQuery#8caa9a96 flags:# query_id:long user_id:long payload:bytes info:flags.0?PaymentRequestedInfo shipping_option_id:flags.1?string currency:string total_amount:long = Update;
-
----functions---
-
-messages.setBotPrecheckoutResults#9c2dd95 flags:# success:flags.1?true query_id:long error:flags.0?string = Bool;
-

The user enters their payment information as described above and presses the final pay button. -At this moment the Telegram API sends an updateBotPrecheckoutQuery constructor that contains all the available information about the order to the bot. -The bot must reply using messages.setBotPrecheckoutResults within 10 seconds after receiving this update or the transaction is canceled.

-

The bot may return an error if it can‘t process the order for any reason. We highly recommend specifying a reason for failure to complete the order in human readable form (e.g. "Sorry, we’re all out of rubber ducks! Would you be interested in a steel bear instead?"). Telegram will display this reason to the user.

-

5. Checkout

-
keyboardButtonBuy#afd93fbb text:string = KeyboardButton;
-
-keyboardButtonRow#77608b83 buttons:Vector<KeyboardButton> = KeyboardButtonRow;
-replyInlineMarkup#48a30254 rows:Vector<KeyboardButtonRow> = ReplyMarkup;
-
-messageMediaInvoice#84551347 flags:# shipping_address_requested:flags.1?true test:flags.3?true title:string description:string photo:flags.0?WebDocument receipt_msg_id:flags.2?int currency:string total_amount:long start_param:string = MessageMedia;
-
-message#85d6cbe2 flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true from_scheduled:flags.18?true legacy:flags.19?true edit_hide:flags.21?true pinned:flags.24?true id:int from_id:flags.8?Peer peer_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?long reply_to:flags.3?MessageReplyHeader date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int forwards:flags.10?int replies:flags.23?MessageReplies edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long restriction_reason:flags.22?Vector<RestrictionReason> ttl_period:flags.25?int = Message;
-
-updateNewMessage#1f2b0afd message:Message pts:int pts_count:int = Update;
-
-payments.paymentReceipt#70c4fe03 flags:# date:int bot_id:long provider_id:long title:string description:string photo:flags.2?WebDocument invoice:Invoice info:flags.0?PaymentRequestedInfo shipping:flags.1?ShippingOption tip_amount:flags.3?long currency:string total_amount:long credentials_title:string users:Vector<User> = payments.PaymentReceipt;
-
----functions---
-
-payments.getPaymentReceipt#2478d1cc peer:InputPeer msg_id:int = payments.PaymentReceipt;
-

In case the bot confirms the order, Telegram requests the payment provider to complete the transaction. If the payment information was entered correctly and the payment goes through, the Telegram API will modify the invoice message and send a service message as described below. Once your bot receives this message, it should proceed with delivering the goods or services purchased by the user.

-

If all is OK, the user receives a payments.paymentResult in reply to the payments.sendPaymentForm query, containing info about the updated invoice message in the form of an updateEditMessage.

-

The invoice message will be updated as follows: the attached messageMediaInvoice will now have a receipt_msg_id field. -Clients should treat invoice messages with a receipt_msg_id field as receipt messages, locally modifying the label of the keyboardButtonBuy button to a localized version of the word Receipt. -From this point, clicking on the Receipt button should trigger a call to payments.getPaymentReceipt, providing the receipt_msg_id to the msg_id field, which will return info about the transaction.

-

The payment will also generate one service message of type messageActionPaymentSent or messageActionPaymentSentMe, replying to the invoice. -For bots, the service message will be of type messageActionPaymentSentMe, for users it will be a messageActionPaymentSent.

-
messageActionPaymentSentMe#8f31b327 flags:# currency:string total_amount:long payload:bytes info:flags.0?PaymentRequestedInfo shipping_option_id:flags.1?string charge:PaymentCharge = MessageAction;
-messageActionPaymentSent#40699cd0 currency:string total_amount:long = MessageAction;
- -
- -
-
- -
- - - - - - - - diff --git a/data/core.telegram.org/api/push-updates.html b/data/core.telegram.org/api/push-updates.html deleted file mode 100644 index 14cfeddc8c..0000000000 --- a/data/core.telegram.org/api/push-updates.html +++ /dev/null @@ -1,1009 +0,0 @@ - - - - - Handling PUSH-notifications - - - - - - - - - - - - - -
- -
-
-
- -

Handling PUSH-notifications

- -
- -

Configuring the application

-

To be able to send APNS notifications to Apple servers or GCM notifications to Google servers, application certificates (APNS) or an application key (GCM) must be specified in the application settings.

-

Subscribing to notifications

-

To subscribe to notifications, the client must invoke the account.registerDevice query, passing in token_type and token as parameters that identify the current device. It is useful to repeat this query at least once every 24 hours or when restarting the application. Use account.unregisterDevice to unsubscribe.

-

The following modes are supported:

-
    -
  • 1 - APNS (device token for apple push)
  • -
  • 2 - FCM (firebase token for google firebase)
  • -
  • 3 - MPNS (channel URI for microsoft push)
  • -
  • 4 - Deprecated: Simple push (endpoint for firefox's simple push API)
  • -
  • 5 - Ubuntu phone (token for ubuntu push)
  • -
  • 6 - Blackberry (token for blackberry push)
  • -
  • 7 - MTProto separate session
  • -
  • 8 - WNS (windows push)
  • -
  • 9 - APNS VoIP (token for apple push VoIP)
  • -
  • 10 - Web push (web push, see below)
  • -
  • 11 - MPNS VoIP (token for microsoft push VoIP)
  • -
  • 12 - Tizen (token for tizen push)
  • -
-

For 10 web push, the token must be a JSON-encoded object with the following keys:

-
    -
  • endpoint: Absolute URL exposed by the push service where the application server can send push messages
  • -
  • keys: P-256 elliptic curve Diffie-Hellman parameters in the following object
      -
    • p256dh: Base64url-encoded P-256 elliptic curve Diffie-Hellman public key
    • -
    • auth: Base64url-encoded authentication secret
    • -
    -
  • -
-

Notification encryption

-

For FCM and APNS VoIP, an optional encryption key used to encrypt push notifications can be passed to account.registerDevice (secret). This key (auth_key) is used to encrypt the payloads using MTProto v2.

-

The FCM payload will be a JSON payload, containing a p field with the base64-encoded encrypted MTProto payload. After decryption, the result will be a JSON object, prefixed by a 32-bit little-endian integer with the length of the JSON payload. As usual, make sure to follow all security checks as described in the MTProto docs.

-

Example implementation.

-

As mentioned above, payloads can also be encrypted using P-256 Elliptic Curve Diffie-Hellman when using web push.

-

Notification structure

-

An (optionally encrypted) notification is provided as a JSON object in the following format:

-
{
-  "data": {
-    "loc_key": "CHAT_MESSAGE_CONTACT",
-    "loc_args": ["John Doe", "My magical group", "Contact Exchange"],
-    "user_id": 14124122,
-    "custom": {
-      "chat_id": 241233,
-      "msg_id": 123
-    },
-    "sound": "sound1.mp3",
-  }
-}
-

Each notification has several parameters that describe it.

-

Notification type

-

data.loc_key - A string literal in the form /[A-Z_0-9]+/, which summarizes the notification. For example, CHAT_MESSAGE_TEXT.

-

Notification text arguments

-

data.loc_args - A list or arguments which, when inserted into a template, produce a readable notification.

-

Custom parameters

-

data.custom - Parameters which are be passed into the application when a notification is opened.

-

Sound

-

data.sound - The name of an audio file to be played.

-

User id

-

data.user_id - ID of the account to which the PUSH notification should be delivered, in case of clients with multiple accounts active and running.

-

Processing notifications

-

In principle, data.loc_key, data.custom, and an Internet connection are sufficient to generate a notification. Obviously, if possible, when generating a visual notification you need not use all of the transmitted data and may rely on the information already stored on the client. But if a user or a chat is not cached locally, the values passed in loc_args may also be used. data.user_id is the ID of the account to which the PUSH notification should be delivered, in case of clients with multiple accounts active and running.

-

Service notifications

-

The following notifications can be used to update app settings.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeExtra custom argumentsDescription
DC_UPDATEdc - number of the data-center
addr - server address with port number in the format 111.112.113.114:443
In case the client gets this notification, it is necessary to add the received server address to the list of possible addresses. In case the address of the first DC was passed (dc=1), it is recommended to call it immediately using help.getConfig to update dc-configuration.
MESSAGE_DELETEDchannel_id: For channels and supergroups, Channel/supergroup identifier
chat_id: For chats, Chat identifier
from_id: For PMs, Author identifier
messages: Comma-separated IDs of messages that were deleted
Messages were deleted, remove multiple notifications for this chat
READ_HISTORYchannel_id: For channels and supergroups, Channel/supergroup identifier
chat_id: For chats, Chat identifier
from_id: For PMs, Author identifier
max_id: Maximum ID of read messages
Message history was read, remove multiple notifications for this chat
GEO_LIVE_PENDING Any of the live locations currently being shared should be updated
SESSION_REVOKE Logout and remove DB for specified session by data.user_id, only apply if coming from an MTProto-encrypted payload
MESSAGE_MUTED Sent rarely, every 10th message in chats or once per 15 sec in PM, to update badge or download messages
-

Possible Notifications

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeTemplate exampleArgumentsExtra custom arguments
AUTH_REGIONNew login from unrecognized device {1}, location: {2}1. Device name
2. Location
 
AUTH_UNKNOWNNew login from unrecognized device {1}1. Device name 
CHANNEL_MESSAGES{1} posted an album1. Message authorattachb64: Base64-encoded version of the attached media (related to the first message)
channel_id: Channel/supergroup identifier (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
CHANNEL_MESSAGE_AUDIO{1} posted a voice message1. Message authorattachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_CONTACT{1} posted a contact {2}1. Message author
2. Contact name
attachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_DOC{1} posted a file1. Message authorattachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_DOCS{1} posted {2} files1. Channel name
2. Number of documents that were posted
attachb64: Base64-encoded version of the attached media (related to the first message)
channel_id: Channel/supergroup identifier (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
CHANNEL_MESSAGE_FWDS{1} posted {2} forwarded messages1. Message author
2. Number of forwarded messages
attachb64: Base64-encoded version of the attached media (related to the first message)
channel_id: Channel/supergroup identifier (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
CHANNEL_MESSAGE_GAME{1} invited you to play {2}1. Message author
2. Game name
attachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_GAME_SCORE{1} scored {3} in game {2}1. User
2. Game name
3. Score
attachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_GEO{1} posted a location1. Channel nameattachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_GEOLIVE{1} posted a live location1. Channel nameattachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_GIF{1} posted a GIF1. Channel nameattachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_NOTEXT{1} posted a message1. Channel nameattachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_PHOTO{1} posted a photo1. Channel nameattachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_PHOTOS{1} posted {2} photos1. Channel name
2. Number of photos that was sent
attachb64: Base64-encoded version of the attached media (related to the first message)
channel_id: Channel/supergroup identifier (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
CHANNEL_MESSAGE_PLAYLIST{1} posted {2} music files1. Channel name
2. Number of audio files that were posted
attachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_POLL{1} posted a poll {2}1. Channel name
2. Poll name
attachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_QUIZ{1} posted a quiz {2}1. Channel name
2. Quiz name
attachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_ROUND{1} posted a video message1. Channel nameattachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_STICKER{1} posted a {2} sticker1. Channel name
2. Sticker emoji
attachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_TEXT{1}: {2}1. Channel name
2. Message body
attachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_VIDEO{1} posted a video1. Channel nameattachb64: Base64-encoded version of the attached media
channel_id: Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHANNEL_MESSAGE_VIDEOS{1} posted {2} videos1. Channel name
2. Number of videos that were posted
attachb64: Base64-encoded version of the attached media (related to the first message)
channel_id: Channel/supergroup identifier (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
CHAT_ADD_MEMBER{1} invited {3} to the group {2}1. Message author
2. Chat name
3. New participant name
chat_id: chat identifier
CHAT_ADD_YOU{1} invited you to the group {2}1. User name
2. Group name
chat_id: chat identifier
CHAT_CREATED{1} invited you to the group {2}1. Message author
2. Chat name
chat_id: chat identifier
CHAT_DELETE_MEMBER{1} removed {3} from the group {2}1. Message author
2. Chat name
3. Dropped participant name
chat_id: chat identifier
CHAT_DELETE_YOU{1} removed you from the group {2}1. Message author
2. Chat name
chat_id: chat identifier
CHAT_JOINED{1} joined the group {2}1. User name
2. Group name
chat_id: chat identifier
CHAT_LEFT{1} left the group {2}1. Message author
2. Chat name
chat_id: chat identifier
CHAT_MESSAGES{1} sent an album to the group {2}1. User name
2. Group name
chat_from_id: Message author identifier
chat_id: chat identifier
mention: Whether the user was mentioned in the message
CHAT_MESSAGE_AUDIO{1} sent a voice message to the group {2}1. Message author
2. Chat name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_CONTACT{1} shared a contact {3} in the group {2}1. User name
2. Group name
3. Contact name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_DOC{1} sent a file to the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_DOCS{1} sent {3} files to the group {2}1. User name
2. Group name
3. Number of documents that were sent
attachb64: Base64-encoded version of the attached media (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
chat_id: Chat identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
CHAT_MESSAGE_FWDS{1} forwarded {3} messages to the group {2}1. User name
2. Group name
3. Number of messages that were forwarded
attachb64: Base64-encoded version of the attached media (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
chat_id: Chat identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
CHAT_MESSAGE_GAME{1} invited the group {2} to play {3}1. User name
2. Group name
3. Game name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_GAME_SCORE{1} scored {4} in game {3} in the group {2}1. User name
2. Group name
3. Game name
4. Score
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_GEO{1} sent a location to the group {2}1. Message author
2. Chat name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_GEOLIVE{1} shared a live location with the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_GIF{1} sent a GIF to the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_INVOICE{1} sent an invoice to the group {2} for {3}1. User name
2. Group name
3. Product name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_NOTEXT{1} sent a message to the group {2}1. Message author
2. Chat name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_PHOTO{1} sent a photo to the group {2}1. Message author
2. Chat name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_PHOTOS{1} sent {3} photos to the group {2}1. User name
2. Group name
3. Number of photos that were sent
attachb64: Base64-encoded version of the attached media (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
chat_id: Chat identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
CHAT_MESSAGE_PLAYLIST{1} sent {3} music files to the group {2}1. User name
2. Group name
3. Number of audio files that were sent
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_POLL{1} sent a poll {3} to the group {2}1. User name
2. Group name
3. Poll name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_QUIZ{1} sent a quiz {3} to the group {2}1. User name
2. Group name
3. Quiz name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_ROUND{1} sent a video message to the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_STICKER{1} sent a {3} sticker to the group {2}1. User name
2. Group name
3. Sticker emoji
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_TEXT{1} @ {2}: {3}1. Message author
2. Chat name
3. Message body
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_VIDEO{1} sent a video to the group {2}1. Message author
2. Chat name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
chat_id: Chat identifier
edit_date: When was the message last edited
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
CHAT_MESSAGE_VIDEOS{1} sent {3} videos to the group {2}1. User name
2. Group name
3. Number of videos that were sent
attachb64: Base64-encoded version of the attached media (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
chat_id: Chat identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
CHAT_PHOTO_EDITED{1} changed the group photo for {2}1. Message author
2. Chat name
chat_from_id: Message author identifier
chat_id: chat identifier
msg_id: ID of the message
CHAT_RETURNED{1} returned to the group {2}1. Message author
2. Chat name
chat_id: chat identifier
CHAT_TITLE_EDITED{1} renamed the group {2}1. User name
2. Group name
chat_id: chat identifier
CHAT_VOICECHAT_END{1} ended a voice chat in the group {2}1. User name
2. Chat name
 
CHAT_VOICECHAT_INVITE{1} invited {3} to a voice chat in the group {2}1. User name
2. Chat name
3. Invited users
 
CHAT_VOICECHAT_INVITE_YOU{1} invited you to a voice chat in the group {2}1. User name
2. Chat name
 
CHAT_VOICECHAT_START{1} started a voice chat in the group {2}1. User name
2. Chat name
 
CONTACT_JOINED{1} joined Telegram!1. Contact namecontact_id: contact identifier
ENCRYPTED_MESSAGEYou have a new message encryption_id: secret chat identifier
random_id: message identifier
ENCRYPTION_ACCEPTYou have a new message encryption_id: secret chat identifier
ENCRYPTION_REQUESTYou have a new message encryption_id: secret chat identifier
LOCKED_MESSAGEYou have a new message  
MESSAGES{1} sent you an album1. User namefrom_id: author identifier
MESSAGE_ANNOUNCEMENT{1}1. Announcementannouncement: Announcement: roughly equivalent to a message received from the service notifications (Telegram Notifications, id 777000) user, but must be delivered via push notifications, without contacting the API.
MESSAGE_AUDIO{1} sent you a voice message1. Message authorattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_CONTACT{1} shared a contact {2} with you1. User name
2. Contact name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_DOC{1} sent you a file1. User nameattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_DOCS{1} sent you {2} files1. User name
2. Number of documents that were sent
attachb64: Base64-encoded version of the attached media (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
from_id: Author identifier (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
MESSAGE_FWDS{1} forwarded you {2} messages1. User name
2. Number of messages that were forwarded
attachb64: Base64-encoded version of the attached media (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
from_id: Author identifier (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
MESSAGE_GAME{1} invited you to play {2}1. User name
2. Game name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_GAME_SCORE{1} scored {3} in game {2}1. User name
2. Game name
3. Score
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_GEO{1} sent you a location1. Message authorattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_GEOLIVE{1} sent you a live location1. User nameattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_GIF{1} sent you a GIF1. User nameattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_INVOICE{1} sent you an invoice for {2}1. User name
2. Product
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_NOTEXT{1} sent you a message1. Message authorattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_PHOTO{1} sent you a photo1. Message authorattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_PHOTOS{1} sent you {2} photos1. User name
2. Number of photos that were sent
attachb64: Base64-encoded version of the attached media (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
from_id: Author identifier (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
MESSAGE_PHOTO_SECRET{1} sent you a self-destructing photo1. User nameattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_PLAYLIST{1} sent you {2} music files1. User name
2. Number of audio files that were sent
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_POLL{1} sent you a poll {2}1. User name
2. Poll name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_QUIZ{1} sent you a quiz {2}1. User name
2. Quiz name
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_ROUND{1} sent you a video message1. User nameattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_SCREENSHOT{1} took a screenshot1. User nameattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_STICKER{1} sent you a {2} sticker1. User name
2. Sticker emoji
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_TEXT{1}: {2}1. Message author
2. Message body
attachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_VIDEO{1} sent you a video1. Message authorattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
MESSAGE_VIDEOS{1} sent you {2} videos1. User name
2. Number of videos that were sent
attachb64: Base64-encoded version of the attached media (related to the first message)
chat_from_id: Groups only, message author identifier (related to the first message)
edit_date: When was the message last edited (related to the first message)
from_id: Author identifier (related to the first message)
mention: Whether the user was mentioned in the message (related to the first message)
msg_id: ID of the message (related to the first message)
silent: Whether the message was posted silently (no notification should be issued) (related to the first message)
MESSAGE_VIDEO_SECRET{1} sent you a self-destructing video1. User nameattachb64: Base64-encoded version of the attached media
chat_from_id: Groups only, message author identifier
edit_date: When was the message last edited
from_id: Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
scheduled: Whether this is a scheduled message
silent: Whether the message was posted silently (no notification should be issued)
PHONE_CALL_MISSEDYou missed a call from {1}1. User name 
PHONE_CALL_REQUEST{1} is calling you!1. User namecall_ah: Call access hash
call_id: Call ID
PINNED_AUDIO{1} pinned a voice message1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_AUDIO{1} pinned a voice message in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_CONTACT{1} pinned a contact {2}1. User name
2. Contact name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_CONTACT{1} pinned a contact {3} in the group {2}1. User name
2. Group name
3. Contact name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_DOC{1} pinned a file1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_DOC{1} pinned a file in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_GAME{1} pinned a game1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_GAME{1} pinned a game in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_GAME_SCORE{1} pinned a game score1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_GAME_SCORE{1} pinned a game score in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_GEO{1} pinned a map1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_GEO{1} pinned a map in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_GEOLIVE{1} pinned a live location1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_GEOLIVE{1} pinned a live location in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_GIF{1} pinned a GIF1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_GIF{1} pinned a GIF in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_INVOICE{1} pinned an invoice1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_INVOICE{1} pinned an invoice in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_NOTEXT{1} pinned a message1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_NOTEXT{1} pinned a message in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_PHOTO{1} pinned a photo1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_PHOTO{1} pinned a photo in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_POLL{1} pinned a poll {2}1. User name
2. Poll name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_POLL{1} pinned a poll {3} in the group {2}1. User name
2. Group name
3. Poll name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_QUIZ{1} pinned a quiz {2}1. User name
2. Quiz name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_QUIZ{1} pinned a quiz {3} in the group {2}1. User name
2. Group name
3. Quiz name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_ROUND{1} pinned a video message1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_ROUND{1} pinned a video message in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_STICKER{1} pinned a {2} sticker1. User name
2. Sticker emoji
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_STICKER{1} pinned a {3} sticker in the group {2}1. User name
2. Group name
3. Sticker emoji
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_TEXT{1} pinned "{2}"1. User name
2. Message body
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_TEXT{1} pinned "{3}" in the group {2}1. User name
2. Group name
3. Message body
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_VIDEO{1} pinned a video1. User nameattachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
PINNED_VIDEO{1} pinned a video in the group {2}1. User name
2. Group name
attachb64: Base64-encoded version of the attached media
channel_id: For channels and supergroups, Channel/supergroup identifier
chat_from_id: Groups only, message author identifier
chat_id: For chats, Chat identifier
edit_date: When was the message last edited
from_id: For PMs, Author identifier
mention: Whether the user was mentioned in the message
msg_id: ID of the message
silent: Whether the message was posted silently (no notification should be issued)
- -
- -
-
- -
- - - - - - - - diff --git a/data/core.telegram.org/api/updates.html b/data/core.telegram.org/api/updates.html deleted file mode 100644 index 6f1e6d89c6..0000000000 --- a/data/core.telegram.org/api/updates.html +++ /dev/null @@ -1,226 +0,0 @@ - - - - - Working with Updates - - - - - - - - - - - - - -
- -
-
-
- -

Working with Updates

- -
- -

When a client is being actively used, events will occur that affect the current user and that they must learn about as soon as possible, e.g. when a new message is received. To eliminate the need for the client itself to periodically download these events, there is an update delivery mechanism in which the server sends the user notifications over one of its available connections with the client.

-

Subscribing to Updates

-

Update events are sent to an authorized user into the last active connection (except for connections needed for downloading / uploading files).

-

So to start receiving updates the client needs to init connection and call API method, e.g. to fetch current state.

-

Event sequences

-

All events are received from the socket as a sequence of TL-serialized Updates objects, which might be optionally gzip-compressed in the same way as responses to queries.

-

Each Updates object may contain single or multiple Update objects, representing different events happening.

-

In order to apply all updates in precise order and to guarantee that no update is missed or applied twice there is seq attribute in Updates constructors, and pts (with pts_count) or qts attributes in Update constructors. The client must use those attributes values in combination with locally stored state to correctly apply incoming updates.

-

When a gap in updates sequence occurs, it must be filled via calling one of the API methods. More below »

-

Updates sequence

-

As said earlier, each payload with updates has a TL-type Updates. It can be seen from the schema below that this type has several constructors.

-
updatesTooLong#e317af7e = Updates;
-updateShort#78d4dec1 update:Update date:int = Updates;
-updateShortMessage#313bc7f8 flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true id:int user_id:long message:string pts:int pts_count:int date:int fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?long reply_to:flags.3?MessageReplyHeader entities:flags.7?Vector<MessageEntity> ttl_period:flags.25?int = Updates;
-updateShortChatMessage#4d6deea5 flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true id:int from_id:long chat_id:long message:string pts:int pts_count:int date:int fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?long reply_to:flags.3?MessageReplyHeader entities:flags.7?Vector<MessageEntity> ttl_period:flags.25?int = Updates;
-updateShortSentMessage#9015e101 flags:# out:flags.1?true id:int pts:int pts_count:int date:int media:flags.9?MessageMedia entities:flags.7?Vector<MessageEntity> ttl_period:flags.25?int = Updates;
-updatesCombined#725b04c3 updates:Vector<Update> users:Vector<User> chats:Vector<Chat> date:int seq_start:int seq:int = Updates;
-updates#74ae4240 updates:Vector<Update> users:Vector<User> chats:Vector<Chat> date:int seq:int = Updates;
-

updatesTooLong indicates that there are too many events pending to be pushed to the client, so one needs to fetch them manually.

-

Events inside updateShort constructors, normally, have lower priority and are broadcast to a large number of users, i.e. one of the chat participants started entering text in a big conversation (updateChatUserTyping).

-

The updateShortMessage, updateShortSentMessage and updateShortChatMessage constructors are redundant but help significantly reduce the transmitted message size for 90% of the updates. They should be transformed to updateShort upon receiving.

-

Two remaining constructors updates and updatesCombined are part of the Updates sequence. Both of them have seq attribute, which indicates the remote Updates state after the generation of the Updates, and seq_start indicates the remote Updates state after the first of the Updates in the packet is generated. For updates, seq_start attribute is omitted, because it is assumed that it is always equal to seq.

-

Message-related event sequences

-

Each event related to a message box (message created, message edited, message deleted, etc) is identified by a unique autoincremented pts, or qts in case of secret chat updates, certain bot updates, etc.

-

Each message box can be considered as some server-side DB table that stores messages and events associated with them. -All boxes are completely independent, and each pts sequence is tied to just one box (see below).

-

Update object may contain info about multiple events (for example, updateDeleteMessages). -That's why all single updates might have pts_count parameter indicating the number of events contained in the received update (with some exceptions, in this case, the pts_count is considered to be 0).

-

Each channel and supergroup has its message box and its event sequence as a result; private chats and legacy groups of one user have another common event sequence. -Secret chats, certain bot events and other kinds of updates have yet another common secondary event sequence.

-

To recap, the client has to take care of the integrity of the following sequences to properly handle updates:

-
    -
  • Updates sequence (seq)
      -
    • Common message box sequence (pts)
    • -
    • Secondary event sequence (qts)
    • -
    • Channel message box sequence 1 (pts)
    • -
    • Channel message box sequence 2 (pts)
    • -
    • Channel message box sequence 3 (pts)
    • -
    • and so on...
    • -
    -
  • -
-

Fetching state

-

The common update state is represented by the updates.State constructor. -When the user logs in for the first time, call to updates.getState has to be made to store the latest update state (which will not be the absolute initial state, just the latest state at the current time). -The common update state can also be fetched from updates.differenceTooLong.

-

The channel update state is represented simply by the pts of the event sequence: when first logging in, the initial channel state can be obtained from the dialog constructor when fetching dialogs, from the full channel info, or it can be received as an updateChannelTooLong update.

-

The secondary update state is represented by the qts of the secret event sequence, it is contained in the updates.State of the common update state.

-

The Updates sequence state is represented by the date and seq of the Updates sequence, it is contained in the updates.State of the common update state.

-

Update handling

-

Update handling in Telegram clients consists of receiving events, making sure there were no gaps and no events were missed based on the locally stored state of the correspondent event sequence, and then updating the locally stored state based on the parameters received.

-

When the client receives payload with serialized updates, first of all, it needs to walk through all of the nested Update objects and check if they belong to any of message box sequences (have pts or qts parameters). Those updates need to be handled separately according to corresponding local state and new pts/qts values. Details below »

-

After message box updates are handled, if there are any other updates remaining the client needs to handle them with respect to seq. Details below »

-

pts: checking and applying

-

Here, local_pts will be the local state, pts will be the remote state, pts_count will be the number of events in the update.

-

If local_pts + pts_count === pts, the update can be applied. -If local_pts + pts_count > pts, the update was already applied, and must be ignored. -If local_pts + pts_count < pts, there's an update gap that must be filled.

-

For example, let's assume the client has the following local state for the channel 123456789:

-
local_pts = 131
-

Now let's assume an updateNewChannelMessage from channel 123456789 is received with pts = 132 and pts_count=1. -Since local_pts + pts_count === pts, the total number of events since the last stored state is, in fact, equal to pts_count: this means the update can be safely accepted and the remote pts applied:

-
local_pts = 132
-

Since:

-
    -
  • pts indicates the server state after the new channel message events are generated
  • -
  • pts_count indicates the number of events in the new channel update
  • -
  • The server state before the new channel message event was generated has to be: pts_before = pts - pts_count = 131, which is, in fact, equal to our local state.
  • -
-

Now let's assume an updateNewChannelMessage from channel 123456789 is received with pts = 132 and pts_count=1. -Since local_pts + pts_count > pts (133 > 132), the update is skipped because we've already handled this update (in fact, our current local_pts was set by this same update, and it was resent twice due to network issues or other issues).

-

Now let's assume an updateDeleteChannelMessages from channel 123456789 is received with pts = 140 and pts_count=5. -Since local_pts + pts_count < pts (137 < 140), this means that updates were missed, and the gap must be recovered.

-
Secret chats & bots
-

The whole process is very similar for secret chats and certain bot updates, but there is qts instead of pts, and events are never grouped, so it's assumed that qts_count is always equal to 1.

-

seq: checking and applying

-

On top level when handling received updates and updatesCombined there are three possible cases: -If local_seq + 1 === seq_start, the updates can be applied. -If local_seq + 1 > seq_start, the updates were already applied, and must be ignored. -If local_seq + 1 < seq_start, there's an updates gap that must be filled (updates.getDifference must be used as with common and secret event sequences).

-

If the updates were applied, local Updates state must be updated with seq and date from the constructor.

-

For all the other Updates type constructors there is no need to check seq or change a local state.

-

Recovering gaps

-

To do this, updates.getDifference (common/secret state) or updates.getChannelDifference (channel state) with the respective local states must be called. -These methods should also be called on startup, to fetch new updates (preferably with some flags to reduce server load, see the method's docs). -Manually obtaining updates is also required in the following situations:

-
    -
  • Loss of sync: a gap was found in seq / pts / qts (as described above). It may be useful to wait up to 0.5 seconds in this situation and abort the sync in case a new update arrives, that fills the gap.
  • -
  • Session loss on the server: the client receives a new session created notification. This can be caused by garbage collection on the MTProto server or a server reboot.
  • -
  • Incorrect update: the client cannot deserialize the received data.
  • -
  • Incomplete update: the client is missing data about a chat/user from one of the shortened constructors, such as updateShortChatMessage, etc.
  • -
  • Long period without updates: no updates for 15 minutes or longer.
  • -
  • The server requests the client to fetch the difference using updateChannelTooLong or updatesTooLong.
  • -
-

When calling updates.getDifference if the updates.differenceSlice constructor is returned in response, the full difference was too large to be received in one request. The intermediate status, intermediate_state, must be saved on the client and the query must be repeated, using the intermediate status as the current status.

-

To fetch the updates difference of a channel, updates.getChannelDifference is used. -If the difference is too large to be received in one request, the final flag of the result is not set (see docs). -The intermediate status, represented by the pts, must be saved on the client and the query must be repeated, using the intermediate status as the current status.

-

For perfomance reasons and for better user experience, client can set maximum gap size to be filled: pts_total_limit parameter of updates.getDifference and limit parameter for updates.getChannelDifference can be used.

-

If the gap is too large and there are too many updates to fetch, a *TooLong constructor will be returned. In this case, the client must re-fetch the state, re-start fetching updates from that state and follow the instructions that can be found here.

-

It is recommended to use limit 10-100 for channels and 1000-10000 otherwise.

-

Example implementations

-

Implementations also have to take care to postpone updates received via the socket while filling gaps in the event and Update sequences, as well as avoid filling gaps in the same sequence.

-

Example implementations: tdlib, MadelineProto.

-

An interesting and easy way this can be implemented, instead of using various locks, is by running background loops, like in MadelineProto ».

-

PUSH Notifications about Updates

-

If a client does not have an active connection at the time of an event, PUSH Notifications will also be useful.

- -
- -
-
- -
- - - - - - - - diff --git a/data/core.telegram.org/constructor/payments.ValidatedRequestedInfo b/data/core.telegram.org/constructor/payments.ValidatedRequestedInfo deleted file mode 100644 index ac3d46faf0..0000000000 --- a/data/core.telegram.org/constructor/payments.ValidatedRequestedInfo +++ /dev/null @@ -1,145 +0,0 @@ - - - - - payments.ValidatedRequestedInfo - - - - - - - - - - - - - -
- -
-
-
- -

payments.ValidatedRequestedInfo

- -

Validated user-provided info

-

{schema}

-

Parameters

- - - - - - - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
flags#Flags, see TL conditional fields
idflags.0?stringID
shipping_optionsflags.1?Vector<ShippingOption>Shipping options
-

Type

-

payments.ValidatedRequestedInfo

- -
- -
-
- -
- - - - - - diff --git a/data/corefork.telegram.org/constructor/true.html b/data/corefork.telegram.org/constructor/true.html deleted file mode 100644 index 9a3db4259f..0000000000 --- a/data/corefork.telegram.org/constructor/true.html +++ /dev/null @@ -1,134 +0,0 @@ - - - - - true - - - - - - - - - - - - - -
- -
-
-
- -

true

- -

See predefined identifiers.

-

- -
-
true#3fedd339 = True;

-

Parameters

-

This constructor does not require any parameters.

-

Type

-

True

-

Related pages

-

TL-formal

- -
- -
-
- -
- - - - - - diff --git a/data/corefork.telegram.org/mtproto/description.html b/data/corefork.telegram.org/mtproto/description.html deleted file mode 100644 index 8893708b9f..0000000000 --- a/data/corefork.telegram.org/mtproto/description.html +++ /dev/null @@ -1,238 +0,0 @@ - - - - - Mobile Protocol: Detailed Description - - - - - - - - - - - - - -
- -
-
-
- -

Mobile Protocol: Detailed Description

- -
- -
-

As of version 4.6, major Telegram clients are using MTProto 2.0. -MTProto v.1.0 is deprecated and is currently being phased out.

-
-

This article describes the basic layer of the MTProto protocol version 2.0 (Cloud chats, server-client encryption). The principal differences from version 1.0 (described here for reference) are as follows:

-
    -
  • SHA-256 is used instead of SHA-1;
  • -
  • Padding bytes are involved in the computation of msg_key;
  • -
  • msg_key depends not only on the message to be encrypted, but on a portion of auth_key as well;
  • -
  • 12..1024 padding bytes are used instead of 0..15 padding bytes in v.1.0.
  • -
-

See also: MTProto 2.0: Secret Chats, end-to-end encryption

-

Protocol description

-

Before a message (or a multipart message) is 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 that consists of a 64-bit key identifier auth_key_id (that uniquely identifies an authorization key for the server as well as the user) and a 128-bit message key msg_key.

-

The authorization key auth_key combined with the message key msg_key define an actual 256-bit key aes_key and a 256-bit initialization vector aes_iv, which are used to encrypt the message using AES-256 encryption in infinite garble extension (IGE) mode. 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). In MTProto 2.0, the message key is defined as the 128 middle bits of the SHA-256 of the message body (including session, message ID, padding, etc.) prepended by 32 bytes taken from the authorization key. In the older MTProto 1.0, the message key was computed as the lower 128 bits of SHA-1 of the message body, excluding the padding bytes.

-

Multipart messages are encrypted as a single message.

- -
-

Got questions about this setup? — Check out the Advanced FAQ!

-
-
Note 1
-

Each plaintext message to be encrypted in MTProto always contains the following data to be checked upon decryption in order to make the system robust against known problems with the components:

-
    -
  • server salt (64-Bit)
  • -
  • session id
  • -
  • message sequence number
  • -
  • message length
  • -
  • time
  • -
-
Note 2
-

Telegram's End-to-end encrypted Secret Chats are using an additional layer of encryption on top of the described above. See Secret Chats, End-to-End encryption for details.

-

Terminology

-

Authorization Key (auth_key)

-

A 2048-bit key shared by the client device and the server, created upon user registration directly on the client device by 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.

-

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

-

Key Identifier (auth_key_id)

-

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 in a Diffie-Hellman exchange. For MTProto 2.0, SHA1 is still used here, because auth_key_id should identify the authorization key used independently of the protocol version.

-

Session

-

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.

-

Server Salt

-

A (random) 64-bit number changed every 30 minutes (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 1800 seconds). Required to protect against replay attacks and certain tricks associated with adjusting the client clock to a moment in the distant future.

-

Message Identifier (msg_id)

-

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.

-

Content-related Message

-

A message requiring an explicit acknowledgment. These include all the user and many service messages, virtually all with the exception of containers and acknowledgments.

-

Message Sequence Number (msg_seqno)

-

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.

-

Message Key (msg_key)

-

In MTProto 2.0, the middle 128 bits of the SHA-256 hash of the message to be encrypted (including the internal header and the padding bytes for MTProto 2.0), prepended by a 32-byte fragment of the authorization key.

-

In MTProto 1.0, message key was defined differently, as the lower 128 bits of the SHA-1 hash of the message to be encrypted, with padding bytes excluded from the computation of the hash. Authorization key was not involved in this computation.

-

Internal (cryptographic) Header

-

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

-

External (cryptographic) Header

-

A header (24 bytes) added before an encrypted message or a container. Consists of the key identifier auth_key_id (64 bits) and the message key msg_key (128 bits).

-

Payload

-

External header + encrypted message or container.

-

Defining AES Key and Initialization Vector

-

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 that is added later) with AES-256 in infinite garble extension (IGE) mode.

-

For MTProto 2.0, the algorithm for computing aes_key and aes_iv from auth_key and msg_key is as follows.

-
    -
  • msg_key_large = SHA256 (substr (auth_key, 88+x, 32) + plaintext + random_padding);
  • -
  • msg_key = substr (msg_key_large, 8, 16);
  • -
  • sha256_a = SHA256 (msg_key + substr (auth_key, x, 36));
  • -
  • sha256_b = SHA256 (substr (auth_key, 40+x, 36) + msg_key);
  • -
  • aes_key = substr (sha256_a, 0, 8) + substr (sha256_b, 8, 16) + substr (sha256_a, 24, 8);
  • -
  • aes_iv = substr (sha256_b, 0, 8) + substr (sha256_a, 8, 16) + substr (sha256_b, 24, 8);
  • -
-

where x = 0 for messages from client to server and x = 8 for those from server to client.

-

For the obsolete MTProto 1.0, msg_key, aes_key, and aes_iv were computed differently (see this document for reference).

-

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

-

In MTProto 1.0, when AES was used to encrypt a block of data of a length not divisible by 16 bytes, the data was padded with 0 to 15 random padding bytes random_padding to a length divisible by 16 bytes prior to encryption. In MTProto 2.0, this padding is taken into account when computing msg_key. Note that MTProto 2.0 requires from 12 to 1024 bytes of padding, still subject to the condition that the resulting message length be divisible by 16 bytes.

-

Using MTProto 2.0 instead of MTProto 1.0

-

A client may either use only MTProto 2.0 or only MTProto 1.0 in the same TCP connection. The server detects the protocol used by the first message received from the client, and then uses the same encryption for its messages, and expects the client to use the same encryption henceforth. We recommend using MTProto 2.0; MTProto 1.0 is deprecated and supported for backward compatibility only.

-

Important Checks

-

When an encrypted message is received, it must be checked that msg_key is in fact equal to the 128 middle bits of the SHA-256 of the decrypted data with a 32-byte fragment of auth_key prepended to it, 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.

-

On top of this, 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.

-

Storing an Authorization Key on a Client Device

-

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 can be accomplished by prepending the value of cryptographic hash function, such as SHA-256, 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 checking the SHA-256 value. From the user’s standpoint, this is practically the same as using an application or a website password.

-

Unencrypted Messages

-

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.

-

Schematic Presentation of Messages

-

Encrypted Message

- - - - -
auth_key_id
int64
msg_key
int128
encrypted_data
bytes
-

Encrypted Message: encrypted_data

-

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
padding12..1024
bytes
-

Unencrypted Message

- - - - - -
auth_key_id = 0
int64
message_id
int64
message_data_length
int32
message_data
bytes
-

MTProto 2.0 uses 12..1024 padding bytes, instead of the 0..15 used in MTProto 1.0

-

Creating an Authorization Key

-

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.

- -
- -
-
- -
- - - - - - - - diff --git a/data/corefork.telegram.org/mtproto/description_v1.html b/data/corefork.telegram.org/mtproto/description_v1.html deleted file mode 100644 index ca2ed0b856..0000000000 --- a/data/corefork.telegram.org/mtproto/description_v1.html +++ /dev/null @@ -1,205 +0,0 @@ - - - - - Mobile Protocol: Detailed Description (v.1.0, DEPRECATED) - - - - - - - - - - - - - -
- -
-
-
- -

Mobile Protocol: Detailed Description (v.1.0, DEPRECATED)

- -
-

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.

- -

Terminology

-

Authorization Key

-

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.

-

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

-

Key Identifier

-

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.

-

Session

-

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.

-

Server Salt

-

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.

-

Message Identifier (msg_id)

-

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.

-

Content-related Message

-

A message requiring an explicit acknowledgment. These include all the user and many service messages, virtually all with the exception of containers and acknowledgments.

-

Message Sequence Number (msg_seqno)

-

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.

-

Message Key

-

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

-

Internal (cryptographic) Header

-

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

-

External (cryptographic) Header

-

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

-

Payload

-

External header + encrypted message or container.

-

Defining AES Key and Initialization Vector

-

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:

-
    -
  • msg_key = substr (SHA1 (plaintext), 4, 16);
  • -
  • sha1_a = SHA1 (msg_key + substr (auth_key, x, 32));
  • -
  • sha1_b = SHA1 (substr (auth_key, 32+x, 16) + msg_key + substr (auth_key, 48+x, 16));
  • -
  • sha1_с = SHA1 (substr (auth_key, 64+x, 32) + msg_key);
  • -
  • sha1_d = SHA1 (msg_key + substr (auth_key, 96+x, 32));
  • -
  • aes_key = substr (sha1_a, 0, 8) + substr (sha1_b, 8, 12) + substr (sha1_c, 4, 12);
  • -
  • aes_iv = substr (sha1_a, 8, 12) + substr (sha1_b, 0, 8) + substr (sha1_c, 16, 4) + substr (sha1_d, 0, 8);
  • -
-

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.

-

Important Tests

-

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.

-

Storing an Authorization Key on a Client Device

-

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.

-

Unencrypted Messages

-

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.

-

Schematic Presentation of Messages

-

Encrypted Message

- - - - -
auth_key_id
int64
msg_key
int128
encrypted_data
bytes
-

Encrypted Message: encrypted_data

-

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
-

Unencrypted Message

- - - - - -
auth_key_id = 0
int64
message_id
int64
message_data_length
int32
message_data
bytes
-

Creating an Authorization Key

-

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.

- -
- -
-
- -
- - - - - - diff --git a/data/corefork.telegram.org/themes.html b/data/corefork.telegram.org/themes.html deleted file mode 100644 index 4c05d75ae0..0000000000 --- a/data/corefork.telegram.org/themes.html +++ /dev/null @@ -1,143 +0,0 @@ - - - - - Creating Custom Cloud Themes - - - - - - - - - - - - - -
- -
-
-
-
-

Creating Custom Cloud Themes

- -

Official Telegram apps support custom cloud themes as of version 5.11. Everyone is welcome to create and share their themes.

-

Creating a theme

-

You can use the Online Theme Editor (use a VPN if it is blocked in your country) to create new Telegram themes from scratch or edit existing ones. Simply log in with your Telegram account and pick a platform to start editing the relevant theme file – or import an existing theme.

-
    -
  • Set a name for your theme using the name attribute
  • -
  • Set colors for elements using hex codes or the color picker
  • -
  • Press ‘Save and apply theme’ to push changes to all users of your theme
  • -
-

Checking your theme in-app

-

Once you have saved a theme for the first time, Telegram will send you a message with its sharing link. Open the link in the app to switch to your theme.

-

You can always switch to your theme in Settings > Chat Settings. On iOS and MacOS native app – Settings > Appearance.

-

Publishing your theme

-

Each theme has a t.me/addtheme link which people can use to switch to your theme. You can choose a beautiful short link (e.g., https://t.me/addtheme/desert) by changing the shortname attribute. If you add support for multiple platforms, the same link can be used for setting your theme on all of them.

-

Updating your theme

-

Your theme gets updated automatically for all its users whenever you save and apply changes.

-

Including a chat background

-

Your themes can include a custom wallpaper. To do this, simply go to Settings > Chat Settings > Chat Background. On iOS and MacOS native app – Settings > Appearance > Chat Background.

-

Open any background and tap the sharing button in the top right corner, then copy its t.me/bg/... link. In the theme file, set this link as the value of the wallpaper attribute.

-

For Telegram Desktop, if you want to make the background tiled, add ?mode=tiled at the end of the link. For example:

-
wallpaper: t.me/bg/-jI7lnO3DFABAAAA1vXcFaZP_Vo?mode=tiled
-

Creating themes in-app

-

If you prefer a more WYSIWYG approach, try creating themes using the in-app tools for customizing appearance. Telegram for Android and Telegram Desktop have advanced in-app theme editors. Telegram for iOS and MacOS allow choosing a custom accent color from the color wheel and a background, then saving the result as a custom theme.

-

Once you have saved a new theme in any of the apps, it also becomes accessible in the online editor.

-

Read more

- -
- -
- -
-
- -
- - - - - - diff --git a/data/telegram.org/blog/cryptocontest.html b/data/telegram.org/blog/cryptocontest.html deleted file mode 100644 index 4d3e6fd5fd..0000000000 --- a/data/telegram.org/blog/cryptocontest.html +++ /dev/null @@ -1,224 +0,0 @@ - - - - - $300,000 for Cracking Telegram Encryption - - - - - - - - - - - - - - - - - - - -
-
- -
-
-
- -
-
-

$300,000 for Cracking Telegram Encryption

- -
- -
- -
-

This contest is over, but Telegram's bug bounty program is always open.

-

Security researchers are welcome to submit any issues they find in the Telegram apps or protocol to us at security@telegram.org. All submissions which result in a change of code or configuration are eligible for bounties, ranging from $500 to $100,000 or more, depending on the severity of the issue.

-
-

Earlier this year we had a contest to decipher intercepted Telegram messages, that did not produce a winner. Today we announce a new contest with an easier task and a larger prize — $300,000 for cracking Telegram's encryption, and this time contestants can not only monitor traffic, but also act as the Telegram server and use active attacks, which vastly increases their capabilities.

-

In this contest you assume the role of a malicious entity in full control of both the communication lines and the Telegram servers themselves.

-
-

UPD The current round of the contest is over. Go to results »

-
-

Your goal is to extract sensitive data (a secret email address) from a Secret Chat between two users — Nick and Paul. You control the entire process, from chat creation to the sending of each individual message and can perform various active attacks, including MITM, KPA, CPA, replay attacks, etc.

-

Contest Interface

-

In order to facilitate the task, we have created an interface, using which you can act as the server and determine which side gets what data. For more details, please check out the Cracking Contest Description.

-

Objectives

-

In order to confirm that Telegram crypto was indeed cracked and claim your $300,000, you‘ll need to send an email to the secret email address that you’ve extracted from one of the messages exchanged by Paul and Nick.

-

Your email must contain:
- The entire text of the message that contained the secret email.
- Session logs for the successful attempt with your user_id.
- A detailed explanation of the attack on the protocol.
- Your bank account details to receive the $300,000 prize.

-

There is also a bonus objective with an independent prize of $100,000.
See full description for details »

-

End Date

-

To prove that the competition was fair, we will add a command that returns the keys used for encryption as soon as a winner is announced. In case there is no winner by February 4, 2015, decryption commands will be added at that date.

-
-
-
- -

November 4, 2014
The Telegram Team

-
- -
- - -
- - -
-
-
- - - - - - - diff --git a/data/telegram.org/blog/edit.html b/data/telegram.org/blog/edit.html deleted file mode 100644 index f521b32d49..0000000000 --- a/data/telegram.org/blog/edit.html +++ /dev/null @@ -1,245 +0,0 @@ - - - - - Edit Messages, New Mentions and More - - - - - - - - - - - - - - - - - - - -
-
- -
-
-
- -
-
-

Edit Messages, New Mentions and More

- -
- -
- -

Farewell to typos! Starting today, you can edit the text of your messages after sending them. This works across all Telegram chats, including groups and one-on-one conversations.

-
- -

Edit messages

-
- -

Simply tap and hold on a message, then press ‘Edit’. If you're on desktop, press the up arrow button to edit your last message. The messages will display a small ‘edited’ label so that it's easy to tell which were altered.

-

New Mentions

-

Mentioning other people in groups is handy since it sends them a notification about your message even if they muted the group. Starting today, you can mention any members in a group – even if they don't have a username. Just type the @ symbol and select whoever you would like to address. Easy!

-
- -

Mention group members

-
- -

People List

-

Speaking of addressing people, you can now get to your recent chats much faster using the new People list in Search.

-
- -

Recent chats

-
- - -

Bot Attachments

-

We've also made it easier for you to access your favorite inline bots. Simply scroll down the attachment menu – and there they are. The more you use them, the higher they will climb.

-
- -

Bots in attachment menu

-
- -

Naturally, you will only see inline bots in the attachment menu if you used them at least once. Try @youtube, @gif or @imdb if you don't know where to start. Check out this post for more info on how to use inline bots.

-

Interface Improvements

-

We‘ve added quick sharing buttons to forwarded messages from bots, channels, and public groups. Notifications about messages with stickers will now show the relevant emoji so that you’ll know the general idea at first glance.

-
- -

Scroll to bottom

-
- -

Last but not least, if you're on iOS, your app now remembers the scroll position in chats when switching to a different chat and back. And scrolling up in a chat summons a new button that will send you back to the bottom in one tap. This button also displays a handy unread message counter if new ones are waiting for you there.

-

- -

And that's it for today. Stay tuned for more updates coming soon!

-

- -

May 15, 2016
The Telegram Team

-
- -
- - -
- - -
-
-
- - - - - - - diff --git a/data/telegram.org/blog/folders.html b/data/telegram.org/blog/folders.html deleted file mode 100644 index 71673fc44c..0000000000 --- a/data/telegram.org/blog/folders.html +++ /dev/null @@ -1,298 +0,0 @@ - - - - - Chat Folders, Archive, Channel Stats and More - - - - - - - - - - - - - - - - - - - -
-
- -
-
-
- -
-
-

Chat Folders, Archive, Channel Stats and More

- -
- -
- -
- Introducing Chat Folders -
- -

Many of our users rely on Telegram for their work and studies, even more so in the last weeks. To make sure everyone's chat lists can handle the increased load and you don't miss important messages, we're introducing Chat Folders today.

-

If you have too many chats, you can now separate fun from work, or family stuff from school stuff – then swipe between the tabs to quickly access any of your chats.

-
- -
- -

You can include or exclude all chats of a particular type, like Channels, or Unread – or one by one.

-

Folders become available in the interface when your chat list is long enough to start getting cluttered. Alternatively, you may use this link in your app to enable Chat Folders.

-

Unlimited Pins

-

Each of your folders can have as many pinned chats as you like.

-
- Pinned chats in folders -
- -

Archived Chats

-

Chat Folders work best to make some of your chats more visible. If you're looking to hide some of your chats from view, try archiving them instead.

-

Swipe left on a chat to transfer it to your archived chats folder. When an archived chat gets a notification, it will pop out of the folder and back into your chat list. Muted chats will stay archived forever.

-
- -
- -

You can hide the archive by swiping left on it. See it again by dragging the screen down.

-

On Android, if you are already using Folders, swiping will not work for archiving. Instead, you can long press on a chat to open the bulk actions menu where you can select multiple chats and then pin, mute, archive or delete them all at once.

-
- Archive button in the bulk actions menu -
- - -

Desktop Sync

-

Like everything on Telegram (except for Secret Chats), your Chat Folders will seamlessly sync to all your other connected apps, including our Desktop Apps.

-

Thanks to the extra space available on your computer screen, we've added a folder sidebar – as well as some icons to make your folders more recognizable:

-
- -
- -
-

Get the multiplatform Telegram Desktop or our dedicated macOS app. If you're not using those, you're only enjoying half of Telegram.

-
-

Channel Stats

-
-If you have a channel with more than 1000 50 subscribers, you can now view detailed statistics about its growth and the performance of its posts. -
- -
- -
- -

With this information, you can find out what's working and what's working really well. Hint: Cat Pictures.

-

Voice Recording Animations on Android

-

Our designers added some fancy wavy animations below your finger when you're recording a voice or video message.

-
- -
- -

Tip of the day: Did you know you can slide your finger up to lock recording and keep talking without holding the button?

-

New Animated Emoji

-

The latest additions to our army of animated emoji can help you be brave and urge your friends to stay safe and healthy. Send 🦠, 🤒, 😷, 🤕, 🤧, 🤢, 🤮, 🧼, 💉, 💊 or 🚑 to any chat to check them out.

-
- -
- -

Most of our sticker packs now also have something to say about the situation. Type 🦠 in any chat and wait to see the suggestions:

-
- -
- -

And One More Thing

-

Missing your Catan or D&D partners while the world is on lockdown? Send 🎲 to any chat to get a certified random number from the animated dice.

-

Besides trying to test your luck, you can also use it as a tiebreaker if a group poll or friendly debate ends in a split decision. Pick a number – the closest one wins!

-
- -
- -

Stay home, stay safe and stay tuned for our next updates!

-

- -

March 30, 2020,
The Telegram Team

-
- -
- - -
- - -
-
-
- - - - - - - diff --git a/data/telegram.org/blog/profile-videos-people-nearby-and-more.html b/data/telegram.org/blog/profile-videos-people-nearby-and-more.html deleted file mode 100644 index 7c2eca8eef..0000000000 --- a/data/telegram.org/blog/profile-videos-people-nearby-and-more.html +++ /dev/null @@ -1,315 +0,0 @@ - - - - - Profile Videos, 2 GB File Sharing, Group Stats, Improved People Nearby and More - - - - - - - - - - - - - - - - - - - -
-
- -
-
-
- -
-
-

Profile Videos, 2 GB File Sharing, Group Stats, Improved People Nearby and More

- -
-
-
- -
- Introducing Profile Videos, Improved People Nearby, 2 GB File Sharing and More -
- -

Today's update brings Profile Videos along with improved People Nearby features, unlimited file sharing with up to 2 Gigabytes per file, mini-thumbnails for your chat list and notifications, group stats, and much more.

-

Profile Videos

-

You can now upload a video to your profile – and choose any frame you like for your static profile picture in chats. Capture yourself in action, or wink and wave at people like you're in a magical picture from Harry Potter.

-
- -
- -

Same as with any videos you upload, our media editor will help you enhance quality – or decorate yourself with animated stickers.

-

As your mood changes, you can quickly switch back to a previous profile photo or video by tapping ‘Set as Main’. Great for rewinding time and staying young forever.

-

Soften Skin

-

Speaking of the media editor, any photo or video you take with the front-facing camera now has a soften skin option in the media editor. But you don't need it to look fabulous, you already are fabulous.

-
- -
- - - - -

Improved People Nearby

-

Profile videos make meeting new people a dozen times more interesting, and we've beefed up the People Nearby section for the occasion.

-

When people contact you via the People Nearby section, you will see how far away they are. And when you start a chat with someone nearby, Telegram will suggest a greeting sticker to break the ice. Luckily, all our stickers are extroverts.

-
- Improved People Nearby -
- -

Now that people are carefully emerging into this brave new world, it's time to make friends and repopulate the earth compare your sticker collections. Head over to Contacts > Find People Nearby and try tapping on ’Make myself visible’.

-

Mini-thumbnails

-

Ever wondered whether the incoming picture is just another meme or that selfie you've been waiting for? Get an idea of what media is in a message right away thanks to the new chat list thumbnails.

-
- Mini-thumbnails in the chat list -
- -

The new thumbnails also appear in notifications and message search results. Never lose a cat photo again.

-
-

Speaking of previews, you can hold on a profile picture in the chat list to preview messages without opening the chat. This feature is from 2018, but we had a dream in which a talking squid told us to mention it here.

-
-

Filter New Chats from Non-Contacts

-

Thanks to People Nearby and groups with up to 200,000 members, you can always find someone to chat with. Public figures sometimes have the opposite problem and may wish to tone down the attention they receive — we've got this covered too.

-

If you're getting too many messages from non-contacts, try the new switch in Privacy & Security settings to automatically archive and mute new chats from people not in your contacts. You can access these chats anytime from the Archive folder and bring them back to the main chat list in a tap.

-
- -
- - - -

Group Stats

-

Owners of large groups with over 500 members can now view beautiful, detailed graphs about their activity and growth. Group stats also show a list of top members by number of messages and average message length.

-
- -
- -

By the way, the minimum number of subscribers to get Channel Stats has been reduced to 500 as well. 🎉 We're planning to roll out access to group stats for admins of all groups with 100 members or more in the near future.

-

Android Extras

-

On Android, the music player has been redesigned with sleek new icons and an expandable track list. Tap the button on the left to control looping, shuffling and to reverse the track order so your playlist can moonwalk with you.

-

The message input bar will grow smoothly as you type a long message. And the video editor now allows cropping and rotating videos – to help you hide any evidence you were filming vertically.

-
- -
- -

Multiple Accounts on Telegram Desktop

-

Telegram lets you stay signed in on 3 accounts from different phone numbers without logging out. Our mobile users have been enjoying this feature since 2017, and today it's coming to the multi-platform Telegram Desktop.

-
- -
- -

As always, this doesn't require an active connection to your phone – all our apps are completely self-sufficient.

-

More Animated Emoji

-

Our animated emoji army keeps growing (note to self: build a bigger barracks). To get one of these 👇 in a chat, simply send a message with a single emoji – and watch it jump to life.

-
- -
- -

Be careful, one of them bites. And we're not allowed to tell you which one.

-

If you're looking for something more interactive, try sending a single ⚽️ in any chat to see if you score a goal:

-
- -
- -

And One More Thing

-

Since 2014, Telegram users have been sharing files up to 1,5 GB each, which happens to be 93 times larger than 16 MB (which is a totally random number, we have no idea what it could possibly mean).

-

From now on, you can send unlimited numbers of media and files of any kind – up to 2 GB each.

-
-

And that‘s it for today. We're now in the middle of the year — with eight major updates behind us and long-awaited features just around the corner. Stay tuned!

-

- -

July 26, 2020
The Telegram Team

-
- -
- - -
- - -
-
-
- - - - - - - - diff --git a/data/telegram.org/blog/replies-mentions-hashtags.html b/data/telegram.org/blog/replies-mentions-hashtags.html deleted file mode 100644 index 4ceacdecaa..0000000000 --- a/data/telegram.org/blog/replies-mentions-hashtags.html +++ /dev/null @@ -1,238 +0,0 @@ - - - - - Reinventing Group Chats: Replies, Mentions, Hashtags and More - - - - - - - - - - - - - - - - - - - -
-
- -
-
-
- -
-
-

Reinventing Group Chats: Replies, Mentions, Hashtags and More

- -
- -
- -

Group chats have not evolved much since they first appeared in messaging apps many years ago. Today's new features bring group chat communication much closer to what it should look like in 2015. iOS, Android, OSX and Telegram Web get them first.

-

Replies

-

To reply to a specific message in a group chat, simply tap on it (double-tap on iOS) and choose Reply. Easy as that!

-
- - - - - -

- -

The person you replied to will be notified about your message even if s/he muted the group chat — their notification settings for you personally apply in this case.

-

Replies also make group chats much easier to navigate. If you tap on the quote, the app scrolls up to the original message.

-

Mentions

-

If you want several people within a group chat to get instantly involved in the conversation, you may now also mention them in a message, provided they have a username:

-
- - -

-
- -

They will be notified about this message, even if they muted the group chat — unless they've muted you personally, of course!

-

Hashtags

-

Another new way of bringing structure to group chats is by using hashtags. Any word starting with a “#” will be clickable. Tap on a hashtag to get instant search results from your Telegram messages.

-
- - -
-
- -

Forwarding with comments

-

On top of this, you can now add a comment to the stuff you forward. This comment will be shown before the forwarded messages.

-
-

Group chats are becoming larger and livelier — a Telegram group may include up to 200 members that share thousands of messages daily. We hope that these new tools will help you bring order and clarity to the chaos of a thriving group chat.

-

- -

March 19, 2015
The Telegram Team

-
- -
- - -
- - -
-
-
- - - - - - - diff --git a/data/telegram.org/blog/telegram-me-change-number-and-pfs.html b/data/telegram.org/blog/telegram-me-change-number-and-pfs.html deleted file mode 100644 index a8955ba287..0000000000 --- a/data/telegram.org/blog/telegram-me-change-number-and-pfs.html +++ /dev/null @@ -1,228 +0,0 @@ - - - - - Telegram.me, Changing Numbers and PFS - - - - - - - - - - - - - - - - - - - -
-
- -
-
-
- -
-
-

Telegram.me, Changing Numbers and PFS

- -
- -
- -
-

Our iOS and Android apps got updated with three new features today.

-
-

Opening a telegram.me/YourUsernameHere link on your phone will now automatically fire up your Telegram app and open a chat with that user. You can share username links with friends, write them on business cards or put them up on your website.

-
- -
- -
Here's what people will see if they don't have Telegram yet
- -

Changing Your Phone Number

-

It is easy to switch to Telegram and retain your social graph, since it is based on phone numbers. But what if you need to change the phone number itself? As of today, you can change your number in Telegram — and keep everything, including all your contacts, messages and media from the Telegram cloud, as well as all your secret chats.

-
- - - -
-
- -

Your mutual contacts (people in your contacts, who also have your number) will get your new number added to your contact in their address book unless you have blocked them in Telegram. This makes changing numbers even easier.

-

Perfect Forward Secrecy

-

Last but not least, Telegram's Secret Chats now support Perfect Forward Secrecy. What this means is that your Secret Chats will now automatically change encryption keys after a period of time, in order to keep past communications safe. This way you no longer need to manually re-create Secret Chats to achieve this level of security.

-

- -

And that's it for today. Stay tuned for more updates coming your way on all platforms!

-
-

December 1, 2014
The Telegram Team

-
- -
- - -
- - -
-
-
- - - - - - - diff --git a/data/telegram.org/blog/winter-contest-ends.html b/data/telegram.org/blog/winter-contest-ends.html deleted file mode 100644 index b9cbc5c4cd..0000000000 --- a/data/telegram.org/blog/winter-contest-ends.html +++ /dev/null @@ -1,224 +0,0 @@ - - - - - Winter Contest Ends - - - - - - - - - - - - - - - - - - - -
-
- -
-
-
- -
-
-

Winter Contest Ends

- -
- -
- -

The contest to decrypt intercepted traffic of Telegram produced no winners as of March, 1. As promised, today we are publishing the encryption keys necessary to decrypt the traffic.

-
SECRET CHAT:
-2e 20 9f 9d 99 c9 fc 8a 3d dc d5 6d 21 26 46 c9 d8 1a 26 f8 ec f7 f2 7e c9 28 65 95 52 dc 1c 21 bb 95 60 b1 d8 5f 94 5f 43 8d 7e 8e 96 fa e6 89 91 a9 90 39 8b df ef 50 22 06 f8 52 80 e6 50 20 62 71 c4 b2 f5 f8 88 4d 83 ae 66 ec fe cd ec 92 26 69 72 5e 85 f9 ea 58 b0 d6 9f 5b 1e b7 68 15 76 5b 12 88 3d 17 f6 62 49 8b 1f 9d 7a 11 94 67 8d d1 ee d6 55 50 d4 51 c0 5e a5 9a 1a eb 8a 8c 7c 44 1b db 96 5a fd cd 85 47 5b f0 8a 1e b8 d6 74 a4 c7 e7 af 19 3f a6 0a ff e5 3b 9f c4 fc ea 59 af f6 72 60 16 6f 40 af 58 95 98 06 0c 22 00 d7 3d be 96 19 56 54 06 74 d2 6b 38 8d c2 a0 97 62 6d e4 10 99 b9 cf d5 0f 56 9d d3 bb 49 86 d5 15 23 86 03 c3 52 67 82 77 5e 53 e9 ba e8 63 58 ed 55 b0 ef ec 69 65 a0 e5 1d e4 b6 6e 5a 3d 5f 9b 9a 20 67 f5 d5 c4 d7 60 14 c6 56 2d 12 1b 0a
-
-DC 1:
-5e a6 0d a2 9c 90 8e f4 36 d5 48 fe 76 a3 11 f6 66 13 4e 94 bb 11 32 d6 cf fd b0 2f 7b 77 bb 01 d7 42 a4 22 d3 04 e7 d2 fc 5b 32 48 d6 71 eb 18 51 19 99 76 49 46 1a 43 d8 cf cd 8a e2 fe 42 2c 36 d7 05 8b 0c 5e 00 8a 5a bc 35 4f ec 75 b4 10 e1 84 bb cb af ec e3 d6 fd 59 fd 01 83 ef 8b dd 13 50 24 5b 80 09 75 7e c3 c3 08 ba 59 f4 ec c0 87 71 ba 9f 45 8c 15 df 2a cd a5 bc 81 a9 20 fe 42 e2 65 78 02 77 80 11 0e e4 67 f3 40 cf 72 be fc c2 8d 0b ad d9 9e 6e 1a c3 03 71 39 be b9 dd df 7c 63 a6 27 45 ee 8e 00 5e 12 51 51 6c 6a 10 a6 73 3a 10 5d d8 f3 b6 c5 70 fe 91 c2 64 4b d0 74 2d 47 e7 4e 00 cf d5 d3 65 15 2b 48 9c 75 eb a8 96 aa ce 09 49 9b 5e ea 76 06 19 f3 b3 e7 7b af df 5d 68 5e 80 10 48 ec 00 35 90 d3 e5 96 c6 59 a7 44 d8 20 a8 a2 b6 93 64 4f 98 44 23 8e fd
-
-DC 2:
-63 ab 0d b7 98 e1 78 ef 5f 05 9c e4 84 3b 53 b3 4f 6e d1 d3 8a 6d 59 19 32 26 73 60 c2 e2 fe ee d3 2d 74 35 18 08 ba 04 87 cf 7f d9 87 4b 64 d5 80 06 05 f5 01 56 6d c2 66 7e 2d ef f6 a3 82 3d 31 0e ed 6b 46 4c 11 d5 ec 0f 7b be 64 79 26 87 a9 d3 34 27 d8 8b aa b5 36 8b 95 2f a7 c7 2a a6 bf a9 44 51 c5 c8 06 04 78 d2 64 87 e8 13 f3 f0 9b c9 8c bc 29 01 55 a2 80 e1 e8 4e 74 53 7e 05 22 1b 51 3d 1a c5 61 b3 04 98 c2 2f 71 e3 76 2e 31 bd d8 55 15 4b 3e 34 ed 84 b2 56 d0 bd c6 9a 1a 2a 4b 2f fc 68 8e c4 e3 81 23 6f 07 3f 3a 6b 56 f6 ee 31 e6 aa 0d 49 36 6a 51 79 25 bf b6 40 64 8c e2 14 c8 70 37 cb 70 ad a1 83 ed 1f b9 78 b9 93 0c 7c 0c ed 6d c6 aa c2 d0 da 51 ce ae cf 99 8f 65 eb 5a 42 e6 ff 4a 51 a9 97 da 6e ac e5 63 c1 05 a9 fe d0 da da 43 e3 50 14 fc b1 46 ea
-
-DC 3:
-16 0c be 58 e1 74 74 f5 f9 8f f8 82 71 ed 57 84 20 49 bd da 17 0e 00 a8 a4 24 71 79 86 1f ef 3e 41 70 31 de c9 c2 19 23 37 fd ec 2f fa 9e 89 29 4f a2 af 69 cf 24 3a 6e 44 5d 89 d2 8b 50 45 26 3c ff e3 d4 4d 7d b4 88 54 8c 87 09 c5 ac 09 5c e6 62 43 73 b5 3e 96 ea f3 62 76 58 1b fd 8a 36 45 65 4a fc 7b ee 7b 13 06 e5 2f 9d 8f cb b9 a7 6f 76 00 f4 9a ab 50 fb 91 e0 2b ce 28 db 95 02 a0 62 33 bb e7 41 13 7b 2c 7e ba 7c d5 87 12 33 de 44 8d 4b 76 af 59 cc 80 42 02 69 56 90 8a 5d 95 0b 3e 8b ef 65 17 fc 79 62 b4 69 1b 21 aa 89 5b 22 f6 33 67 80 d0 22 f7 76 f2 6c 4b af 69 07 0f 2c 3a af 67 6b 74 c0 7f 8c 83 85 85 8e 47 b7 55 42 c1 3d 70 33 9d 87 60 7c f6 8b 99 96 1d af 82 b8 d2 37 c7 a3 fc ac 25 fe 77 f0 29 4d 82 a4 15 89 cb c2 27 ae 4f 16 d6 b8 4c cb de 2a 59 d7
-
-DC 4:
-b4 aa dc bc 8e e5 6a f4 9f 7b 65 de cd 1c 28 3d f1 58 f6 03 e1 34 9d 63 54 b0 15 a7 b8 a6 45 4e de dd cd e4 1a 54 d7 9b fe 46 05 c7 62 19 d9 7a c0 00 6b e6 72 83 3d 15 00 99 d9 9b 97 c0 4a a8 85 e7 85 3c 3f a4 2f 6a 57 0b 3c b0 2a 97 65 6f bf 4e 0d 93 f7 55 3b 3a 39 a1 1a 0f db 9d 7a df 5b c6 9b 45 9a ea e4 27 92 8c c3 d2 75 53 66 e4 1c 29 f1 14 fc fd e8 c0 c8 12 47 ee 5a 92 f1 bf 1f 6f 8e 95 a5 90 81 37 d6 5d bd 5c 4c 41 61 29 6e 4f 7e 83 e1 b9 ef 00 00 de 25 33 f4 df 1a 94 f0 e7 1c fd 35 c0 75 65 88 ef c5 aa b5 c9 7d 0e e4 6d b7 9f 10 ca 4b f0 c9 c7 2d 30 20 e9 e1 b8 03 de a2 60 4e 3f 59 dc 36 a2 50 f8 52 5e 32 c8 c1 84 87 84 d6 54 42 dd ab b4 1b d6 fe e4 29 d3 70 4e 3e 48 ba 86 80 39 b7 94 3c 31 18 f8 bd 7b d8 89 6b 32 77 5c 89 4a a1 ca 18 ba 1e 6a 87 6a
-
-DC 5:
-4c 76 1f 87 08 53 54 cb 12 fd 01 bd bd e6 42 d2 6b 47 4b d8 0b 6a eb 9f 24 8b ee 77 1f 8b a5 3f f5 f1 c7 80 05 80 2c 20 29 7c 3c 14 59 2b 5e 7f 69 58 3b 7e 07 37 25 67 3d 18 ac f2 28 43 63 8f a5 41 c1 ba 53 dd eb 3d 36 0d 7b d3 14 f7 f9 83 aa 0c 81 20 89 e0 c7 d7 e9 ef 11 aa 43 ca 54 2a 9f 69 0f 1d 99 ef f6 55 14 71 6d a3 1e c2 75 fb 1c 88 f7 c0 21 64 5d 34 db 3f a4 e7 a9 f0 af 9f 9d 14 a4 3a 49 7c 50 e6 45 24 3a cb a4 a6 2a 35 dd 6c 9c ce 87 24 d1 ff 13 19 15 43 89 a4 8c 39 66 a2 22 df 4e 94 76 e1 89 b5 03 7a 2b 34 e7 39 09 f9 22 5d cb 36 4e ce 37 e7 cf 7d ab b5 8b db 81 c6 c8 f4 c7 7c 3a 22 59 fc e6 32 19 aa 46 d2 95 96 61 61 e6 cc 57 f0 0e 87 5c 7d 5b 87 e7 64 28 c6 03 38 3c 0b a6 5e 4a 21 a3 67 af e5 b3 88 cc 9d 03 98 33 ac c6 87 b4 b6 82 42 c4 41 33 39
-


- -

We would like to use this opportunity to thank the users ABC, @DefuseSec, @hackappcom, @Morj and x7mz who helped us further improve security of the client apps and expand guidelines for third-party developers.

-

Since we have no winner in the current challenge, we are going to launch a new competition, with an easier task, but a larger prize. The new competition will allow participants not only to intercept traffic, but to manipulate it as well. We are now building the tools that will enable the contestants to perform all kinds of active attacks. Once the platform is ready later this month, we will announce the new contest on Twitter. Please follow us at @telegram!

-

March 2, 2014
The Telegram Team

-
- -
- - -
- - -
-
-
- - - - - - -