diff --git a/data/corefork.telegram.org/api/datacenter.html b/data/corefork.telegram.org/api/datacenter.html deleted file mode 100644 index 8e9f2cee13..0000000000 --- a/data/corefork.telegram.org/api/datacenter.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - - Working with Different Data Centers - - - - - - - - - - - - - -
-
-
-
- - -
-
-
-
-
-
-
-

Working with Different Data Centers

- -

The servers are divided into several data centers (hereinafter “DCs”) in different parts of the world. -A complete list of proxy access points for these DCs may be obtained using help.getConfig:

-
dcOption#18b7a10d flags:# ipv6:flags.0?true media_only:flags.1?true tcpo_only:flags.2?true cdn:flags.3?true static:flags.4?true id:int ip_address:string port:int secret:flags.10?bytes = DcOption;
-config#330b4067 flags:# phonecalls_enabled:flags.1?true default_p2p_contacts:flags.3?true preload_featured_stickers:flags.4?true ignore_phone_entities:flags.5?true revoke_pm_inbox:flags.6?true blocked_mode:flags.8?true pfs_enabled:flags.13?true date:int expires:int test_mode:Bool this_dc:int dc_options:Vector<DcOption> dc_txt_domain_name:string chat_size_max:int megagroup_size_max:int forwarded_count_max:int online_update_period_ms:int offline_blur_timeout_ms:int offline_idle_timeout_ms:int online_cloud_timeout_ms:int notify_cloud_delay_ms:int notify_default_delay_ms:int push_chat_period_ms:int push_chat_limit:int saved_gifs_limit:int edit_time_limit:int revoke_time_limit:int revoke_pm_time_limit:int rating_e_decay:int stickers_recent_limit:int stickers_faved_limit:int channels_read_media_period:int tmp_sessions:flags.0?int pinned_dialogs_count_max:int pinned_infolder_count_max:int call_receive_timeout_ms:int call_ring_timeout_ms:int call_connect_timeout_ms:int call_packet_timeout_ms:int me_url_prefix:string autoupdate_url_prefix:flags.7?string gif_search_username:flags.9?string venue_search_username:flags.10?string img_search_username:flags.11?string static_maps_provider:flags.12?string caption_length_max:int message_length_max:int webfile_dc_id:int suggested_lang_code:flags.2?string lang_pack_version:flags.2?int base_lang_pack_version:flags.2?int = Config;
----functions---
-help.getConfig#c4f9186b = Config;
-

In this context, this_dc is the number of the current DC, dc_options is a list of all DCs available at the moment, each of which has an id, ip, and port for establishing a connection. Please note that ip and port may change frequently, based on proxy server load and the user's current location.
-Typically, each DC has at least one IPv4 and one IPv6 endpoint available.

-

To optimize client communication with the API, each client must use the connection to the closest access point for its main queries (sending messages, getting contacts, etc.). Therefore, knowing how to select a DC is required before communicating with the API.

-

Registration/Authorization

-

The auth.sendCode method is the basic entry point when registering a new user or authorizing an existing user. 95% of all redirection cases to a different DC will occur when invoking this method.

-

The client does not yet know which DC it will be associated with; therefore, it establishes an encrypted connection to a random address and sends its query to that address. -Having received a phone_number from a client, we can find out whether or not it is registered in the system. If it is, then, if necessary, instead of sending a text message, we request that it establish a connection with a different DC first (PHONE_MIGRATE_X error). -If we do not yet have a user with this number, we examine its IP-address. We can use it to identify the closest DC. Again, if necessary, we redirect the user to a different DC (NETWORK_MIGRATE_X error).

-

Testing Redirects

-

There are reserved phone number prefixes to test the correctness of the application's handling of redirects between DCs. Read more in User Authorization article.

-

File Access

-

A file saved by a user with upload.saveFilePart will be available for direct download only from the DC where the query was executed. That is why each file has a dc_id parameter:

-
document#1e87342b flags:# id:long access_hash:long file_reference:bytes date:int mime_type:string size:int thumbs:flags.0?Vector<PhotoSize> video_thumbs:flags.1?Vector<VideoSize> dc_id:int attributes:Vector<DocumentAttribute> = Document;
-photo#fb197a65 flags:# has_stickers:flags.0?true id:long access_hash:long file_reference:bytes date:int sizes:Vector<PhotoSize> video_sizes:flags.1?Vector<VideoSize> dc_id:int = Photo;
-
-encryptedFile#4a70994c id:long access_hash:long size:int dc_id:int key_fingerprint:int = EncryptedFile;
-
-userProfilePhoto#82d1f706 flags:# has_video:flags.0?true photo_id:long stripped_thumb:flags.1?bytes dc_id:int = UserProfilePhoto;
-chatPhoto#1c6e1c11 flags:# has_video:flags.0?true photo_id:long stripped_thumb:flags.1?bytes dc_id:int = ChatPhoto;
-

To download the file, an encrypted connection to DC dc_id must be established and used to execute the upload.getFile query. -If an attempt is made to download the file over a wrong connection, the FILE_MIGRATE_X error will be returned.

-

Please note that encryption keys are not copied between DCs; therefore, the process of establishing an encrypted connection is started from the very beginning for each new DC. An issued auth_key can be associated with the current authorized user by using an authorization transfer.

-

User Migration

-

During the process of working with the API, user information is accumulated in the DC with which the user is associated. This is the reason a user cannot be associated with a different DC by means of the client. However, in the future, during prolonged communication from an unusual location, we may decide that the user's data must be moved to a different DC. After some time, the data will be copied and the association will be updated. Once this happens, when executing any query transmitted to the old DC, the API will return the USER_MIGRATE_X error. The client will then have to establish a connection with the new DC and repeat the query.

-

Authorization Transfer

-

The following methods can be used to eliminate the need for users to enter the code from a text message every time:

-
auth.exportedAuthorization#b434e2b8 id:long bytes:bytes = auth.ExportedAuthorization;
-auth.authorization#33fb7bb8 flags:# setup_password_required:flags.1?true otherwise_relogin_days:flags.1?int tmp_sessions:flags.0?int user:User = auth.Authorization;
----functions---
-auth.importAuthorization#a57a7dad id:long bytes:bytes = auth.Authorization;
-auth.exportAuthorization#e5bfffcd dc_id:int = auth.ExportedAuthorization;
-

auth.exportAuthorization must be executed in the current DC (the DC with which a connection has already been established), passing in dc_id as the value for the new DC. The method should return the user identifier and a long string of random data. An import operation can be performed at the new DC by sending it what was received. Queries requiring authorization can then be successfully executed in the new DC.

- -
- -
-
-
-
-
-
Telegram
-
- Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed. -
- -
-
About
- -
-
-
Mobile Apps
- -
-
-
Desktop Apps
- -
-
-
Platform
- -
-
-
-
-
About
-
-
-
Blog
-
-
-
Apps
-
-
-
Platform
-
-
-
Twitter
-
-
-
-
- - - - - - diff --git a/data/corefork.telegram.org/api/payments.html b/data/corefork.telegram.org/api/payments.html deleted file mode 100644 index 4431fb1e1b..0000000000 --- a/data/corefork.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#e25ff8e0 flags:# silent:flags.5?true background:flags.6?true clear_draft:flags.7?true noforwards:flags.14?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 send_as:flags.13?InputPeer = 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#38116ee0 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 noforwards:flags.26?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 reactions:flags.20?MessageReactions 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 submitted 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#38116ee0 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 noforwards:flags.26?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 reactions:flags.20?MessageReactions 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;
- -
- -
-
-
-
-
-
Telegram
-
- Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed. -
- -
-
About
- -
-
-
Mobile Apps
- -
-
-
Desktop Apps
- -
-
-
Platform
- -
-
-
-
-
About
-
-
-
Blog
-
-
-
Apps
-
-
-
Platform
-
-
-
Twitter
-
-
-
-
- - - - - - - - diff --git a/data/corefork.telegram.org/constructor/payments.ValidatedRequestedInfo b/data/corefork.telegram.org/constructor/payments.ValidatedRequestedInfo deleted file mode 100644 index 3f2ec3632c..0000000000 --- a/data/corefork.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

