Update content of files

data/web/corefork.telegram.org/api/updates.html

@@ -65,7 +65,7 @@
 <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 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>
+<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>, the <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 <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.
@@ -88,7 +88,7 @@ Secret chats, certain bot events and other kinds of updates have yet another <em
 </ul>
 <h3><a class="anchor" href="#fetching-state" id="fetching-state" name="fetching-state"><i class="anchor-icon"></i></a>Fetching state</h3>
 <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).
+When the user logs in for the first time, a 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 <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>
@@ -99,9 +99,11 @@ The common update state can also be fetched from <a href="/constructor/updates.d
 <p>After message box updates are handled, if there are any other updates remaining the client needs to handle them with respect to <code>seq</code>. <a href="#seq-checking-and-applying">Details below »</a></p>
 <h4><a class="anchor" href="#pts-checking-and-applying" id="pts-checking-and-applying" name="pts-checking-and-applying"><i class="anchor-icon"></i></a><code>pts</code>: checking and applying</h4>
 <p>Here, <code>local_pts</code> will be the local state, <code>pts</code> will be the remote state, <code>pts_count</code> will be the number of events in the update.</p>
-<p>If <code>local_pts + pts_count === pts</code>, the update can be applied.
-If <code>local_pts + pts_count &gt; pts</code>, the update was already applied, and must be ignored.
-If <code>local_pts + pts_count &lt; pts</code>, there's an update gap that must be <a href="#recovering-gaps">filled</a>.</p>
+<ul>
+<li>If <code>local_pts + pts_count === pts</code>, the update can be applied.</li>
+<li>If <code>local_pts + pts_count &gt; pts</code>, the update was already applied, and must be ignored.</li>
+<li>If <code>local_pts + pts_count &lt; pts</code>, there's an update gap that must be <a href="#recovering-gaps">filled</a>.</li>
+</ul>
 <p>For example, let's assume the client has the following local state for the channel <code>123456789</code>:</p>
 <pre><code>local_pts = 131</code></pre>
 <p>Now let's assume an <a href="/constructor/updateNewChannelMessage">updateNewChannelMessage</a> from channel <code>123456789</code> is received with <code>pts = 132</code> and <code>pts_count=1</code>.
@@ -118,12 +120,15 @@ Since <code>local_pts + pts_count &gt; pts</code> (<code>133 &gt; 132</code>), t
 <p>Now let's assume an <a href="/constructor/updateDeleteChannelMessages">updateDeleteChannelMessages</a> from channel <code>123456789</code> is received with <code>pts = 140</code> and <code>pts_count=5</code>.
 Since <code>local_pts + pts_count &lt; pts</code> (<code>137 &lt; 140</code>), this means that updates were missed, and the gap must be recovered.</p>
 <h5><a class="anchor" href="#secret-chats--bots" id="secret-chats--bots" name="secret-chats--bots"><i class="anchor-icon"></i></a>Secret chats &amp; bots</h5>
-<p>The whole process is very similar for secret chats and certain bot updates, but there is <code>qts</code> instead of <code>pts</code>, and events are never grouped, so it's assumed that <code>qts_count</code> is always equal to 1.</p>
+<p>The whole process is very similar for secret chats and certain bot updates, but there is a <code>qts</code> instead of <code>pts</code>, and events are never grouped, so it's assumed that <code>qts_count</code> is always equal to 1.</p>
 <h4><a class="anchor" href="#seq-checking-and-applying" id="seq-checking-and-applying" name="seq-checking-and-applying"><i class="anchor-icon"></i></a><code>seq</code>: checking and applying</h4>
-<p>On top level when handling received <a href="/constructor/updates">updates</a> and <a href="/constructor/updatesCombined">updatesCombined</a> there are three possible cases:
-If <code>local_seq + 1 === seq_start</code>, the updates can be applied.
-If <code>local_seq + 1 &gt; seq_start</code>, the updates were already applied, and must be ignored.
-If <code>local_seq + 1 &lt; seq_start</code>, there's an updates gap that must be <a href="#recovering-gaps">filled</a> (updates.getDifference must be used as with common and secret event sequences).</p>
+<p>On the top level when handling received <a href="/constructor/updates">updates</a> and <a href="/constructor/updatesCombined">updatesCombined</a> there are four possible cases:</p>
+<ul>
+<li>If <code>seq_start === 0</code>, the updates can be applied: this is a special case for updates that aren't ordered and should just be applied immediately.</li>
+<li>If <code>local_seq + 1 === seq_start</code>, the updates can be applied.</li>
+<li>If <code>local_seq + 1 &gt; seq_start</code>, the updates were already applied, and must be ignored.</li>
+<li>If <code>local_seq + 1 &lt; seq_start</code>, there's an updates gap that must be <a href="#recovering-gaps">filled</a> (updates.getDifference must be used as with common and secret event sequences).</li>
+</ul>
 <p>If the updates were applied, local <em>Updates state</em> must be updated with <code>seq</code> and <code>date</code> from the constructor.</p>
 <p>For all the other <a href="/type/Updates">Updates</a> type constructors there is no need to check <code>seq</code> or change a local state.</p>
 <h3><a class="anchor" href="#recovering-gaps" id="recovering-gaps" name="recovering-gaps"><i class="anchor-icon"></i></a>Recovering gaps</h3>