diff --git a/data/web/corefork.telegram.org/api/peers.html b/data/web/corefork.telegram.org/api/peers.html index 13f406ea13..5181edf879 100644 --- a/data/web/corefork.telegram.org/api/peers.html +++ b/data/web/corefork.telegram.org/api/peers.html @@ -111,7 +111,13 @@ 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 receiving a CHAT_FORWARDS_RESTRICTED error when forwarding messages from a chat, to refresh info about the source chat (i.e. the fact that we received this error means that the client didn't locally prevent the user from forwarding a message from the protected chat, because the locally cached channel.noforwards/chat.noforwards flag is out of date).

    +
  • +
  • +

    After receiving a CHAT_GUEST_SEND_FORBIDDEN error when sending messages to a discussion group, to refresh info about the discussion group (i.e. the fact that we received this error means that the client didn't locally prevent the non-member user from sending a message to a discussion group where only members can send messages, because the locally cached channel.join_to_send flag is out of date).

    +
  • +
  • +

    After receiving a USER_NOT_PARTICIPANT error when calling channels.leaveChannel, to refresh info about the channel/supergroup (i.e. the fact that we received this error means that the client tried to leave a channel/supergroup they're not a member of, and the client didn't try to prevent this locally because its channel constructor is out of date).

  • After invoking the following methods (both if the call succeds and after receiving a USERNAME_NOT_MODIFIED error, which is also a success):

    @@ -123,7 +129,7 @@ Info about these IDs may be fetched with the zero access hash even by users. Info should only be manually refreshed with a call to users.getUsers, channels.getChannels if the new username order/active username cannot be applied locally (i.e. the method call successfully set as active some username that isn't associated to the peer 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 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.

    +

    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: