From e699bf1d0f2faf27af01b1d589126fc094178881 Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Fri, 10 Sep 2021 16:35:27 +0000 Subject: [PATCH] Update content of files --- .../constructor/chatInviteEmpty.html | 132 --------------- .../inputPaymentCredentialsAndroidPay.html | 152 ------------------ .../method/phone.editGroupCallMember | 115 +++++++++++++ .../service_messages_about_messages.html | 27 ++-- 4 files changed, 128 insertions(+), 298 deletions(-) delete mode 100644 data/corefork.telegram.org/constructor/chatInviteEmpty.html delete mode 100644 data/corefork.telegram.org/constructor/inputPaymentCredentialsAndroidPay.html create mode 100644 data/corefork.telegram.org/method/phone.editGroupCallMember diff --git a/data/corefork.telegram.org/constructor/chatInviteEmpty.html b/data/corefork.telegram.org/constructor/chatInviteEmpty.html deleted file mode 100644 index 5ca1547c76..0000000000 --- a/data/corefork.telegram.org/constructor/chatInviteEmpty.html +++ /dev/null @@ -1,132 +0,0 @@ - - - - - chatInviteEmpty - - - - - - - - - - - - - -
-
-
-
- - -
-
-
-
-
-
-
-

chatInviteEmpty

- -

No info is associated to the chat invite

-

- -
-
Constructor schema is available as of layer 123. Switch »

-

Parameters

-

This constructor does not require any parameters.

-

Type

-

ExportedChatInvite

- -
- -
-
-
-
-
-
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/inputPaymentCredentialsAndroidPay.html b/data/corefork.telegram.org/constructor/inputPaymentCredentialsAndroidPay.html deleted file mode 100644 index 5b95258d9a..0000000000 --- a/data/corefork.telegram.org/constructor/inputPaymentCredentialsAndroidPay.html +++ /dev/null @@ -1,152 +0,0 @@ - - - - - inputPaymentCredentialsAndroidPay - - - - - - - - - - - - - -
-
-
-
- - -
-
-
-
-
-
-
-

inputPaymentCredentialsAndroidPay

- -

Android pay payment credentials

-

- -
-
Constructor schema is available as of layer 74. Switch »

-

Parameters

- - - - - - - - - - - - - - - - - - - - -
NameTypeDescription
payment_tokenDataJSONAndroid pay payment token
google_transaction_idstringGoogle transaction ID
-

Type

-

InputPaymentCredentials

- -
- -
-
-
-
-
-
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/method/phone.editGroupCallMember b/data/corefork.telegram.org/method/phone.editGroupCallMember new file mode 100644 index 0000000000..f73c402df5 --- /dev/null +++ b/data/corefork.telegram.org/method/phone.editGroupCallMember @@ -0,0 +1,115 @@ + + + + + Page not found + + + + + + + + + + + + + +
+
+
+
+ + +
+
+
+
+
+
+
+

Page not found

