diff --git a/data/web/corefork.telegram.org/api/peers.html b/data/web/corefork.telegram.org/api/peers.html index 5181edf879..f21d34531b 100644 --- a/data/web/corefork.telegram.org/api/peers.html +++ b/data/web/corefork.telegram.org/api/peers.html @@ -85,18 +85,36 @@ users.getUsers#d91a548 id:Vector<InputUser> = Vector<User>; messages.getChats#49e9528f id:Vector<long> = messages.Chats; channels.getChannels#a7f6bbb id:Vector<InputChannel> = messages.Chats; +

The peer info database contains the following information:

+ +

And it must be populated as follows:

+ +

Saving constructors

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).

+

Handling certain updates

Some updates should trigger an update of a small subset of the info contained in the peer database:

+

Manual refreshes

Information 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...):

Do not manually 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:

-

Peer ID

The peer id is a unique 64-bit ID used to identify a specific user, chat or channel.

This field should be used as primary key in the channel, chat and user databases.

@@ -181,11 +193,13 @@ As specified in the constructor docs, some of the fields must not be overwritten messages.getFullChat#aeb00b34 chat_id:long = messages.ChatFull; channels.getFullChannel#8736a09 channel:InputChannel = messages.ChatFull;

The full info database contains info from the userFull, chatFull and channelFull constructors.

-

To populate the full info database for a peer, manually invoke users.getFullUser, messages.getFullChat, channels.getFullChannel, all requiring the previously cached access_hash » when the client needs to use one of the full info fields.

-

Full info must be manually refreshed and stored to the database 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...):

+

To populate the full info database for a peer, invoke users.getFullUser, messages.getFullChat, channels.getFullChannel, all requiring the previously cached access_hash ».

+

Populate the full info database only when the client needs some data from a full constructor, and there is no entry already in the database.

+

Full peer info stored to the database must be refreshed only in the following conditions (i.e. do not refresh user info when opening the profile page, or every time the entry is accessed, do not use TTLs to expire the database entries, and so on...):

Do not refresh full peer information in any other case, to avoid overloading the server by continuously requesting changes for the same unchanged information.