From 10844a9890e6706e3313ea4ce03669242d8e6207 Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Sat, 23 Dec 2023 19:24:44 +0000 Subject: [PATCH] Update content of files --- data/web/corefork.telegram.org/api/boost.html | 2 +- data/web/corefork.telegram.org/api/colors.html | 2 +- data/web/corefork.telegram.org/api/invoking.html | 2 +- .../constructor/attachMenuBot.html | 2 +- .../constructor/inputReplyToMessage.html | 6 +++--- .../constructor/messageReplyHeader.html | 12 ++++++------ .../corefork.telegram.org/mtproto/description.html | 1 - .../mtproto/service_messages.html | 11 ++++++++++- 8 files changed, 23 insertions(+), 15 deletions(-) diff --git a/data/web/corefork.telegram.org/api/boost.html b/data/web/corefork.telegram.org/api/boost.html index 204f6c1bf2..2eef4ab691 100644 --- a/data/web/corefork.telegram.org/api/boost.html +++ b/data/web/corefork.telegram.org/api/boost.html @@ -94,7 +94,7 @@ A BOOST_NOT_MODIFIED RPC error will be returned when calling any of

Everything works exactly the same as when posting stories as a user, with the only difference that clients should pass the appropriate inputPeerChannel instead of inputPeerSelf to stories.canSendStory, stories.sendStory and all the other story methods, see the main documentation » for more info.

Use stories.getChatsToSend to obtain a list of channels where the user can post stories; stories.canSendStory must still be used before uploading a story to make sure no other limit was reached, as described in the main documentation ».

Changing message accents

-

After reaching at least boost level channel_color_level_min », channels gain the ability to change their message accent palette ».

+

After reaching at least boost level channel_color_level_min », channels gain the ability to change their message accent and profile palettes ».

diff --git a/data/web/corefork.telegram.org/api/colors.html b/data/web/corefork.telegram.org/api/colors.html index b75bf9d77b..3cb08a251d 100644 --- a/data/web/corefork.telegram.org/api/colors.html +++ b/data/web/corefork.telegram.org/api/colors.html @@ -82,7 +82,7 @@ If the hidden flag is set it should not be displayed as an option t

Use account.updateColor to update the color palette of the current account's message accents and/or profile page; note that the current account must be subscribed to Telegram Premium in order to call the method.
Use channels.updateColor to update the color palette of a channel's message accents; note that channels have to be boosted » at least to level channel_color_level_min » in order to use this method.

The chosen message accent palette will be visible to other users in the channel.color and user.color fields.

-

User profile palettes will be visible in the user.profile_color field.

+

The chosen user and channel profile palettes will be visible in the user.profile_color and channel.profile_color fields.

diff --git a/data/web/corefork.telegram.org/api/invoking.html b/data/web/corefork.telegram.org/api/invoking.html index 3305b71887..3aff17c67a 100644 --- a/data/web/corefork.telegram.org/api/invoking.html +++ b/data/web/corefork.telegram.org/api/invoking.html @@ -69,7 +69,7 @@ These methods allow reducing the latency for calls which require strict ordering

They may be used, for example, when a client attempts to send messages that accumulated while waiting for the Internet connection to be restored for a long time. In this case, the 32-bit number 0xcb9f372d must be added before the method number in each request, followed by a 64-bit message identifier, msg_id, which contains the previous request in the queue.

The second method is similar, except it takes several messages that must be successfully processed before the current one.

-

If the waiting period exceeds 0.5 seconds (this value may change in the future) and no result has appeared, the method will return the 400/500 MSG_WAIT_TIMEOUT error: handle this error by resending the request, still wrapped in the same invokeAfterMsg/invokeAfterMsgs constructor with the same id/ids.

+

If the waiting period exceeds 0.5 seconds (this value may change in the future) and no result has appeared, the method will return the MSG_WAIT_TIMEOUT error: handle this error by resending the request, still wrapped in the same invokeAfterMsg/invokeAfterMsgs constructor with the same id/ids.

If any of the previous queries mentioned in msg_ids or msg_id fails (i.e. an RPC error is emitted by a query, including FLOOD_WAIT_ errors), a MSG_WAIT_FAILED error will be returned for the current request: the simplest way to handle it is to simply enforce local synchronization, by waiting for a response from all previous msg_ids/msg_id before resending the request.

If and only if any of the previous requests also failed with MSG_WAIT_FAILED/MSG_WAIT_TIMEOUT errors and require resending, wrap the current request in another invokeAfterMsg/invokeAfterMsgs constructor with the new IDs of the previous requests, resent along with the current one.

Scenario 1

