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 ».
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 thehidden 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.
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.
quote_text field.quote_text within the original message (in UTF-16 code units).quote_text field.quote_text within the original message (in UTF-16 code units).msg_detailed_infomsg_new_detailed_infomsg_resend_reqmsg_resend_ans_reqIn 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 requestsAt 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.
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.