mirror of
https://github.com/MarshalX/telegram-crawler.git
synced 2024-12-29 15:59:13 +01:00
Update content of files
This commit is contained in:
GitHub Action
parent
36d3915aca
commit
65154cf4f3
5 changed files with 17 additions and 15 deletions
|
|
@ -82,7 +82,7 @@ Folders can also have up to <code>dialogs_folder_pinned_limit_*</code> pinned ch
|
|||
<p>Clients can receive <a href="/constructor/updateDialogFilter">updateDialogFilter</a>, <a href="/constructor/updateDialogFilterOrder">updateDialogFilterOrder</a> updates with new filter information, generated by other clients when modifying folder info.<br>
|
||||
Clients can also receive <a href="/constructor/updateDialogFilters">updateDialogFilters</a>, in which case folder info should be refetched manually using <a href="/method/messages.getDialogFilters">messages.getDialogFilters</a>.</p>
|
||||
<h3><a class="anchor" href="#peer-folders" id="peer-folders" name="peer-folders"><i class="anchor-icon"></i></a>Peer folders</h3>
|
||||
<p>The API also has another method for identifying groups of peers, typically used only by archived chats.</p>
|
||||
<p>The API also has another method for identifying groups of peers, used by archived chats.</p>
|
||||
<p>Schema:</p>
|
||||
<pre><code><a href='/constructor/inputDialogPeer'>inputDialogPeer</a>#fcaafeb7 peer:<a href='/type/InputPeer'>InputPeer</a> = <a href='/type/InputDialogPeer'>InputDialogPeer</a>;
|
||||
<a href='/constructor/inputDialogPeerFolder'>inputDialogPeerFolder</a>#64600527 folder_id:<a href='/type/int'>int</a> = <a href='/type/InputDialogPeer'>InputDialogPeer</a>;
|
||||
|
|
|
|||
|
|
@ -64,15 +64,15 @@
|
|||
<a href='/constructor/updates'>updates</a>#74ae4240 updates:<a href='/type/Vector%20t'>Vector</a><<a href='/type/Update'>Update</a>> users:<a href='/type/Vector%20t'>Vector</a><<a href='/type/User'>User</a>> chats:<a href='/type/Vector%20t'>Vector</a><<a href='/type/Chat'>Chat</a>> date:<a href='/type/int'>int</a> seq:<a href='/type/int'>int</a> = <a href='/type/Updates'>Updates</a>;</code></pre>
|
||||
<p><a href="/constructor/updatesTooLong">updatesTooLong</a> indicates that there are too many events pending to be pushed to the client, so one needs to <a href="#recovering-gaps">fetch them manually</a>.</p>
|
||||
<p>Events inside <a href="/constructor/updateShort">updateShort</a> constructors, normally, have lower priority and are broadcast to a large number of users, i.e. one of the chat participants started entering text in a big conversation (<a href="/constructor/updateChatUserTyping">updateChatUserTyping</a>).</p>
|
||||
<p>The <a href="/constructor/updateShortMessage">updateShortMessage</a>, <a href="/constructor/updateShortMessage">updateShortSentMessage</a> and <a href="/constructor/updateShortChatMessage">updateShortChatMessage</a> constructors are redundant but help significantly reduce the transmitted message size for 90% of the updates. They should be transformed to <a href="/constructor/updateShort">updateShort</a> upon receiving.</p>
|
||||
<p>Two remaining constructors <a href="/constructor/updates">updates</a> and <a href="/constructor/updatesCombined">updatesCombined</a> are part of the Updates sequence. Both of them have <code>seq</code> attribute, which indicates the remote Updates state after the generation of the Updates, and <code>seq_start</code> indicates the remote Updates state after the <em>first</em> of the Updates in the packet is generated. For <a href="/constructor/updates">updates</a>, <code>seq_start</code> attribute is omitted, because it is assumed that it is always equal to <code>seq</code>.</p>
|
||||
<p>The <a href="/constructor/updateShortMessage">updateShortMessage</a>, <a href="/constructor/updateShortMessage">updateShortSentMessage</a> and <a href="/constructor/updateShortChatMessage">updateShortChatMessage</a> constructors are redundant but help significantly reduce the transmitted message size for 90% of the updates. They should be transformed to <a href="/constructor/updateShort">updateShort</a> upon receival.</p>
|
||||
<p>Two remaining constructors <a href="/constructor/updates">updates</a> and <a href="/constructor/updatesCombined">updatesCombined</a> are part of the Updates sequence. Both of them have the <code>seq</code> attribute, which indicates the remote Updates state after the generation of the Updates, and <code>seq_start</code> indicates the remote Updates state after the <em>first</em> of the Updates in the packet is generated. For <a href="/constructor/updates">updates</a>, <code>seq_start</code> attribute is omitted, because it is assumed that it is always equal to <code>seq</code>.</p>
|
||||
<h3><a class="anchor" href="#message-related-event-sequences" id="message-related-event-sequences" name="message-related-event-sequences"><i class="anchor-icon"></i></a>Message-related event sequences</h3>
|
||||
<p>Each <em>event</em> related to a message box (message created, message edited, message deleted, etc) is identified by a unique autoincremented <em>pts</em>, or <em>qts</em> in case of secret chat updates, certain bot updates, etc.</p>
|
||||
<p>Each <em>event</em> related to a message box (message created, message edited, message deleted, etc) is identified by a unique autoincremented <code>pts</code>, or <code>qts</code> in case of secret chat updates, certain bot updates, etc.</p>
|
||||
<p>Each message box can be considered as some server-side DB table that stores messages and events associated with them.
|
||||
All boxes are completely independent, and each pts sequence is tied to just one box (see below).</p>
|
||||
<p><a href="/type/Update">Update</a> object may contain info about <em>multiple events</em> (for example, <a href="/constructor/updateDeleteMessages">updateDeleteMessages</a>).
|
||||
That's why all single updates might have <em>pts_count</em> parameter indicating the <em>number of events</em> contained in the received <em>update</em> (with some exceptions, in this case, the <em>pts_count</em> is considered to be <code>0</code>).</p>
|
||||
<p>Each <a href="/api/channel#channels">channel</a> and <a href="/api/channel#supergroups">supergroup</a> has its message box and <em>its event sequence</em> as a result; private chats and <a href="/api/channel#basic-groups">basic groups</a> of one user have another <em>common event sequence</em>.
|
||||
<p>The <a href="/type/Update">Update</a> object may contain info about <em>multiple events</em> (for example, <a href="/constructor/updateDeleteMessages">updateDeleteMessages</a>).
|
||||
That's why all single updates might have <code>pts_count</code> parameter indicating the <em>number of events</em> contained in the received <em>update</em> (with some exceptions, in this case, the <code>pts_count</code> is considered to be <code>0</code>).</p>
|
||||
<p>Each <a href="/api/channel#channels">channel</a> and <a href="/api/channel#supergroups">supergroup</a> has its message box and <em>its event sequence</em> as a result; private chats and <a href="/api/channel#basic-groups">basic groups</a> of one user have another <em>common event sequence</em>.<br>
|
||||
Secret chats, certain bot events and other kinds of updates have yet another <em>common secondary event sequence</em>.</p>
|
||||
<p>To recap, the client has to take care of the integrity of the following sequences to properly handle updates:</p>
|
||||
<ul>
|
||||
|
|
@ -90,9 +90,9 @@ Secret chats, certain bot events and other kinds of updates have yet another <em
|
|||
<p>The <em>common</em> update state is represented by the <a href="/type/updates.State">updates.State</a> constructor.
|
||||
When the user logs in for the first time, call to <a href="/method/updates.getState">updates.getState</a> has to be made to store the latest update state (which will not be the absolute initial state, just the latest state at the current time).
|
||||
The common update state can also be fetched from <a href="/constructor/updates.differenceTooLong">updates.differenceTooLong</a>.</p>
|
||||
<p>The <em>channel update state</em> is represented simply by the <em>pts</em> of the event sequence: when first logging in, the initial channel state can be obtained from the <a href="/constructor/dialog">dialog</a> constructor when fetching dialogs, from <a href="/constructor/channelFull">the full channel info</a>, or it can be received <a href="https://core.telegram.org/constructor/updateChannelTooLong">as an updateChannelTooLong update</a>.</p>
|
||||
<p>The <em>secondary update state</em> is represented by the <em>qts</em> of the secret event sequence, it is contained in the <a href="/type/updates.State">updates.State</a> of the <em>common update state</em>.</p>
|
||||
<p>The <em>Updates sequence state</em> is represented by the <em>date</em> and <em>seq</em> of the <em>Updates sequence</em>, it is contained in the <a href="/type/updates.State">updates.State</a> of the <em>common</em> update state.</p>
|
||||
<p>The <em>channel update state</em> is represented simply by the <code>pts</code> of the event sequence: when first logging in, the initial channel state can be obtained from the <a href="/constructor/dialog">dialog</a> constructor when fetching dialogs, from <a href="/constructor/channelFull">the full channel info</a>, or it can be received <a href="https://core.telegram.org/constructor/updateChannelTooLong">as an updateChannelTooLong update</a>.</p>
|
||||
<p>The <em>secondary update state</em> is represented by the <code>qts</code> of the secret event sequence, it is contained in the <a href="/type/updates.State">updates.State</a> of the <em>common update state</em>.</p>
|
||||
<p>The <em>Updates sequence state</em> is represented by the <code>date</code> and <code>seq</code> of the <em>Updates sequence</em>, it is contained in the <a href="/type/updates.State">updates.State</a> of the <em>common</em> update state.</p>
|
||||
<h3><a class="anchor" href="#update-handling" id="update-handling" name="update-handling"><i class="anchor-icon"></i></a>Update handling</h3>
|
||||
<p>Update handling in Telegram clients consists of receiving events, making sure there were no gaps and no events were missed based on the locally stored state of the correspondent event sequence, and then updating the locally stored state based on the parameters received.</p>
|
||||
<p>When the client receives payload with serialized updates, first of all, it needs to walk through all of the nested <a href="/type/Update">Update</a> objects and check if they belong to any of message box sequences (have <code>pts</code> or <code>qts</code> parameters). Those updates need to be handled separately according to corresponding local state and new <code>pts</code>/<code>qts</code> values. <a href="#pts-checking-and-applying">Details below »</a></p>
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@
|
|||
<tr>
|
||||
<td><strong>min</strong></td>
|
||||
<td style="text-align: center;"><a href="/mtproto/TL-combinators#conditional-fields">flags</a>.0?<a href="/constructor/true">true</a></td>
|
||||
<td>Similar to <a href="/api/min">min</a> objects, used for poll constructors that are the same for all users so they don't have option chosen by the current user (you can use <a href="/method/messages.getPollResults">messages.getPollResults</a> to get the full poll results).</td>
|
||||
<td>Similar to <a href="/api/min">min</a> objects, used for poll constructors that are the same for all users so they don't have the option chosen by the current user (you can use <a href="/method/messages.getPollResults">messages.getPollResults</a> to get the full poll results).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><strong>results</strong></td>
|
||||
|
|
|
|||
|
|
@ -168,7 +168,7 @@ The first byte must also not be equal to <code>0xef</code> (abridged).
|
|||
Bytes <code>4-8</code> must also not be equal to <code>0x00000000</code>, since that would indicate use of the full transport with the initial TCP sequence number (0).</p>
|
||||
<p>The protocol identifier, if present, must be inserted in the initialization payload at byte offset <code>56</code>: if its length is less than 4, it must be padded using the protocol identifier itself, to make its length 4 (<code>0xef</code> => <code>0xefefefef</code>): the standalone protocol identifier must be not be sent aftwerwards.</p>
|
||||
<p>This protocol is also (but not exclusively) used when connecting to MTProxies: <strong>only in this case</strong>, the DC ID in a specially encoded form must also be inserted in the initialization payload at offset <code>60</code>.
|
||||
The encoding simply consist of the DC ID in two-byte signed little-endian form; <code>10000</code> has to be added to the DC ID to connect to the test servers; it has to be made negative if the DC we're connecting to is a media (not CDN) DC. </p>
|
||||
The encoding simply consists of the DC ID in two-byte signed little-endian form; <code>10000</code> has to be added to the DC ID to connect to the test servers; it has to be made negative if the DC we're connecting to is a media (not CDN) DC. </p>
|
||||
<p>Next, a secondary initialization payload is generated by reversing the primary initialization payload. </p>
|
||||
<p>Two keys are extracted from both initialization payloads, using bytes at offsets <code>8-40</code>: the key extracted from the primary payload is used as encryption key, the key extracted from the secondary payload is used as decryption key.</p>
|
||||
<p>Two IVs are extracted from both initialization payloads, using bytes at offsets <code>40-56</code>: the IV extracted from the primary payload is used as encryption IV, the IV extracted from the secondary payload is used as decryption IV.</p>
|
||||
|
|
@ -176,7 +176,9 @@ The encoding simply consist of the DC ID in two-byte signed little-endian form;
|
|||
The secret is a 16-byte string, usually distributed in its hexadecimal form along with the MTProxy host and port in <a href="/api/links#mtproxy-links">proxy deep links »</a>.</p>
|
||||
<p>Often, a 17-byte version of the secret can be found: this simply indicates that the client should use a specific MTProto transport (based on the first byte, usually it's <code>0xdd</code>, to indicate that the padded intermediate protocol should be used <code>0xdddddddd</code>; however, clients should default to the padded intermediate transport whenever an additional byte in the secret is encountered).</p>
|
||||
<p>The extracted encryption and decryption keys must be concatenated with the secret (the first byte of which should be ignored if it's the 17-byte version), and the SHA256 hash of such string should be used as encryption/decryption key.</p>
|
||||
<p>The obtained encryption and decryption key/IV pairs must then be used with <strong>AES-256-CTR</strong> to encrypt and decrypt all outgoing and incoming payloads.</p>
|
||||
<p>The obtained encryption and decryption key/IV pairs must then be used with <strong>AES-256-CTR</strong> to encrypt and decrypt all outgoing and incoming payloads.<br>
|
||||
The encryption and decryption counters must be reused for every payload, until the TCP/WS connection is closed.<br>
|
||||
In other words, reuse the same <strong>AES-256-CTR</strong> OpenSSL instance until the connection is closed. </p>
|
||||
<p>The first thing that must be encrypted using the encryption key is the initialization payload itself.
|
||||
Then bytes <code>56-64</code> of the encrypted initialization payload are substituted in the original initialization payload: this is the part that contains the constant MTProto transport protocol identifier and the DC ID (<strong>only for MTProxies</strong>).</p>
|
||||
<p>The final initialization payload must then be sent in the socket as <strong>first 64 bytes</strong> after the TCP handshake.</p>
|
||||
|
|
|
|||
|
|
@ -115,6 +115,8 @@ destroy_auth_key_ok#f660e1d4 = DestroyAuthKeyRes;
|
|||
destroy_auth_key_none#0a9f2259 = DestroyAuthKeyRes;
|
||||
destroy_auth_key_fail#ea109b13 = DestroyAuthKeyRes;
|
||||
|
||||
http_wait#9299359f max_delay:int wait_after:int max_wait:int = HttpWait;
|
||||
|
||||
---functions---
|
||||
|
||||
req_pq_multi#be7e8ef1 nonce:int128 = ResPQ;
|
||||
|
|
@ -129,8 +131,6 @@ 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;</code></pre></div>
|
||||
|
||||
</div>
|
||||
|
|
|
|||
Loading…
Reference in a new issue