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
a991708b01
commit
6b0aa85955
11 changed files with 28 additions and 50 deletions
|
|
@ -166,6 +166,8 @@
|
|||
<h3><a class="anchor" href="#type" id="type" name="type"><i class="anchor-icon"></i></a>Type</h3>
|
||||
<p><a href="/type/Authorization">Authorization</a></p>
|
||||
<h3><a class="anchor" href="#related-pages" id="related-pages" name="related-pages"><i class="anchor-icon"></i></a>Related pages</h3>
|
||||
<h4><a class="anchor" href="#user-authorization" id="user-authorization" name="user-authorization"><i class="anchor-icon"></i></a><a href="/api/auth">User Authorization</a></h4>
|
||||
<p>How to register a user's phone to start using the API.</p>
|
||||
<h4><a class="anchor" href="#creating-your-telegram-application" id="creating-your-telegram-application" name="creating-your-telegram-application"><i class="anchor-icon"></i></a><a href="/api/obtaining_api_id">Creating your Telegram Application</a></h4>
|
||||
<p>How to get your application identifier and create a new Telegram app.</p></div>
|
||||
|
||||
|
|
|
|||
|
|
@ -4,30 +4,10 @@
|
|||
<meta charset="utf-8">
|
||||
<title>sponsoredWebPage</title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta property="description" content="Represents a sponsored website.
|
||||
Parameters
|
||||
Name
|
||||
Type
|
||||
Description
|
||||
flags
|
||||
#
|
||||
Flags, see TL conditional fields
|
||||
url
|
||||
string
|
||||
Web…">
|
||||
<meta property="description" content="Represents a sponsored website.">
|
||||
<meta property="og:title" content="sponsoredWebPage">
|
||||
<meta property="og:image" content="">
|
||||
<meta property="og:description" content="Represents a sponsored website.
|
||||
Parameters
|
||||
Name
|
||||
Type
|
||||
Description
|
||||
flags
|
||||
#
|
||||
Flags, see TL conditional fields
|
||||
url
|
||||
string
|
||||
Web…">
|
||||
<meta property="og:description" content="Represents a sponsored website.">
|
||||
<link rel="icon" type="image/svg+xml" href="/img/website_icon.svg?4">
|
||||
<link rel="apple-touch-icon" sizes="180x180" href="/img/apple-touch-icon.png">
|
||||
<link rel="icon" type="image/png" sizes="32x32" href="/img/favicon-32x32.png">
|
||||
|
|
|
|||
|
|
@ -101,6 +101,8 @@
|
|||
<h3><a class="anchor" href="#type" id="type" name="type"><i class="anchor-icon"></i></a>Type</h3>
|
||||
<p><a href="/type/Update">Update</a></p>
|
||||
<h3><a class="anchor" href="#related-pages" id="related-pages" name="related-pages"><i class="anchor-icon"></i></a>Related pages</h3>
|
||||
<h4><a class="anchor" href="#user-authorization" id="user-authorization" name="user-authorization"><i class="anchor-icon"></i></a><a href="/api/auth">User Authorization</a></h4>
|
||||
<p>How to register a user's phone to start using the API.</p>
|
||||
<h4><a class="anchor" href="#pagination-in-the-api" id="pagination-in-the-api" name="pagination-in-the-api"><i class="anchor-icon"></i></a><a href="/api/offsets">Pagination in the API</a></h4>
|
||||
<p>How to fetch results from large lists of objects.</p></div>
|
||||
|
||||
|
|
|
|||
|
|
@ -4,10 +4,10 @@
|
|||
<meta charset="utf-8">
|
||||
<title>updates.channelDifferenceTooLong</title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta property="description" content="The provided pts + limit < remote pts. Simply, there are too many updates to be fetched (more than limit), the client has to resolve the update gap in one of the following ways (assuming the existence of a persistent database to locally store messages):">
|
||||
<meta property="description" content="The provided pts + limit < remote pts. Simply, there are too many updates to be fetched (more than limit), the client has to resolve the update gap in one of the following ways (assuming the existence of a persistent database to locally store messages): 1. Delete all known messages in the chat, begin from scratch by refetching all messages manually with messages.getHistory. It is easy to implement, but suddenly disappearing messages look awful to the user. 2. Save all messages loaded in the memory until application restart, but delete all messages from the database. Messages left in the memory must be lazily updated using calls to messages.getHistory. It will look much smoother to the user, they will need to redownload messages only after client restart. Unsynchronized messages left in memory shouldn't be saved to the database, results of messages.getHistory and messages.getMessages must be used to update the state of deleted and edited messages left in the memory. 3. Save all messages loaded in the memory and stored in the database without saving that some messages form continuous ranges. Messages in the database will be excluded when paginating through or searching the local message history after application restart and will be available only through individual message queries. Every message should still be checked using messages.getHistory. It has more disadvantages over 2) than advantages. 4. Save all messages with saving all data about continuous message ranges. Messages from the database may be used when paginating through or searching the local message history. The messages should still be lazily checked using messages.getHistory, but they are still available offline. It is the best way for gaps support, but it is pretty hard to implement correctly. It should be also noted that some messages like live location messages shouldn't be deleted.">
|
||||
<meta property="og:title" content="updates.channelDifferenceTooLong">
|
||||
<meta property="og:image" content="">
|
||||
<meta property="og:description" content="The provided pts + limit < remote pts. Simply, there are too many updates to be fetched (more than limit), the client has to resolve the update gap in one of the following ways (assuming the existence of a persistent database to locally store messages):">
|
||||
<meta property="og:description" content="The provided pts + limit < remote pts. Simply, there are too many updates to be fetched (more than limit), the client has to resolve the update gap in one of the following ways (assuming the existence of a persistent database to locally store messages): 1. Delete all known messages in the chat, begin from scratch by refetching all messages manually with messages.getHistory. It is easy to implement, but suddenly disappearing messages look awful to the user. 2. Save all messages loaded in the memory until application restart, but delete all messages from the database. Messages left in the memory must be lazily updated using calls to messages.getHistory. It will look much smoother to the user, they will need to redownload messages only after client restart. Unsynchronized messages left in memory shouldn't be saved to the database, results of messages.getHistory and messages.getMessages must be used to update the state of deleted and edited messages left in the memory. 3. Save all messages loaded in the memory and stored in the database without saving that some messages form continuous ranges. Messages in the database will be excluded when paginating through or searching the local message history after application restart and will be available only through individual message queries. Every message should still be checked using messages.getHistory. It has more disadvantages over 2) than advantages. 4. Save all messages with saving all data about continuous message ranges. Messages from the database may be used when paginating through or searching the local message history. The messages should still be lazily checked using messages.getHistory, but they are still available offline. It is the best way for gaps support, but it is pretty hard to implement correctly. It should be also noted that some messages like live location messages shouldn't be deleted.">
|
||||
<link rel="icon" type="image/svg+xml" href="/img/website_icon.svg?4">
|
||||
<link rel="apple-touch-icon" sizes="180x180" href="/img/apple-touch-icon.png">
|
||||
<link rel="icon" type="image/png" sizes="32x32" href="/img/favicon-32x32.png">
|
||||
|
|
|
|||
|
|
@ -116,6 +116,8 @@
|
|||
</tbody>
|
||||
</table>
|
||||
<h3><a class="anchor" href="#related-pages" id="related-pages" name="related-pages"><i class="anchor-icon"></i></a>Related pages</h3>
|
||||
<h4><a class="anchor" href="#user-authorization" id="user-authorization" name="user-authorization"><i class="anchor-icon"></i></a><a href="/api/auth">User Authorization</a></h4>
|
||||
<p>How to register a user's phone to start using the API.</p>
|
||||
<h4><a class="anchor" href="#authorization" id="authorization" name="authorization"><i class="anchor-icon"></i></a><a href="/constructor/authorization">authorization</a></h4>
|
||||
<p>Logged-in session</p>
|
||||
<h4><a class="anchor" href="#accountgetauthorizations" id="accountgetauthorizations" name="accountgetauthorizations"><i class="anchor-icon"></i></a><a href="/method/account.getAuthorizations">account.getAuthorizations</a></h4>
|
||||
|
|
|
|||
|
|
@ -95,11 +95,6 @@
|
|||
<tbody>
|
||||
<tr>
|
||||
<td>400</td>
|
||||
<td>EMAIL_UNCONFIRMED_%d</td>
|
||||
<td>The provided email isn't confirmed, %d is the length of the verification code that was just sent to the email: use <a href="/method/account.verifyEmail">account.verifyEmail</a> to enter the received verification code and enable the recovery email.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>400</td>
|
||||
<td>EMAIL_INVALID</td>
|
||||
<td>The specified email is invalid.</td>
|
||||
</tr>
|
||||
|
|
@ -110,6 +105,11 @@
|
|||
</tr>
|
||||
<tr>
|
||||
<td>400</td>
|
||||
<td>EMAIL_UNCONFIRMED_%d</td>
|
||||
<td>The provided email isn't confirmed, %d is the length of the verification code that was just sent to the email: use <a href="/method/account.verifyEmail">account.verifyEmail</a> to enter the received verification code and enable the recovery email.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>400</td>
|
||||
<td>NEW_SALT_INVALID</td>
|
||||
<td>The new salt is invalid.</td>
|
||||
</tr>
|
||||
|
|
|
|||
|
|
@ -329,16 +329,16 @@
|
|||
<td>You can't send messages as the specified peer.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>420</td>
|
||||
<td>SLOWMODE_WAIT_%d</td>
|
||||
<td>Slowmode is enabled in this chat: wait %d seconds before sending another message to this chat.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>400</td>
|
||||
<td>SLOWMODE_MULTI_MSGS_DISABLED</td>
|
||||
<td>Slowmode is enabled, you cannot forward multiple messages to this group.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>420</td>
|
||||
<td>SLOWMODE_WAIT_%d</td>
|
||||
<td>Slowmode is enabled in this chat: wait %d seconds before sending another message to this chat.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>406</td>
|
||||
<td>TOPIC_CLOSED</td>
|
||||
<td>This topic was closed, you can't send messages to it anymore.</td>
|
||||
|
|
|
|||
|
|
@ -145,6 +145,8 @@
|
|||
<p>Telegram users and channels can easily post and view stories through the API.</p>
|
||||
<h4><a class="anchor" href="#styled-text-with-message-entities" id="styled-text-with-message-entities" name="styled-text-with-message-entities"><i class="anchor-icon"></i></a><a href="/api/entities">Styled text with message entities</a></h4>
|
||||
<p>How to create styled text with message entities</p>
|
||||
<h4><a class="anchor" href="#client-configuration" id="client-configuration" name="client-configuration"><i class="anchor-icon"></i></a><a href="/api/config">Client configuration</a></h4>
|
||||
<p>The MTProto API has multiple configuration parameters that can be fetched with the appropriate methods.</p>
|
||||
<h4><a class="anchor" href="#privacy" id="privacy" name="privacy"><i class="anchor-icon"></i></a><a href="/api/privacy">Privacy</a></h4>
|
||||
<p>Telegram allows users to specify granular privacy settings, choosing which users can or can't interact with them in certain ways.</p></div>
|
||||
|
||||
|
|
|
|||
|
|
@ -200,10 +200,10 @@
|
|||
<p>Telegram users and channels can easily post and view stories through the API.</p>
|
||||
<h4><a class="anchor" href="#styled-text-with-message-entities" id="styled-text-with-message-entities" name="styled-text-with-message-entities"><i class="anchor-icon"></i></a><a href="/api/entities">Styled text with message entities</a></h4>
|
||||
<p>How to create styled text with message entities</p>
|
||||
<h4><a class="anchor" href="#privacy" id="privacy" name="privacy"><i class="anchor-icon"></i></a><a href="/api/privacy">Privacy</a></h4>
|
||||
<p>Telegram allows users to specify granular privacy settings, choosing which users can or can't interact with them in certain ways.</p>
|
||||
<h4><a class="anchor" href="#client-configuration" id="client-configuration" name="client-configuration"><i class="anchor-icon"></i></a><a href="/api/config">Client configuration</a></h4>
|
||||
<p>The MTProto API has multiple configuration parameters that can be fetched with the appropriate methods.</p>
|
||||
<h4><a class="anchor" href="#privacy" id="privacy" name="privacy"><i class="anchor-icon"></i></a><a href="/api/privacy">Privacy</a></h4>
|
||||
<p>Telegram allows users to specify granular privacy settings, choosing which users can or can't interact with them in certain ways.</p>
|
||||
<h4><a class="anchor" href="#telegram-premium" id="telegram-premium" name="telegram-premium"><i class="anchor-icon"></i></a><a href="/api/premium">Telegram Premium</a></h4>
|
||||
<p>Telegram Premium is an optional subscription service that unlocks additional exclusive client-side and API-side features, while helping support the development of the app.</p></div>
|
||||
|
||||
|
|
|
|||
|
|
@ -4,20 +4,10 @@
|
|||
<meta charset="utf-8">
|
||||
<title>SponsoredWebPage</title>
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta property="description" content="Represents a sponsored website.
|
||||
Constructors
|
||||
Constructor
|
||||
Description
|
||||
sponsoredWebPage
|
||||
">
|
||||
<meta property="description" content="Represents a sponsored website.">
|
||||
<meta property="og:title" content="SponsoredWebPage">
|
||||
<meta property="og:image" content="">
|
||||
<meta property="og:description" content="Represents a sponsored website.
|
||||
Constructors
|
||||
Constructor
|
||||
Description
|
||||
sponsoredWebPage
|
||||
">
|
||||
<meta property="og:description" content="Represents a sponsored website.">
|
||||
<link rel="icon" type="image/svg+xml" href="/img/website_icon.svg?4">
|
||||
<link rel="apple-touch-icon" sizes="180x180" href="/img/apple-touch-icon.png">
|
||||
<link rel="icon" type="image/png" sizes="32x32" href="/img/favicon-32x32.png">
|
||||
|
|
@ -77,7 +67,7 @@ sponsoredWebPage
|
|||
<tbody>
|
||||
<tr>
|
||||
<td><a href="/constructor/sponsoredWebPage">sponsoredWebPage</a></td>
|
||||
<td> </td>
|
||||
<td>Represents a sponsored website.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table></div>
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@
|
|||
</tr>
|
||||
<tr>
|
||||
<td><a href="/constructor/updates.channelDifferenceTooLong">updates.channelDifferenceTooLong</a></td>
|
||||
<td>The provided <code>pts + limit < remote pts</code>. Simply, there are too many updates to be fetched (more than <code>limit</code>), the client has to resolve the update gap in one of the following ways (assuming the existence of a persistent database to locally store messages):<br><br>1. Delete all known messages in the chat, begin from scratch by refetching all messages manually with <a href="/method/messages.getHistory">messages.getHistory</a>. It is easy to implement, but suddenly disappearing messages look awful to the user.<br>2. Save all messages loaded in the memory until application restart, but delete all messages from the database. Messages left in the memory must be lazily updated using calls to <a href="/method/messages.getHistory">messages.getHistory</a>. <br> It will look much smoother to the user, they will need to redownload messages only after client restart. <br> Unsynchronized messages left in memory shouldn't be saved to the database, results of <a href="/method/messages.getHistory">messages.getHistory</a> and <a href="/method/messages.getMessages">messages.getMessages</a> must be used to update the state of deleted and edited messages left in the memory.<br>3. Save all messages loaded in the memory and stored in the database without saving that some messages form continuous ranges. <br> Messages in the database will be excluded when paginating through or searching the local message history after application restart and will be available only through individual message queries. <br> Every message should still be checked using <a href="/method/messages.getHistory">messages.getHistory</a>. <br> It has more disadvantages over 2) than advantages.<br>4. Save all messages with saving all data about continuous message ranges. <br> Messages from the database may be used when paginating through or searching the local message history. <br> The messages should still be lazily checked using <a href="/method/messages.getHistory">messages.getHistory</a>, but they are still available offline. <br> It is the best way for gaps support, but it is pretty hard to implement correctly.<br><br>It should be also noted that some messages like live location messages shouldn't be deleted.</td>
|
||||
<td>The provided <code>pts + limit < remote pts</code>. Simply, there are too many updates to be fetched (more than <code>limit</code>), the client has to resolve the update gap in one of the following ways (assuming the existence of a persistent database to locally store messages):<br><br>1. Delete all known messages in the chat, begin from scratch by refetching all messages manually with <a href="/method/messages.getHistory">messages.getHistory</a>. It is easy to implement, but suddenly disappearing messages look awful to the user.<br>2. Save all messages loaded in the memory until application restart, but delete all messages from the database. Messages left in the memory must be lazily updated using calls to <a href="/method/messages.getHistory">messages.getHistory</a>. <br> It will look much smoother to the user, they will need to redownload messages only after client restart. <br> Unsynchronized messages left in memory shouldn't be saved to the database, results of <a href="/method/messages.getHistory">messages.getHistory</a> and <a href="/method/messages.getMessages">messages.getMessages</a> must be used to update the state of deleted and edited messages left in the memory.<br>3. Save all messages loaded in the memory and stored in the database without saving that some messages form continuous ranges. <br> Messages in the database will be excluded when paginating through or searching the local message history after application restart and will be available only through individual message queries. <br> Every message should still be checked using <a href="/method/messages.getHistory">messages.getHistory</a>. <br> It has more disadvantages over 2) than advantages.<br>4. Save all messages with saving all data about continuous message ranges. <br> Messages from the database may be used when paginating through or searching the local message history. <br> The messages should still be lazily checked using <a href="/method/messages.getHistory">messages.getHistory</a>, but they are still available offline. <br> It is the best way for gaps support, but it is pretty hard to implement correctly.<br><br>It should be also noted that some messages like live location messages shouldn't be deleted.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><a href="/constructor/updates.channelDifference">updates.channelDifference</a></td>
|
||||
|
|
|
|||
Loading…
Reference in a new issue