diff --git a/data/web/corefork.telegram.org/constructor/attachMenuBot.html b/data/web/corefork.telegram.org/constructor/attachMenuBot.html index b97a7ae27a..e7d9558fa1 100644 --- a/data/web/corefork.telegram.org/constructor/attachMenuBot.html +++ b/data/web/corefork.telegram.org/constructor/attachMenuBot.html @@ -80,7 +80,7 @@ has_settings flags.1?true -True, if the bot supports the "settings_button_pressed" event » +Deprecated flag, can be ignored. request_write_access diff --git a/data/web/corefork.telegram.org/constructor/inputReplyToMessage.html b/data/web/corefork.telegram.org/constructor/inputReplyToMessage.html index 999e2e6f5e..902bef2a34 100644 --- a/data/web/corefork.telegram.org/constructor/inputReplyToMessage.html +++ b/data/web/corefork.telegram.org/constructor/inputReplyToMessage.html @@ -89,17 +89,17 @@ quote_text flags.2?string -  +Used to quote-reply to only a certain section (specified here) of the original message. quote_entities flags.3?Vector<MessageEntity> -Message entities for styled text +Message entities for styled text from the quote_text field. quote_offset flags.4?int -  +Offset of the message quote_text within the original message (in UTF-16 code units). diff --git a/data/web/corefork.telegram.org/constructor/messageReplyHeader.html b/data/web/corefork.telegram.org/constructor/messageReplyHeader.html index ee8ac51ed7..93c7f7050f 100644 --- a/data/web/corefork.telegram.org/constructor/messageReplyHeader.html +++ b/data/web/corefork.telegram.org/constructor/messageReplyHeader.html @@ -84,7 +84,7 @@ quote flags.9?true -  +Whether this message is quoting a part of another message. reply_to_msg_id @@ -99,12 +99,12 @@ reply_from flags.5?MessageFwdHeader -  +When replying to a message sent by a certain peer to another chat, contains info about the peer that originally sent the message to that other chat. reply_media flags.8?MessageMedia -  +When replying to a media sent by a certain peer to another chat, contains the media of the replied-to message. reply_to_top_id @@ -114,17 +114,17 @@ quote_text flags.6?string -  +Used to quote-reply to only a certain section (specified here) of the original message. quote_entities flags.7?Vector<MessageEntity> -Message entities for styled text +Message entities for styled text from the quote_text field. quote_offset flags.10?int -  +Offset of the message quote_text within the original message (in UTF-16 code units). diff --git a/data/web/corefork.telegram.org/mtproto/description.html b/data/web/corefork.telegram.org/mtproto/description.html index 7508682889..c85adfb06b 100644 --- a/data/web/corefork.telegram.org/mtproto/description.html +++ b/data/web/corefork.telegram.org/mtproto/description.html @@ -128,7 +128,6 @@ MTProto v.1.0 is deprecated and is currently being phased out.

  • msg_detailed_info
  • msg_new_detailed_info
  • msg_resend_req
    • -
  • msg_resend_ans_req

    • Message Key (msg_key)

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

    diff --git a/data/web/corefork.telegram.org/mtproto/service_messages.html b/data/web/corefork.telegram.org/mtproto/service_messages.html index 1ef2aba848..e92c5b96e0 100644 --- a/data/web/corefork.telegram.org/mtproto/service_messages.html +++ b/data/web/corefork.telegram.org/mtproto/service_messages.html @@ -125,7 +125,16 @@ Clients should group acknowledgments, state requests and message resend requests

    At the same time, the max_delay parameter has higher priority than wait_after, and max_wait has higher priority than max_delay.

    This message does not require a response or an acknowledgement. If the container transmitted over HTTP carries several such messages, the behavior is undefined (in fact, the latest parameter will be used).

    If no http_wait is present in container, default values max_delay=0 (milliseconds), wait_after=0 (milliseconds), and max_wait=25000 (milliseconds) are used.

    -

    If the client's ping of the server takes a long time, it may make sense to set max_delay to a value that is comparable in magnitude to ping time.

    +

    If the client's ping of the server takes a long time, it may make sense to set max_delay to a value that is comparable in magnitude to ping time.

    +

    Destruction of a permanent auth key

    +
    destroy_auth_key_ok#f660e1d4 = DestroyAuthKeyRes;
+destroy_auth_key_none#0a9f2259 = DestroyAuthKeyRes;
+destroy_auth_key_fail#ea109b13 = DestroyAuthKeyRes;
+
+---functions---
+
+destroy_auth_key#d1435160 = DestroyAuthKeyRes;
    +

    destroy_auth_key should be called whenever a permanent auth key isn't needed anymore, such as after the user was logged out.