+ +
The page has not been saved
+ +
+ +
+
+
+
+
+
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/service_messages_about_messages.html b/data/corefork.telegram.org/mtproto/service_messages_about_messages.html index 1dffe0a936..48cf89b763 100644 --- a/data/corefork.telegram.org/mtproto/service_messages_about_messages.html +++ b/data/corefork.telegram.org/mtproto/service_messages_about_messages.html @@ -41,14 +41,13 @@ Receipt of virtually all messages (with the exception of some purely service one

Service Messages about Messages

-

Acknowledgment of Receipt

-

Receipt of virtually all messages (with the exception of some purely service ones as well as the plain-text messages used in the protocol for creating an authorization key) must be acknowledged. -This requires the use of the following service message (not requiring an acknowledgment):

+

Acknowledgment of Receipt

+

Receipt of virtually all messages (with the exception of some purely service ones as well as the plain-text messages used in the protocol for creating an authorization key) must be acknowledged.
This requires the use of the following service message (not requiring an acknowledgment):

msgs_ack#62d6b459 msg_ids:Vector<long> = MsgsAck;

A server usually acknowledges the receipt of a message from a client (normally, an RPC query) using an RPC response. If a response is a long time coming, a server may first send a receipt acknowledgment, and somewhat later, the RPC response itself.

A client normally acknowledges the receipt of a message from a server (usually, an RPC response) by adding an acknowledgment to the next RPC query if it is not transmitted too late (if it is generated, say, 60-120 seconds following the receipt of a message from the server). However, if for a long period of time there is no reason to send messages to the server or if there is a large number of unacknowledged messages from the server (say, over 16), the client transmits a stand-alone acknowledgment.

Max 8192 IDs are allowed per constructor.

-

Notice of Ignored Error Message

+

Notice of Ignored Error Message

In certain cases, a server may notify a client that its incoming message was ignored for whatever reason. Note that such a notification cannot be generated unless a message is correctly decoded by the server.

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;
@@ -70,12 +69,12 @@ bad_server_salt#edab447b bad_msg_id:long bad_msg_seqno:int error_code:int new_se

Notifications of an ignored message do not require acknowledgment (i.e., are irrelevant).

Important: if server_salt has changed on the server or if client time is incorrect, any query will result in a notification in the above format. The client must check that it has, in fact, recently sent a message with the specified msg_id, and if that is the case, update its time correction value (the difference between the client’s and the server’s clocks) and the server salt based on msg_id and the server_salt notification, so as to use these to (re)send future messages. In the meantime, the original message (the one that caused the error message to be returned) must also be re-sent with a better msg_id and/or server_salt.

In addition, the client can update the server_salt value used to send messages to the server, based on the values of RPC responses or containers carrying an RPC response, provided that this RPC response is actually a match for the query sent recently. (If there is doubt, it is best not to update since there is risk of a replay attack).

-

Request for Message Status Information

+

Request for Message Status Information

If either party has not received information on the status of its outgoing messages for a while, it may explicitly request it from the other party:

msgs_state_req#da69fb52 msg_ids:Vector long = MsgsStateReq;

Max 8192 IDs are allowed per constructor.

The response to the query contains the following information:

-

Informational Message regarding Status of Messages

+

Informational Message regarding Status of Messages

msgs_state_info#04deb57d req_msg_id:long info:string = MsgsStateInfo;

Here, info is a string that contains exactly one byte of message status for each message from the incoming msg_ids list:

    @@ -90,26 +89,26 @@ bad_server_salt#edab447b bad_msg_id:long bad_msg_seqno:int error_code:int new_se
  • +128 = other party knows for a fact that message is already received

This response does not require an acknowledgment. It is an acknowledgment of the relevant msgs_state_req, in and of itself.

-

Note that if it turns out suddenly that the other party is missing a message that appears to have been sent to it, the message must not be re-sent on its own with the same msg_id. Instead, it can be either wrapped in a container, or the status of the message can be checked using msgs_state_req and if the message wasn't received, then it must be re-sent with a new msg_id.

-

Voluntary Communication of Status of Messages

+

Note that if it turns out suddenly that the other party is missing a message that appears to have been sent to it, the message must not be re-sent on its own with the same msg_id. Instead, it can be either wrapped in a container, or the status of the message can be checked using msgs_state_req and if the message wasn't received, then it must be re-sent with a new msg_id.

+

Voluntary Communication of Status of Messages

Either party may voluntarily inform the other party of the status of the messages transmitted by the other party.

msgs_all_info#8cc0d131 msg_ids:Vector long info:string = MsgsAllInfo

All message codes known to this party are enumerated, with the exception of those for which the +128 and the +16 flags are set. However, if the +32 flag is set but not +64, then the message status will still be communicated.

This message does not require an acknowledgment.

-

Extended Voluntary Communication of Status of One Message

+

Extended Voluntary Communication of Status of One Message

Normally used by the server to respond to the receipt of a duplicate msg_id, especially if a response to the message has already been generated and the response is large. If the response is small, the server may re-send the answer itself instead. This message can also be used as a notification instead of resending a large message.

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;

The second version is used to notify of messages that were created on the server not in response to an RPC query (such as notifications of new messages) and were transmitted to the client some time ago, but not acknowledged.

Currently, status is always zero. This may change in future.

This message does not require an acknowledgment.

-

Explicit Request to Re-Send Messages

+

Explicit Request to Re-Send Messages

msg_resend_req#7d861a08 msg_ids:Vector long = MsgResendReq;
-

The remote party immediately responds by re-sending the requested messages, normally using the same connection that was used to transmit the query. If at least one message with requested msg_id does not exist or has already been forgotten, or has been sent by the requesting party (known from parity), MsgsStateInfo is returned for all messages requested as if the MsgResendReq query had been a MsgsStateReq query as well.
-Max 8192 IDs are allowed per constructor.

-

Explicit Request to Re-Send Answers

+

The remote party immediately responds by re-sending the requested messages, normally using the same connection that was used to transmit the query. If at least one message with requested msg_id does not exist or has already been forgotten, or has been sent by the requesting party (known from parity), MsgsStateInfo is returned for all messages requested as if the MsgResendReq query had been a MsgsStateReq query as well.
Max 8192 IDs are allowed per constructor.

+

Explicit Request to Re-Send Answers

msg_resend_ans_req#8610baeb msg_ids:Vector long = MsgResendReq;
-

The remote party immediately responds by re-sending answers to the requested messages, normally using the same connection that was used to transmit the query. MsgsStateInfo is returned for all messages requested as if the MsgResendReq query had been a MsgsStateReq query as well.

+

The remote party immediately responds by re-sending answers to the requested messages, normally using the same connection that was used to transmit the query. MsgsStateInfo is returned for all messages requested as if the MsgResendReq query had been a MsgsStateReq query as well.

+