The peer info database needs to be updated every time a new constructor of type user, chat and channel (and their forbidden counterparts, used for peers that the user can't access, but can view basic info about) is received.
These constructors are received when interacting with the API (i.e. in common chats, through the search function, username resolution, temporary profile links, and so on...).
Unless specified otherwise (see the constructor pages for the special cases), when updating the local peer database, all fields from the newly received constructor take priority over the old constructor cached locally (including by removing fields that aren't set in the new constructor).
-Information about already cached peers must be refreshed in certain conditions using the bulked users.getUsers, messages.getChats, channels.getChannels methods, all requiring the previously cached access_hash (read on for more info).
Peer info must be refreshed only in the following conditions (i.e. do not refresh user info when opening the profile page, and so on...):
+Some updates should trigger an update of a small subset of the info contained in the peer database:
min: 777000 (service notifications user), 1271266957 (replies bot), 1087968824 (anonymous bot), 136817688 (channel bot), 5434988373 (antispam bot).name (but not the about or the description, 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 changedCHAT_FORWARDS_RESTRICTED error when forwarding messages to a chatstatusfirst_name/last_name/username/usernamesemoji_statusparticipants_count, chatFull.participants. participants_count, chatFull.participants. hidden_prehistoryInformation about already cached peers must be refreshed manually in certain conditions using the bulked users.getUsers, messages.getChats, channels.getChannels methods, all requiring the previously cached access_hash (read on for more info).
Peer info must be manually refreshed with a method call to the above methods only in the following conditions (i.e. do not refresh user info when opening the profile page, and so on...):
+When passively receiving an updateUser, updateChat, updateChannel, and some other updates, as specified here »
+When fetching info about one of the following internal user IDs, if the info isn't already cached or if the cached info is min: 777000 (service notifications user), 1271266957 (replies bot), 1087968824 (anonymous bot), 136817688 (channel bot), 5434988373 (antispam bot).
+Info about these IDs may be fetched with the zero access hash even by users.
After invoking bots.setBotInfo after changing name (but not the about or the description, 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
After receiving a CHAT_FORWARDS_RESTRICTED error when forwarding messages from a chat, to refresh info about the source chat.
After invoking the following methods (both if the call succeds and after receiving a USERNAME_NOT_MODIFIED error, which is also a success):
Info should only be manually refreshed with a call to users.getUsers if the new username order/active username cannot be applied locally (i.e. the methods successfully set as active some username that isn't associated to the user in our local cache, and so on), otherwise the username and usernames fields of the peer info database should be updated locally, using the info that was passed to to the toggle/reorder methods by the user.
Do not refresh peer information in any other case, to avoid overloading the server by continuously requesting changes for the same unchanged information.
The peer info database contains the following information:
diff --git a/data/web/corefork.telegram.org/constructor/channel.html b/data/web/corefork.telegram.org/constructor/channel.html index e394dbdcb4..4c66e69269 100644 --- a/data/web/corefork.telegram.org/constructor/channel.html +++ b/data/web/corefork.telegram.org/constructor/channel.html @@ -209,7 +209,7 @@min flag is not set OR min flag is set AND min flag of the locally cached user entry is set.min flag is not set OR min flag is set AND min flag of the locally cached user entry is set.