OpenSource/telegram-crawler
OpenSource/telegram-crawler
1
0
Fork 0
mirror of https://github.com/MarshalX/telegram-crawler.git synced 2025-03-31 04:47:21 +02:00
Code Issues Projects Releases Packages Wiki Activity

Update content of files

Browse source
This commit is contained in:
GitHub Action 2024-07-22 19:44:52 +00:00
parent 5d07ce89e5
commit dcf2f01ede
2 changed files with 5 additions and 1 deletions
data/web/corefork.telegram.org/api
min.htmlpeers.html

2
data/web/corefork.telegram.org/api/min.html
View file

@ -43,7 +43,7 @@
<h1 id="dev_page_title">Min constructors</h1>
<div id="dev_page_content"><p>In some situations <a href="/constructor/user">user</a> and <a href="/constructor/channel">channel</a> constructors have reduced set of fields present (although <code>id</code> is always there) and <code>min</code> flag set. This is done for performance and privacy reasons. </p>
<p>When receiving said constructors, the client must first check if user or chat object without <code>min</code> flag is already present in local cache.<br>
<p>When receiving said constructors, the client must first check if user or chat object without <code>min</code> flag is already present in the <a href="/api/peers">local peer database »</a>.<br>
If it is present, then the client should merge the remote and the local object, ignoring some specific fields of the remote object as specified by the <a href="/constructor/user">user</a> and <a href="/constructor/channel">channel</a> pages. </p>
<p>Additionally, the client must store the context (similar to <a href="/api/file_reference">file references</a>) in which the user/channel was seen. Later, when the client needs to pass the user/channel as input argument (e.g. passing the <code>access_hash</code> to fetch profile, mute, ban info etc), the context is used to generate the <code>input*FromMessage</code> constructor, instead of normal <code>inputUser</code>, <code>inputChannel</code> or <code>inputPeer</code>.</p>
<ul>

4
data/web/corefork.telegram.org/api/peers.html
View file

@ -92,6 +92,10 @@
<p>Peer info must be refreshed <strong>only in the following conditions</strong> (i.e. <strong>do not</strong> refresh user info when opening the profile page, and so on...): </p>
<ul>
<li>When passively receiving an <a href="/constructor/updateUser">updateUser</a>, <a href="/constructor/updateChat">updateChat</a>, <a href="/constructor/updateChannel">updateChannel</a>, and some other updates, as specified <a href="/type/Update">here »</a></li>
<li>When fetching info about one of the following internal user IDs, if the info isn't already cached or if the cached info is <code>min</code>: 777000 (service notifications user), 1271266957 (replies bot), 1087968824 (anonymous bot), 136817688 (channel bot), 5434988373 (antispam bot).<br>
Info about these IDs may be fetched with the zero access hash even by users. </li>
<li>After invoking <a href="/method/bots.setBotInfo">bots.setBotInfo</a> after changing <code>name</code> (but <strong>not</strong> the <code>about</code> or the <code>description</code>, as changing those fields already triggers a refresh of the full info database, and with it the peer database), for the bot whose info we changed</li>
<li>After receiving a <code>CHAT_FORWARDS_RESTRICTED</code> error when forwarding messages to a chat</li>
</ul>
<p>Do not refresh peer information in any other case, to avoid overloading the server by continuously requesting changes for the same unchanged information. </p>
<p>The peer info database contains the following information: </p>