- -
- -
-
-
-
-
-
Telegram
-
- Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed. -
- -
-
About
- -
-
-
Mobile Apps
- -
-
-
Desktop Apps
- -
-
-
Platform
- -
-
-
-
-
About
-
-
-
Blog
-
-
-
Apps
-
-
-
Platform
-
-
-
Twitter
-
-
-
-
- - - - - - diff --git a/data/corefork.telegram.org/js/main.js b/data/corefork.telegram.org/js/main.js deleted file mode 100644 index 5b19de1b7a..0000000000 --- a/data/corefork.telegram.org/js/main.js +++ /dev/null @@ -1,685 +0,0 @@ -var startTime = +(new Date()); -function dT() { - return '[' + ((+(new Date()) - startTime)/ 1000.0) + '] '; -} - -var jsonpCallbacks = []; -function twitterCustomShareInit () { - var btns = document.querySelectorAll - ? document.querySelectorAll('.tl_twitter_share_btn') - : [document.getElementById('tl_twitter_share_btn')]; - - if (!btns.length) { - return; - } - var head = document.getElementsByTagName('head')[0], i, script; - for (i = 0; i < btns.length; i++) { - (function (btn) { - var status = btn.getAttribute('data-text'), - url = btn.getAttribute('data-url') || location.toString() || 'https://telegram.org/', - via = btn.getAttribute('data-via'), - urlEncoded = encodeURIComponent(url), - popupUrl = 'https://twitter.com/intent/tweet?text=' + encodeURIComponent(status) + '&url=' + urlEncoded + '&via=' + encodeURIComponent(via); - - btn.setAttribute('href', popupUrl); - btn.href = popupUrl; - - btn.addEventListener('click', function (e) { - var popupW = 550, - popupH = 450, - params = [ - 'width=' + popupW, - 'height=' + popupH, - 'left=' + Math.round(screen.width / 2 - popupW / 2), - 'top=' + Math.round(screen.height / 2 - popupH / 2), - 'personalbar=0', - 'toolbar=0', - 'scrollbars=1', - 'resizable=1' - ].join(','), - popup = window.open(popupUrl, '_blank', params); - - if (popup) { - try { - popup.focus(); - } catch (e) {} - } - - return cancelEvent(e); - }, false); - })(btns[i]); - } -} - -function blogRecentNewsInit () { - if (document.querySelectorAll) { - var sideImages = document.querySelectorAll('.blog_side_image_wrap'); - var sideImage, parent, i; - var len = len = sideImages.length; - for (i = 0; i < len; i++) { - sideImage = sideImages[i]; - parent = sideImage.parentNode.parentNode; - if (parent) { - parent.insertBefore(sideImage, parent.firstChild); - } - } - } - - var moreBtn = document.getElementById('tlb_blog_head_more_link'); - if (!moreBtn) { - return false; - } - - var activeClassName = 'tlb_blog_head_recent_active'; - moreBtn.addEventListener('click', function (event) { - var parent = this.parentNode; - var className = parent.className; - if (className.indexOf(activeClassName) == -1) { - className += ' ' + activeClassName; - } else { - className = className.replace(' ' + activeClassName, ''); - } - parent.className = className; - - return cancelEvent(event); - }); -} - -function blogSideImageUpdate(argument) { - var isDesktop = document.documentElement.offsetWidth >= 1000 - document.querySelectorAll('.blog_side_image_wrap').forEach(function (imageWrap) { - if (isDesktop) { - var titleHeight = imageWrap.parentNode.previousElementSibling.clientHeight; - var beforeTitleEl = imageWrap.parentNode.previousElementSibling.previousElementSibling; - if (beforeTitleEl) { - titleHeight += beforeTitleEl.clientHeight; - } - imageWrap.firstElementChild.style.marginTop = (-titleHeight - 8) + 'px'; - } else { - imageWrap.firstElementChild.style.marginTop = ''; - } - }) -} - -function blogSideImageInit() { - window.addEventListener('resize', blogSideImageUpdate, false); - setTimeout(blogSideImageUpdate, 0); -} - -function cancelEvent (event) { - event = event || window.event; - if (event) event = event.originalEvent || event; - - if (event.stopPropagation) event.stopPropagation(); - if (event.preventDefault) event.preventDefault(); - - return false; -} - -function trackDlClick (element, event) { - var href = element.getAttribute('href'), - track = element.getAttribute('data-track') || false; - - if (!track || !window.ga) { - return; - } - - var trackData = track.toString().split('/'); - - ga('send', 'event', trackData[0], trackData[1], href); - - if ((element.getAttribute('target') || '').toLowerCase() != '_blank') { - setTimeout(function() { location.href = href; }, 200); - return false; - } -} - -var toTopWrapEl, - toTopEl, - pageContentWrapEl, - curVisible, - curShown = false; -function backToTopInit (labelHtml) { - pageContentWrapEl = document.getElementById('dev_page_content_wrap'); - if (!pageContentWrapEl) { - return false; - } - var t = document.createElement('div'); - - t.innerHTML = '
' + labelHtml + '
'; - toTopEl = t.firstChild; - t.innerHTML = ''; - toTopWrapEl = t.firstChild; - - toTopWrapEl.appendChild(toTopEl); - document.body.appendChild(toTopWrapEl); - - if (window.addEventListener) { - window.addEventListener('resize', backToTopResize, false); - window.addEventListener('scroll', backToTopScroll, false); - } - backToTopResize(); -} - -function backToTopGo () { - window.scroll(0, 0); - backToTopScroll(); -} - -function backToTopResize () { - var left = getXY(pageContentWrapEl)[0], - dwidth = Math.max(window.innerWidth, document.documentElement.clientWidth, 0), - dheight = Math.max(window.innerHeight, document.documentElement.clientHeight); - - curVisible = pageContentWrapEl && left > 130 && dwidth > 640; - toTopWrapEl.style.width = left + 'px'; - toTopEl.style.height = dheight + 'px'; - backToTopScroll(); -} - -function backToTopScroll () { - var st = window.pageYOffset || document.body.scrollTop || document.documentElement.scrollTop || document.documentElement.scrollTop; - if ((st > 400 && curVisible) != curShown) { - curShown = !curShown; - if (curShown) { - toTopWrapEl.classList.add('back_to_top_shown'); - } else { - toTopWrapEl.classList.remove('back_to_top_shown'); - } - } -} - -function removePreloadInit() { - if (window.addEventListener) { - window.addEventListener('load', function () { - document.body.classList.remove('preload'); - }, false); - } else { - setTimeout(function () { - document.body.classList.remove('preload'); - }, 1000) - } -} - -function getXY (obj) { - if (!obj) return [0, 0]; - - var left = 0, top = 0; - if (obj.offsetParent) { - do { - left += obj.offsetLeft; - top += obj.offsetTop; - } while (obj = obj.offsetParent); - } - return [left, top]; -} - - -var onDdBodyClick, - currentDd; -function dropdownClick (element, event) { - var parent = element.parentNode; - var isOpen = (parent.className || '').indexOf('open') > 0; - if (currentDd && currentDd != parent) { - dropdownHide(currentDd); - } - if (!isOpen) { - parent.className = (parent.className || '') + ' open'; - if (!onDdBodyClick) { - window.addEventListener('click', dropdownPageClick, false); - } - currentDd = parent; - } else { - dropdownHide(currentDd); - currentDd = false; - } - event.cancelBubble = true; - return false; -} - -function dropdownHide (parent) { - parent.className = parent.className.replace(' open', ''); -} - -function dropdownPageClick (event) { - if (currentDd) { - dropdownHide(currentDd); - currentDd = false; - } -} - -function escapeHTML (html) { - html = html || ''; - return html.replace(/&/g, '&') - .replace(/>/g, '>') - .replace(/'); - var lastLi = false; - var items = 0; - $('a.anchor').each(function (k, anchor) { - var parentTag = anchor.parentNode.tagName; - var matches = parentTag.match(/^h([34])$/i); - var anchorName = anchor.name; - if (!matches || !anchorName) { - return; - } - anchor.id = anchor.name; - var level = parseInt(matches[1]); - var li = $('
  • ' + escapeHTML(anchor.nextSibling.textContent) + '
    • '); - if (level == 3) { - li.appendTo(menu); - lastLi = li; - } else { - // console.log(lastLi); - if (!lastLi) { - return; - } - var subMenu = $('ul', lastLi)[0] || $('').appendTo(lastLi); - // console.log(subMenu); - li.appendTo(subMenu); - } - items++; - }); - // console.log(items, menu); - // console.timeEnd('page nav'); - if (items < 2) { - return false; - } - - return menu; -} - -function showTitleIfOverflows(element) { - if (element && - element.innerText && - element.scrollWidth && - element.offsetWidth && - element.offsetWidth < element.scrollWidth) { - element.setAttribute('title', element.innerText); - } - else if (element.removeAttribute) { - element.removeAttribute('title'); - } -} - -function initDevPageNav() { - window.hasDevPageNav = true; - var menu = getDevPageNav(); - if (!menu) { - return; - } - var sideNavCont = $('#dev_side_nav_cont'); - if (!sideNavCont.length) { - sideNavCont = $('#dev_page_content_wrap'); - } - var sideNavWrap = $('
    ').prependTo(sideNavCont); - var sideNav = $('
    ').appendTo(sideNavWrap); - menu.appendTo(sideNav); - $('body').css({position: 'relative'}).scrollspy({ target: '.dev_side_nav' }); - - $('body').on('activate.bs.scrollspy', function () { - $('.dev_side_nav > ul').affix('checkPosition'); - var active_el = $('.dev_side_nav li.active').get(-1); - if (active_el) { - if (active_el.scrollIntoViewIfNeeded) { - active_el.scrollIntoViewIfNeeded(); - } else if (active_el.scrollIntoView) { - active_el.scrollIntoView(false); - } - } - }); - $('body').trigger('activate.bs.scrollspy'); - - updateMenuAffix(menu); -} - -function updateDevPageNav() { - if (!window.hasDevPageNav) { - return; - } - var menu = getDevPageNav() || $(''); - $('.dev_side_nav > ul').replaceWith(menu); - $('body').scrollspy('refresh'); - updateMenuAffix(menu); -} - -function updateMenuAffix(menu) { - menu.affix({ - offset: { - top: function () { - return $('.dev_side_nav_wrap').offset().top; - }, - bottom: function () { - return (this.bottom = $('.footer_wrap').outerHeight(true) + 20) - } - } - }) -} - - -function initScrollVideos(desktop) { - var videos = document.querySelectorAll - ? document.querySelectorAll('video.tl_blog_vid_autoplay') - : []; - - window.pageVideos = Array.prototype.slice.apply(videos); - if (!pageVideos.length) { - return; - } - window.pageVideosPlaying = {}; - - var index = 1; - var tgStickersCnt = document.querySelectorAll('.js-tgsticker_image').length; - var preloadVideos = tgStickersCnt ? 0 : 2; - for (var i = 0; i < pageVideos.length; i++) { - var videoEl = pageVideos[i]; - videoEl.setAttribute('vindex', index++); - var preloadValue = i >= preloadVideos ? 'metadata' : 'auto'; - videoEl.setAttribute('preload', preloadValue); - videoEl.preload = preloadValue; - if (desktop) { - videoEl.removeAttribute('controls'); - videoEl.autoplay = false; - videoEl.removeAttribute('autoplay'); - } else { - videoEl.autoplay = true; - videoEl.playsinline = true; - videoEl.setAttribute('autoplay', 'autoplay'); - videoEl.setAttribute('playsinline', 'playsinline'); - } - } - if (!desktop) { - return; - } - - window.addEventListener('scroll', checkScrollVideos, false); - window.addEventListener('resize', checkScrollVideos, false); - setTimeout(checkScrollVideos, 1000); -} - -function checkScrollVideos() { - var w = window, - d = document, - e = d.documentElement, - g = d.getElementsByTagName('body')[0], - winWidth = w.innerWidth || e.clientWidth || g.clientWidth, - winHeight = w.innerHeight|| e.clientHeight|| g.clientHeight, - scrollTop = e.scrollTop || g.scrollTop || w.pageYOffset; - - for (var i = 0; i < pageVideos.length; i++) { - var videoEl = pageVideos[i]; - var curIndex = videoEl.getAttribute('vindex'); - var posY = getFullOffsetY(videoEl); - var height = videoEl.offsetHeight; - // console.log(scrollTop, winHeight, posY, height); - - - if (isVisibleEnough(posY, height, scrollTop, winHeight, 0.7, 0.9)) { - if (!pageVideosPlaying[curIndex]) { - pageVideosPlaying[curIndex] = true; - console.log('play', videoEl); - videoEl.play(); - } - } else { - if (pageVideosPlaying[curIndex]) { - delete pageVideosPlaying[curIndex]; - console.log('pause', videoEl); - videoEl.pause(); - } - } - } -} - -function isVisibleEnough(boxOffset, boxSize, viewOffset, viewSize, boxThreshold, viewThreshold) { - var boxEnd = boxOffset + boxSize; - var viewEnd = viewOffset + viewSize; - var viewBox = Math.min(viewEnd, boxEnd) - Math.max(boxOffset, viewOffset); - if (viewBox < 0) { - return false; - } - if (viewBox / boxSize > boxThreshold) { - return true; - } - if (viewThreshold && viewBox / viewSize > viewThreshold) { - return true; - } - return false -} - -function getFullOffsetY(el) { - var offsetTop = el.offsetTop || 0; - if (el.offsetParent) { - offsetTop += getFullOffsetY(el.offsetParent); - } - return offsetTop; -} - -function redraw(el) { - el.offsetTop + 1; -} - -function initRipple() { - if (!document.querySelectorAll) return; - var rippleTextFields = document.querySelectorAll('.textfield-item input.form-control'); - for (var i = 0; i < rippleTextFields.length; i++) { - (function(rippleTextField) { - function onTextRippleStart(e) { - if (document.activeElement === rippleTextField) return; - var rect = rippleTextField.getBoundingClientRect(); - if (e.type == 'touchstart') { - var clientX = e.targetTouches[0].clientX; - } else { - var clientX = e.clientX; - } - var ripple = rippleTextField.parentNode.querySelector('.textfield-item-underline'); - var rippleX = (clientX - rect.left) / rippleTextField.offsetWidth * 100; - ripple.style.transition = 'none'; - redraw(ripple); - ripple.style.left = rippleX + '%'; - ripple.style.right = (100 - rippleX) + '%'; - redraw(ripple); - ripple.style.left = ''; - ripple.style.right = ''; - ripple.style.transition = ''; - } - rippleTextField.removeEventListener('mousedown', onTextRippleStart); - rippleTextField.removeEventListener('touchstart', onTextRippleStart); - rippleTextField.addEventListener('mousedown', onTextRippleStart); - rippleTextField.addEventListener('touchstart', onTextRippleStart); - })(rippleTextFields[i]); - } - var rippleHandlers = document.querySelectorAll('.ripple-handler'); - for (var i = 0; i < rippleHandlers.length; i++) { - (function(rippleHandler) { - function onRippleStart(e) { - var rippleMask = rippleHandler.querySelector('.ripple-mask'); - if (!rippleMask) return; - var rect = rippleMask.getBoundingClientRect(); - if (e.type == 'touchstart') { - var clientX = e.targetTouches[0].clientX; - var clientY = e.targetTouches[0].clientY; - } else { - var clientX = e.clientX; - var clientY = e.clientY; - } - var rippleX = (clientX - rect.left) - rippleMask.offsetWidth / 2; - var rippleY = (clientY - rect.top) - rippleMask.offsetHeight / 2; - var ripple = rippleHandler.querySelector('.ripple'); - ripple.style.transition = 'none'; - redraw(ripple); - ripple.style.transform = 'translate3d(' + rippleX + 'px, ' + rippleY + 'px, 0) scale3d(0.2, 0.2, 1)'; - ripple.style.opacity = 1; - redraw(ripple); - ripple.style.transform = 'translate3d(' + rippleX + 'px, ' + rippleY + 'px, 0) scale3d(1, 1, 1)'; - ripple.style.transition = ''; - - function onRippleEnd(e) { - ripple.style.transitionDuration = '.2s'; - ripple.style.opacity = 0; - document.removeEventListener('mouseup', onRippleEnd); - document.removeEventListener('touchend', onRippleEnd); - document.removeEventListener('touchcancel', onRippleEnd); - } - document.addEventListener('mouseup', onRippleEnd); - document.addEventListener('touchend', onRippleEnd); - document.addEventListener('touchcancel', onRippleEnd); - } - rippleHandler.removeEventListener('mousedown', onRippleStart); - rippleHandler.removeEventListener('touchstart', onRippleStart); - rippleHandler.addEventListener('mousedown', onRippleStart); - rippleHandler.addEventListener('touchstart', onRippleStart); - })(rippleHandlers[i]); - } -} - -function mainInitRetinaVideos() { - var videoEls = document.querySelectorAll('video.video__init_retina'); - var isRetina = window.devicePixelRatio >= 1.5; - var videoEl, i, badChildren, j, badChild, sources, sourceEl; - for (i = 0; i < videoEls.length; i++) { - videoEl = videoEls[i]; - sources = (videoEl.getAttribute('data-sources')||'').split(','); - sourceEl = document.createElement('source'); - sourceEl.type = 'video/mp4'; - sourceEl.src = sources[isRetina ? 1 : 0]; - videoEl.appendChild(sourceEl); - videoEl.classList.remove('video__init_retina'); - videoEl.setAttribute('preload', 'auto'); - } -} - -function mainInitDemoAutoplay(videoLinkElsSelector) { - var videoLinkEls = document.querySelectorAll(videoLinkElsSelector); - var videoLinkEl, videoEl, i; - for (i = 0; i < videoLinkEls.length; i++) { - videoLinkEl = videoLinkEls[i]; - videoEl = videoLinkEl.querySelector('video'); - if (!videoEl) { - continue; - } - if (videoEl.readyState > 1) { - mainDemoVideoHover(videoLinkEl, 1); - } else { - videoEl.load(); - videoEl.addEventListener('loadeddata', (function(el) { - return function () { - setTimeout(function () { - mainDemoVideoHover(el, 1); - }, 0) - } - })(videoLinkEl), false); - } - } -} - -function mainDemoVideoHover(videoLinkEl, isHover) { - var outTimeout = videoLinkEl.outTimeout; - var curIsHover = videoLinkEl.isHover || 0; - if (outTimeout) { - clearTimeout(outTimeout); - } - if (curIsHover == isHover) { - return false; - } - if (!isHover) { - outTimeout = setTimeout(function () { - mainDemoVideoDoHover(videoLinkEl, isHover) - }, 100); - videoLinkEl.outTimeout = outTimeout; - return false; - } - mainDemoVideoDoHover(videoLinkEl, isHover); -} - -function mainDemoVideoDoHover(videoLinkEl, isHover) { - delete videoLinkEl.outTimeout; - - var videoEl = videoLinkEl.querySelector('video'); - if (isHover) { - if (videoEl.readyState > 1) { - videoLinkEl.classList.add('video_play'); - videoEl.play(); - videoLinkEl.isHover = 1; - } - } else { - videoLinkEl.isHover = 0; - } - if (!videoEl.inited) { - videoEl.inited = true; - // videoEl.onended = - videoEl.addEventListener('ended', function onVideoEnded(e) { - if (videoLinkEl.isHover) { - videoEl.currentTime = 0; - videoEl.play(); - } else { - videoEl.pause(); - videoEl.currentTime = 0; - videoLinkEl.classList.remove('video_play') - } - }, false); - } -} - -function mainInitTgStickers(options) { - options = options || {}; - if (!RLottie.isSupported) { - if (options.unsupportedURL) { - if (!getCookie('stel_notgs')) { - setCookie('stel_notgs', 1, 7); - } - location = options.unsupportedURL; - } - return false; - } - document.querySelectorAll('.js-tgsticker_image').forEach(function (imgEl) { - RLottie.init(imgEl, options); - }); -} - -function setCookie(name, value, days) { - var expires = ''; - if (days) { - var date = new Date(); - date.setTime(date.getTime() + (days * 86400000)); - expires = "; expires=" + date.toUTCString(); - } - document.cookie = name + "=" + (value || "") + expires + "; path=/"; -} - -function getCookie(name) { - var nameEQ = name + '='; - var ca = document.cookie.split(';'); - for (var i = 0; i < ca.length; i++) { - var c = ca[i]; - while (c.charAt(0) == ' ') { - c = c.substr(1, c.length); - } - if (c.indexOf(nameEQ) == 0) { - return c.substr(nameEQ.length, c.length); - } - } - return null; -} - -function mainScrollTo(element) { - if (typeof element === 'string') { - element = document.querySelector(element) - } - if (element) { - window.scroll(0, getFullOffsetY(element)); - } -} diff --git a/data/corefork.telegram.org/mtproto.html b/data/corefork.telegram.org/mtproto.html deleted file mode 100644 index 63ee767b8e..0000000000 --- a/data/corefork.telegram.org/mtproto.html +++ /dev/null @@ -1,260 +0,0 @@ - - - - - MTProto Mobile Protocol - - - - - - - - - - - - - -
    -
    -
    -
    - - -
    -
    -
    -
    -
    -
    -
    -

    MTProto Mobile Protocol

    - -
    - -
    -

    Please feel free to check out our FAQ for the Technically Inclined. -Client developers are required to comply with the Security Guidelines.

    -
    -

    Related articles

    -

    - -

    -
    -

    This page deals with the basic layer of MTProto encryption used for Cloud chats (server-client encryption). See also:

    - -

    General Description

    -

    The protocol is designed for access to a server API from applications running on mobile devices. It must be emphasized that a web browser is not such an application.

    -

    The protocol is subdivided into three virtually independent components:

    -
      -
    • High-level component (API query language): defines the method whereby API queries and responses are converted to binary messages.
      • -
    • Cryptographic (authorization) layer: defines the method by which messages are encrypted prior to being transmitted through the transport protocol.
      • -
    • Transport component: defines the method for the client and the server to transmit messages over some other existing network protocol (such as HTTP, HTTPS, WS (plain websockets), WSS (websockets over HTTPS), TCP, UDP).
      • -
    - -
    -

    As of version 4.6, major Telegram clients are using MTProto 2.0, described in this article. -MTProto v1.0 (described here for reference) is deprecated and is currently being phased out.

    -
    -

    Brief Component Summary

    -

    High-Level Component (RPC Query Language/API)

    -

    From the standpoint of the high-level component, the client and the server exchange messages inside a session. The session is attached to the client device (the application, to be more exact) rather than a specific websocket/http/https/tcp connection. In addition, each session is attached to a user key ID by which authorization is actually accomplished.

    -

    Several connections to a server may be open; messages may be sent in either direction through any of the connections (a response to a query is not necessarily returned through the same connection that carried the original query, although most often, that is the case; however, in no case can a message be returned through a connection belonging to a different session). When the UDP protocol is used, a response might be returned by a different IP address than the one to which the query had been sent.

    -

    There are several types of messages:

    -
      -
    • RPC calls (client to server): calls to API methods
      • -
    • RPC responses (server to client): results of RPC calls
      • -
    • Message received acknowledgment (or rather, notification of status of a set of messages)
      • -
    • Message status query
      • -
    • Multipart message or container (a container that holds several messages; needed to send several RPC calls at once over an HTTP connection, for example; also, a container may support gzip).
      • -
    -

    From the standpoint of lower level protocols, a message is a binary data stream aligned along a 4 or 16-byte boundary. The first several fields in the message are fixed and are used by the cryptographic/authorization system.

    -

    Each message, either individual or inside a container, consists of a message identifier (64 bits, see below), a message sequence number within a session (32 bits), the length (of the message body in bytes; 32 bits), and a body (any size which is a multiple of 4 bytes). In addition, when a container or a single message is sent, an internal header is added at the top (see below), then the entire message is encrypted, and an external header is placed at the top of the message (a 64-bit key identifier and a 128-bit message key).

    -

    A message body normally consists of a 32-bit message type followed by type-dependent parameters. In particular, each RPC function has a corresponding message type. For more detail, see Binary Data Serialization, Mobile Protocol: Service Messages.

    -

    All numbers are written as little endian. However, very large numbers (2048-bit) used in RSA and DH are written in the big endian format because that is how the OpenSSL library does it.

    -

    Authorization and Encryption

    -

    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 defines an actual 256-bit key which is what encrypts the message using AES-256 encryption. 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 middle bits of the SHA256 of the message body (including session, message ID, etc.), including the padding bytes, prepended by 32 bytes taken from the authorization key. Multipart messages are encrypted as a single message.

    -
    -

    For a technical specification, see Mobile Protocol: Detailed Description

    -
    -

    The first thing a client application must do is create an authorization key which is normally generated when it is first run and almost never changes.

    -

    The protocol's principal drawback is that an intruder passively intercepting messages and then somehow appropriating the authorization key (for example, by stealing a device) will be able to decrypt all the intercepted messages post factum. This probably is not too much of a problem (by stealing a device, one could also gain access to all the information cached on the device without decrypting anything); however, the following steps could be taken to overcome this weakness:

    -
      -
    • Session keys generated using the Diffie-Hellman protocol and used in conjunction with the authorization and the message keys to select AES parameters. To create these, the first thing a client must do after creating a new session is send a special RPC query to the server (“generate session key”) to which the server will respond, whereupon all subsequent messages within the session are encrypted using the session key as well.
      • -
    • Protecting the key stored on the client device with a (text) password; this password is never stored in memory and is entered by a user when starting the application or more frequently (depending on application settings).
      • -
    • Data stored (cached) on the user device can also be protected by encryption using an authorization key which, in turn, is to be password-protected. Then, a password will be required to gain access even to that data.
      • -
    -

    Time Synchronization

    -

    If client time diverges widely from server time, a server may start ignoring client messages, or vice versa, because of an invalid message identifier (which is closely related to creation time). Under these circumstances, the server will send the client a special message containing the correct time and a certain 128-bit salt (either explicitly provided by the client in a special RPC synchronization request or equal to the key of the latest message received from the client during the current session). This message could be the first one in a container that includes other messages (if the time discrepancy is significant but does not as yet result in the client's messages being ignored).

    -

    Having received such a message or a container holding it, the client first performs a time synchronization (in effect, simply storing the difference between the server's time and its own to be able to compute the “correct” time in the future) and then verifies that the message identifiers for correctness.

    -

    Where a correction has been neglected, the client will have to generate a new session to assure the monotonicity of message identifiers.

    -

    MTProto transport

    -

    Before being sent using the selected transport protocol, the payload has to be wrapped in a secondary protocol header, defined by the appropriate MTProto transport protocol.

    - -

    The server recognizes these different protocols (and distinguishes them from HTTP, too) by the header. -Additionally, the following transport features can be used:

    - -

    Example implementations for these protocols can be seen in tdlib and MadelineProto.

    -

    Transport

    -

    Enables the delivery of encrypted containers together with the external header (hereinafter, Payload) from client to server and back. -Multiple transport protocols are defined:

    - -

    (We shall examine only the first five types.)

    -

    Recap

    -

    To recap, using the ISO/OSI stack as comparison:

    -
    - -
    - -
    -
    -
    -
    -
    -
    Telegram
    -
    - Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed. -
    - -
    -
    About
    - -
    -
    -
    Mobile Apps
    - -
    -
    -
    Desktop Apps
    - -
    -
    -
    Platform
    - -
    -
    -
    -
    -
    About
    -
    -
    -
    Blog
    -
    -
    -
    Apps
    -
    -
    -
    Platform
    -
    -
    -
    Twitter
    -
    -
    -
    -
    - - - - - - - - diff --git a/data/corefork.telegram.org/mtproto_v1.html b/data/corefork.telegram.org/mtproto_v1.html deleted file mode 100644 index a8b5ff7ae3..0000000000 --- a/data/corefork.telegram.org/mtproto_v1.html +++ /dev/null @@ -1,229 +0,0 @@ - - - - - MTProto Mobile Protocol v.1.0 (DEPRECATED) - - - - - - - - - - - - - -
    -
    -
    -
    - - -
    -
    -
    -
    -
    -
    -
    -

    MTProto Mobile Protocol v.1.0 (DEPRECATED)

    - -
    -

    This document describes MTProto v1.0, its status is DEPRECATED.
    For information on encryption used in up-to-date Telegram clients, kindly see this document.

    -
    -

    Related articles

    -

    - -

    -
    -

    This page deals with the basic layer of MTProto encryption used for Cloud chats (server-client encryption). See also:

    - -

    General Description

    -

    The protocol is designed for access to a server API from applications running on mobile devices. It must be emphasized that a web browser is not such an application.

    -

    The protocol is subdivided into three virtually independent components:

    -
      -
    • High-level component (API query language): defines the method whereby API queries and responses are converted to binary messages.
      • -
    • Cryptographic (authorization) layer: defines the method by which messages are encrypted prior to being transmitted through the transport protocol.
      • -
    • Transport component: defines the method for the client and the server to transmit messages over some other existing network protocol (such as, http, https, tcp, udp).
      • -
    - - -
    -

    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
    -

    See additional comments on our use of IGE, SHA-1 and message authentication.

    -
    Note 3
    -

    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.

    -

    Brief Component Summary

    -

    High-Level Component (RPC Query Language/API)

    -

    From the standpoint of the high-level component, the client and the server exchange messages inside a session. The session is attached to the client device (the application, to be more exact) rather than a specific http/https/tcp connection. In addition, each session is attached to a user key ID by which authorization is actually accomplished.

    -

    Several connections to a server may be open; messages may be sent in either direction through any of the connections (a response to a query is not necessarily returned through the same connection that carried the original query, although most often, that is the case; however, in no case can a message be returned through a connection belonging to a different session). When the UDP protocol is used, a response might be returned by a different IP address than the one to which the query had been sent.

    -

    There are several types of messages:

    -
      -
    • RPC calls (client to server): calls to API methods
      • -
    • RPC responses (server to client): results of RPC calls
      • -
    • Message received acknowledgment (or rather, notification of status of a set of messages)
      • -
    • Message status query
      • -
    • Multipart message or container (a container that holds several messages; needed to send several RPC calls at once over an HTTP connection, for example; also, a container may support gzip).
      • -
    -

    From the standpoint of lower level protocols, a message is a binary data stream aligned along a 4 or 16-byte boundary. The first several fields in the message are fixed and are used by the cryptographic/authorization system.

    -

    Each message, either individual or inside a container, consists of a message identifier (64 bits, see below), a message sequence number within a session (32 bits), the length (of the message body in bytes; 32 bits), and a body (any size which is a multiple of 4 bytes). In addition, when a container or a single message is sent, an internal header is added at the top (see below), then the entire message is encrypted, and an external header is placed at the top of the message (a 64-bit key identifier and a 128-bit message key).

    -

    A message body normally consists of a 32-bit message type followed by type-dependent parameters. In particular, each RPC function has a corresponding message type. For more detail, see Binary Data Serialization, Mobile Protocol: Service Messages.

    -

    All numbers are written as little endian. However, very large numbers (2048-bit) used in RSA and DH are written in the big endian format because that is what the OpenSSL library does.

    -

    Authorization and Encryption

    -

    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 defines an actual 256-bit key which is what encrypts the message using AES-256 encryption. 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.

    -

    For a technical specification, see Mobile Protocol: Detailed Description
    The first thing a client application must do is create an authorization key which is normally generated when it is first run and almost never changes.

    -

    The protocol’s principal drawback is that an intruder passively intercepting messages and then somehow appropriating the authorization key (for example, by stealing a device) will be able to decrypt all the intercepted messages post factum. This probably is not too much of a problem (by stealing a device, one could also gain access to all the information cached on the device without decrypting anything); however, the following steps could be taken to overcome this weakness:

    -
      -
    • Session keys generated using the Diffie-Hellman protocol and used in conjunction with the authorization and the message keys to select AES parameters. To create these, the first thing a client must do after creating a new session is send a special RPC query to the server (“generate session key”) to which the server will respond, whereupon all subsequent messages within the session are encrypted using the session key as well.
      • -
    • Protecting the key stored on the client device with a (text) password; this password is never stored in memory and is entered by a user when starting the application or more frequently (depending on application settings).
      • -
    • Data stored (cached) on the user device can also be protected by encryption using an authorization key which, in turn, is to be password-protected. Then, a password will be required to gain access even to those data.
      • -
    -

    Time Synchronization

    -

    If client time diverges widely from server time, a server may start ignoring client messages, or vice versa, because of an invalid message identifier (which is closely related to creation time). Under these circumstances, the server will send the client a special message containing the correct time and a certain 128-bit salt (either explicitly provided by the client in a special RPC synchronization request or equal to the key of the latest message received from the client during the current session). This message could be the first one in a container that includes other messages (if the time discrepancy is significant but does not as yet result in the client’s messages being ignored).

    -

    Having received such a message or a container holding it, the client first performs a time synchronization (in effect, simply storing the difference between the server’s time and its own to be able to compute the “correct” time in the future) and then verifies that the message identifiers for correctness.

    -

    Where a correction has been neglected, the client will have to generate a new session to assure the monotonicity of message identifiers.

    -

    Transport

    -

    Enables the delivery of encrypted containers together with the external header (hereinafter, Payload) from client to server and back. There are three types of transport:

    -
      -
    • HTTP
      • -
    • TCP
      • -
    • UDP
      • -
    -

    We shall examine the first two types.

    -

    HTTP Transport

    -

    Implemented over HTTP/1.1 (with keepalive) running over the traditional TCP Port 80. HTTPS is not used; the above encryption method is used instead.

    -

    An HTTP connection is attached to a session (or rather, to session + key identifier) specified in the most recent user query received; normally, the session is the same in all queries, but crafty HTTP proxies may corrupt that. A server may not return a message into an HTTP connection unless it belongs to the same session, and unless it is the server’s turn (an HTTP request had been received from the client to which a response has not been sent yet).

    -

    The overall arrangement is as follows. The client opens one or more keepalive HTTP connections to the server. If one or more messages need to be sent, they are made into a payload which is followed by a POST request to the URL/api to which the payload is transmitted as data. In addition, Content-Length, Keepalive, and Host are valid HTTP headers.

    -

    Having received the query, the server may either wait a little while (if the query requires a response following a short timeout) or immediately return a dummy response (only acknowledging the receipt of the container). In any case, the response may contain any number of messages. The server may at the same time send out any other messages it might be holding for the session.

    -

    In addition, there exists a special long poll RPC query (valid for HTTP connections only) which transmits maximum timeout T. If the server has messages for the session, they are returned immediately; otherwise, a wait state is entered until such time as the server has a message for the client or T seconds have elapsed. If no events occur in the span of T seconds, a dummy response is returned (special message).

    -

    If a server needs to send a message to a client, it checks for an HTTP connection that belongs to the required session and is in the “answering an HTTP request” state (including long poll) whereupon the message is added to the response container for the connection and sent to the user. In a typical case, there is some additional wait time (50 milliseconds) against the eventuality that the server will soon have more messages for the session.

    -

    If no suitable HTTP connection is available, the messages are placed in the current session’s send queue. However, they find their way there anyway until receipt is explicitly or indirectly confirmed by the client. For the HTTP protocol, sending the next query into the same HTTP connection is regarded as an implicit acknowledgment (not any more, the HTTP protocol also requires that explicit acknowledgments be sent); in other cases, the client must return an explicit acknowledgment within a reasonable time (it can be added to a container for the following request).

    -

    Important: if the acknowledgment fails to arrive on time, the message can be resent (possibly, in a different container). The parties must autonomously be ready for this and must store the identifiers of the most recent messages received (and ignore such duplicates rather than repeat actions). In order not to have the identifiers stored forever, there exist special garbage collection messages that take advantage of message identifier monotonicity.

    -

    If the send queue overflows or if messages stay in the queue for over 10 minutes, the server forgets them (or sends them to swap, no genius required). This may happen even faster, if the server is running out of buffer space (for example, because of serious network issues resulting in a large number of connections becoming severed).

    -

    TCP Transport

    -

    This is very similar to the HTTP transport. May also be implemented over Port 80 (to penetrate all firewalls) and even use the same server IP addresses. In this situation, the server understands whether HTTP or TCP protocol must be used for the connection, based on the first four incoming bytes (for HTTP, it is POST).

    -

    When a TCP connection is created, it is assigned to the session (and the authorization key) transmitted in the first user message, and subsequently used exclusively for this session (multiplexing arrangements are not allowed).

    -

    If a payload (packet) needs to be transmitted from server to client or from client to server, it is encapsulated as follows: 4 length bytes are added at the front (to include the length, the sequence number, and CRC32; always divisible by 4) and 4 bytes with the packet sequence number within this TCP connection (the first packet sent is numbered 0, the next one 1, etc.), and 4 CRC32 bytes at the end (length, sequence number, and payload together).

    -

    There is an abridged version of the same protocol: if the client sends 0xef as the first byte (important: only prior to the very first data packet), then packet length is encoded by a single byte (0x01..0x7e = data length divided by 4; or 0x7f followed by 3 length bytes (little endian) divided by 4) followed by the data themselves (sequence number and CRC32 not added). In this case, server responses look the same (the server does not send 0xefas the first byte).

    -

    In case 4-byte data alignment is needed, an intermediate version of the original protocol may be used: if the client sends 0xeeeeeeee as the first int (four bytes), then packet length is encoded always by four bytes as in the original version, but the sequence number and CRC32 are omitted, thus decreasing total packet size by 8 bytes.

    -

    The full, the intermediate and the abridged versions of the protocol have support for quick acknowledgment. In this case, the client sets the highest-order length bit in the query packet, and the server responds with a special 4 bytes as a separate packet. They are the 32 higher-order SHA1 bits of the encrypted portion of the packet with the most significant bit set to make clear that this is not the length of a regular server response packet; if the abridged version is used, bswap is applied to these four bytes.

    -

    There are no implicit acknowledgments for the TCP transport: all messages must be acknowledged explicitly. Most frequently, acknowledgments are placed in a container with the next query or response if it is transmitted in short order. For example, this is almost always the case for client messages containing RPC queries: the acknowledgment normally arrives with the RPC response.

    -

    In the event of an error, the server may send a packet whose payload consists of 4 bytes as the error code. For example, Error Code 403 corresponds to situations where the corresponding HTTP error would have been returned by the HTTP protocol.

    -
    - -
    - -
    -
    -
    -
    -
    -
    Telegram
    -
    - Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed. -
    - -
    -
    About
    - -
    -
    -
    Mobile Apps
    - -
    -
    -
    Desktop Apps
    - -
    -
    -
    Platform
    - -
    -
    -
    -
    -
    About
    -
    -
    -
    Blog
    -
    -
    -
    Apps
    -
    -
    -
    Platform
    -
    -
    -
    Twitter
    -
    -
    -
    -
    - - - - - - diff --git a/data/corefork.telegram.org/schema/mtproto-json.html b/data/corefork.telegram.org/schema/mtproto-json.html deleted file mode 100644 index ceca9f3321..0000000000 --- a/data/corefork.telegram.org/schema/mtproto-json.html +++ /dev/null @@ -1 +0,0 @@ -{"constructors":[{"id":"481674261","predicate":"vector","params":[],"type":"Vector t"},{"id":"85337187","predicate":"resPQ","params":[{"name":"nonce","type":"int128"},{"name":"server_nonce","type":"int128"},{"name":"pq","type":"bytes"},{"name":"server_public_key_fingerprints","type":"Vector"}],"type":"ResPQ"},{"id":"-1443537003","predicate":"p_q_inner_data_dc","params":[{"name":"pq","type":"bytes"},{"name":"p","type":"bytes"},{"name":"q","type":"bytes"},{"name":"nonce","type":"int128"},{"name":"server_nonce","type":"int128"},{"name":"new_nonce","type":"int256"},{"name":"dc","type":"int"}],"type":"P_Q_inner_data"},{"id":"1459478408","predicate":"p_q_inner_data_temp_dc","params":[{"name":"pq","type":"bytes"},{"name":"p","type":"bytes"},{"name":"q","type":"bytes"},{"name":"nonce","type":"int128"},{"name":"server_nonce","type":"int128"},{"name":"new_nonce","type":"int256"},{"name":"dc","type":"int"},{"name":"expires_in","type":"int"}],"type":"P_Q_inner_data"},{"id":"-790100132","predicate":"server_DH_params_ok","params":[{"name":"nonce","type":"int128"},{"name":"server_nonce","type":"int128"},{"name":"encrypted_answer","type":"bytes"}],"type":"Server_DH_Params"},{"id":"-1249309254","predicate":"server_DH_inner_data","params":[{"name":"nonce","type":"int128"},{"name":"server_nonce","type":"int128"},{"name":"g","type":"int"},{"name":"dh_prime","type":"bytes"},{"name":"g_a","type":"bytes"},{"name":"server_time","type":"int"}],"type":"Server_DH_inner_data"},{"id":"1715713620","predicate":"client_DH_inner_data","params":[{"name":"nonce","type":"int128"},{"name":"server_nonce","type":"int128"},{"name":"retry_id","type":"long"},{"name":"g_b","type":"bytes"}],"type":"Client_DH_Inner_Data"},{"id":"1003222836","predicate":"dh_gen_ok","params":[{"name":"nonce","type":"int128"},{"name":"server_nonce","type":"int128"},{"name":"new_nonce_hash1","type":"int128"}],"type":"Set_client_DH_params_answer"},{"id":"1188831161","predicate":"dh_gen_retry","params":[{"name":"nonce","type":"int128"},{"name":"server_nonce","type":"int128"},{"name":"new_nonce_hash2","type":"int128"}],"type":"Set_client_DH_params_answer"},{"id":"-1499615742","predicate":"dh_gen_fail","params":[{"name":"nonce","type":"int128"},{"name":"server_nonce","type":"int128"},{"name":"new_nonce_hash3","type":"int128"}],"type":"Set_client_DH_params_answer"},{"id":"1973679973","predicate":"bind_auth_key_inner","params":[{"name":"nonce","type":"long"},{"name":"temp_auth_key_id","type":"long"},{"name":"perm_auth_key_id","type":"long"},{"name":"temp_session_id","type":"long"},{"name":"expires_at","type":"int"}],"type":"BindAuthKeyInner"},{"id":"-212046591","predicate":"rpc_result","params":[{"name":"req_msg_id","type":"long"},{"name":"result","type":"Object"}],"type":"RpcResult"},{"id":"558156313","predicate":"rpc_error","params":[{"name":"error_code","type":"int"},{"name":"error_message","type":"string"}],"type":"RpcError"},{"id":"1579864942","predicate":"rpc_answer_unknown","params":[],"type":"RpcDropAnswer"},{"id":"-847714938","predicate":"rpc_answer_dropped_running","params":[],"type":"RpcDropAnswer"},{"id":"-1539647305","predicate":"rpc_answer_dropped","params":[{"name":"msg_id","type":"long"},{"name":"seq_no","type":"int"},{"name":"bytes","type":"int"}],"type":"RpcDropAnswer"},{"id":"155834844","predicate":"future_salt","params":[{"name":"valid_since","type":"int"},{"name":"valid_until","type":"int"},{"name":"salt","type":"long"}],"type":"FutureSalt"},{"id":"-1370486635","predicate":"future_salts","params":[{"name":"req_msg_id","type":"long"},{"name":"now","type":"int"},{"name":"salts","type":"vector"}],"type":"FutureSalts"},{"id":"880243653","predicate":"pong","params":[{"name":"msg_id","type":"long"},{"name":"ping_id","type":"long"}],"type":"Pong"},{"id":"-501201412","predicate":"destroy_session_ok","params":[{"name":"session_id","type":"long"}],"type":"DestroySessionRes"},{"id":"1658015945","predicate":"destroy_session_none","params":[{"name":"session_id","type":"long"}],"type":"DestroySessionRes"},{"id":"-1631450872","predicate":"new_session_created","params":[{"name":"first_msg_id","type":"long"},{"name":"unique_id","type":"long"},{"name":"server_salt","type":"long"}],"type":"NewSession"},{"id":"1945237724","predicate":"msg_container","params":[{"name":"messages","type":"vector<%Message>"}],"type":"MessageContainer"},{"id":"1538843921","predicate":"message","params":[{"name":"msg_id","type":"long"},{"name":"seqno","type":"int"},{"name":"bytes","type":"int"},{"name":"body","type":"Object"}],"type":"Message"},{"id":"-530561358","predicate":"msg_copy","params":[{"name":"orig_message","type":"Message"}],"type":"MessageCopy"},{"id":"812830625","predicate":"gzip_packed","params":[{"name":"packed_data","type":"bytes"}],"type":"Object"},{"id":"1658238041","predicate":"msgs_ack","params":[{"name":"msg_ids","type":"Vector"}],"type":"MsgsAck"},{"id":"-1477445615","predicate":"bad_msg_notification","params":[{"name":"bad_msg_id","type":"long"},{"name":"bad_msg_seqno","type":"int"},{"name":"error_code","type":"int"}],"type":"BadMsgNotification"},{"id":"-307542917","predicate":"bad_server_salt","params":[{"name":"bad_msg_id","type":"long"},{"name":"bad_msg_seqno","type":"int"},{"name":"error_code","type":"int"},{"name":"new_server_salt","type":"long"}],"type":"BadMsgNotification"},{"id":"2105940488","predicate":"msg_resend_req","params":[{"name":"msg_ids","type":"Vector"}],"type":"MsgResendReq"},{"id":"-630588590","predicate":"msgs_state_req","params":[{"name":"msg_ids","type":"Vector"}],"type":"MsgsStateReq"},{"id":"81704317","predicate":"msgs_state_info","params":[{"name":"req_msg_id","type":"long"},{"name":"info","type":"bytes"}],"type":"MsgsStateInfo"},{"id":"-1933520591","predicate":"msgs_all_info","params":[{"name":"msg_ids","type":"Vector"},{"name":"info","type":"bytes"}],"type":"MsgsAllInfo"},{"id":"661470918","predicate":"msg_detailed_info","params":[{"name":"msg_id","type":"long"},{"name":"answer_msg_id","type":"long"},{"name":"bytes","type":"int"},{"name":"status","type":"int"}],"type":"MsgDetailedInfo"},{"id":"-2137147681","predicate":"msg_new_detailed_info","params":[{"name":"answer_msg_id","type":"long"},{"name":"bytes","type":"int"},{"name":"status","type":"int"}],"type":"MsgDetailedInfo"},{"id":"-161422892","predicate":"destroy_auth_key_ok","params":[],"type":"DestroyAuthKeyRes"},{"id":"178201177","predicate":"destroy_auth_key_none","params":[],"type":"DestroyAuthKeyRes"},{"id":"-368010477","predicate":"destroy_auth_key_fail","params":[],"type":"DestroyAuthKeyRes"}],"methods":[{"id":"-1099002127","method":"req_pq_multi","params":[{"name":"nonce","type":"int128"}],"type":"ResPQ"},{"id":"-686627650","method":"req_DH_params","params":[{"name":"nonce","type":"int128"},{"name":"server_nonce","type":"int128"},{"name":"p","type":"bytes"},{"name":"q","type":"bytes"},{"name":"public_key_fingerprint","type":"long"},{"name":"encrypted_data","type":"bytes"}],"type":"Server_DH_Params"},{"id":"-184262881","method":"set_client_DH_params","params":[{"name":"nonce","type":"int128"},{"name":"server_nonce","type":"int128"},{"name":"encrypted_data","type":"bytes"}],"type":"Set_client_DH_params_answer"},{"id":"1491380032","method":"rpc_drop_answer","params":[{"name":"req_msg_id","type":"long"}],"type":"RpcDropAnswer"},{"id":"-1188971260","method":"get_future_salts","params":[{"name":"num","type":"int"}],"type":"FutureSalts"},{"id":"2059302892","method":"ping","params":[{"name":"ping_id","type":"long"}],"type":"Pong"},{"id":"-213746804","method":"ping_delay_disconnect","params":[{"name":"ping_id","type":"long"},{"name":"disconnect_delay","type":"int"}],"type":"Pong"},{"id":"-414113498","method":"destroy_session","params":[{"name":"session_id","type":"long"}],"type":"DestroySessionRes"},{"id":"-1835453025","method":"http_wait","params":[{"name":"max_delay","type":"int"},{"name":"wait_after","type":"int"},{"name":"max_wait","type":"int"}],"type":"HttpWait"},{"id":"-784117408","method":"destroy_auth_key","params":[],"type":"DestroyAuthKeyRes"}]} \ No newline at end of file diff --git a/data/corefork.telegram.org/schema/mtproto.html b/data/corefork.telegram.org/schema/mtproto.html deleted file mode 100644 index 8877a51951..0000000000 --- a/data/corefork.telegram.org/schema/mtproto.html +++ /dev/null @@ -1,204 +0,0 @@ - - - - - Current MTProto TL-schema - - - - - - - - - - - - - -
    -
    -
    -
    - - -
    -
    -
    -
    -
    -
    -
    -

    Current MTProto TL-schema

    - -

    Below you will find the current MTProto TL-schema. More details on TL »

    -

    See also the detailed schema in JSON »

    -


    -
    int ? = Int;
-long ? = Long;
-double ? = Double;
-string ? = String;
-
-vector {t:Type} # [ t ] = Vector t;
-
-int128 4*[ int ] = Int128;
-int256 8*[ int ] = Int256;
-
-resPQ#05162463 nonce:int128 server_nonce:int128 pq:bytes server_public_key_fingerprints:Vector<long> = ResPQ;
-
-p_q_inner_data_dc#a9f55f95 pq:bytes p:bytes q:bytes nonce:int128 server_nonce:int128 new_nonce:int256 dc:int = P_Q_inner_data;
-p_q_inner_data_temp_dc#56fddf88 pq:bytes p:bytes q:bytes nonce:int128 server_nonce:int128 new_nonce:int256 dc:int expires_in:int = P_Q_inner_data;
-
-server_DH_params_ok#d0e8075c nonce:int128 server_nonce:int128 encrypted_answer:bytes = Server_DH_Params;
-
-server_DH_inner_data#b5890dba nonce:int128 server_nonce:int128 g:int dh_prime:bytes g_a:bytes server_time:int = Server_DH_inner_data;
-
-client_DH_inner_data#6643b654 nonce:int128 server_nonce:int128 retry_id:long g_b:bytes = Client_DH_Inner_Data;
-
-dh_gen_ok#3bcbf734 nonce:int128 server_nonce:int128 new_nonce_hash1:int128 = Set_client_DH_params_answer;
-dh_gen_retry#46dc1fb9 nonce:int128 server_nonce:int128 new_nonce_hash2:int128 = Set_client_DH_params_answer;
-dh_gen_fail#a69dae02 nonce:int128 server_nonce:int128 new_nonce_hash3:int128 = Set_client_DH_params_answer;
-
-bind_auth_key_inner#75a3f765 nonce:long temp_auth_key_id:long perm_auth_key_id:long temp_session_id:long expires_at:int = BindAuthKeyInner;
-
-rpc_result#f35c6d01 req_msg_id:long result:Object = RpcResult;
-rpc_error#2144ca19 error_code:int error_message:string = RpcError;
-
-rpc_answer_unknown#5e2ad36e = RpcDropAnswer;
-rpc_answer_dropped_running#cd78e586 = RpcDropAnswer;
-rpc_answer_dropped#a43ad8b7 msg_id:long seq_no:int bytes:int = RpcDropAnswer;
-
-future_salt#0949d9dc valid_since:int valid_until:int salt:long = FutureSalt;
-future_salts#ae500895 req_msg_id:long now:int salts:vector<future_salt> = FutureSalts;
-
-pong#347773c5 msg_id:long ping_id:long = Pong;
-
-destroy_session_ok#e22045fc session_id:long = DestroySessionRes;
-destroy_session_none#62d350c9 session_id:long = DestroySessionRes;
-
-new_session_created#9ec20908 first_msg_id:long unique_id:long server_salt:long = NewSession;
-
-msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;
-message msg_id:long seqno:int bytes:int body:Object = Message;
-msg_copy#e06046b2 orig_message:Message = MessageCopy;
-
-gzip_packed#3072cfa1 packed_data:bytes = Object;
-
-msgs_ack#62d6b459 msg_ids:Vector<long> = MsgsAck;
-
-bad_msg_notification#a7eff811 bad_msg_id:long bad_msg_seqno:int error_code:int = BadMsgNotification;
-bad_server_salt#edab447b bad_msg_id:long bad_msg_seqno:int error_code:int new_server_salt:long = BadMsgNotification;
-
-msg_resend_req#7d861a08 msg_ids:Vector<long> = MsgResendReq;
-msgs_state_req#da69fb52 msg_ids:Vector<long> = MsgsStateReq;
-msgs_state_info#04deb57d req_msg_id:long info:bytes = MsgsStateInfo;
-msgs_all_info#8cc0d131 msg_ids:Vector<long> info:bytes = MsgsAllInfo;
-msg_detailed_info#276d3ec6 msg_id:long answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
-msg_new_detailed_info#809db6df answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
-
-destroy_auth_key_ok#f660e1d4 = DestroyAuthKeyRes;
-destroy_auth_key_none#0a9f2259 = DestroyAuthKeyRes;
-destroy_auth_key_fail#ea109b13 = DestroyAuthKeyRes;
-
----functions---
-
-req_pq_multi#be7e8ef1 nonce:int128 = ResPQ;
-
-req_DH_params#d712e4be nonce:int128 server_nonce:int128 p:bytes q:bytes public_key_fingerprint:long encrypted_data:bytes = Server_DH_Params;
-
-set_client_DH_params#f5045f1f nonce:int128 server_nonce:int128 encrypted_data:bytes = Set_client_DH_params_answer;
-
-rpc_drop_answer#58e4a740 req_msg_id:long = RpcDropAnswer;
-get_future_salts#b921bd04 num:int = FutureSalts;
-ping#7abe77ec ping_id:long = Pong;
-ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;
-destroy_session#e7512126 session_id:long = DestroySessionRes;
-
-http_wait#9299359f max_delay:int wait_after:int max_wait:int = HttpWait;
-
-destroy_auth_key#d1435160 = DestroyAuthKeyRes;
    - -
    - -
    -
    -
    -
    -
    -
    Telegram
    -
    - Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed. -
    - -
    -
    About
    - -
    -
    -
    Mobile Apps
    - -
    -
    -
    Desktop Apps
    - -
    -
    -
    Platform
    - -
    -
    -
    -
    -
    About
    -
    -
    -
    Blog
    -
    -
    -
    Apps
    -
    -
    -
    Platform
    -
    -
    -
    Twitter
    -
    -
    -
    -
    - - - - - - diff --git a/data/telegram.org/tour.html b/data/telegram.org/tour.html deleted file mode 100644 index b45a72b141..0000000000 --- a/data/telegram.org/tour.html +++ /dev/null @@ -1,144 +0,0 @@ - - - - - Telegram Tour - - - - - - - - - - - - - - - - - - - -
    -
    -
    -
    -
    - - -
    -
    -
    -
    -
    -
    -

    Telegram News

    -
    -
    - -
    -

    Quizzes

    -
    With the help of Quiz Bot you can create multi-question quizzes and share them with others. The bot lets you add text or media before questions to help create exam-style prompts with…
    -
    -
    Dec 22, 2020
    -
    - -
    -

    Group Chats on Telegram

    -
    Telegram groups are a powerful tool for building communities and each can have up to 200,000 members.
    -
    -
    Jan 29, 2018
    -
    - -
    -

    Telegram Channels

    -
    Channels are a tool for broadcasting your public messages to large audiences. They offer a unique opportunity to reach people directly, sending a notification to their phones with…
    -
    -
    Jan 29, 2018
    -
     -
    - -
    - -
    -
    -
    -
    -
    -
    -
    Telegram
    -
    - Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed. -
    - -
    -
    About
    - -
    -
    -
    Mobile Apps
    - -
    -
    -
    Desktop Apps
    - -
    -
    -
    Platform
    - -
    -
    -
    -
    -
    About
    -
    -
    -
    Blog
    -
    -
    -
    Apps
    -
    -
    -
    Platform
    -
    -
    -
    Twitter
    -
    -
    -
    - - - - - -