From e867e326b540a4eaecd18889028c1233d236977d Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Mon, 5 Aug 2024 13:51:43 +0000 Subject: [PATCH] Update content of files --- data/web/corefork.telegram.org/api/peers.html | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/data/web/corefork.telegram.org/api/peers.html b/data/web/corefork.telegram.org/api/peers.html index 31cfdddc73..72deede97a 100644 --- a/data/web/corefork.telegram.org/api/peers.html +++ b/data/web/corefork.telegram.org/api/peers.html @@ -244,19 +244,18 @@ See the documentation in the user and chatBannedRights.until_date, the full cache of the chat/supergroup should be refresh for the admin at until_date. -

Unlike the invalidation condition list for the non-full peer database, the above list is non-exhaustive, so clients may also choose to re-fetch the full info in some other conditions to make sure the info is always up to date (for example when opening a profile page, or when receiving some RPC errors in other cases).

-

Also see this section on quality of life checks ».

+

Unlike the invalidation condition list for the non-full peer database, the above list is non-exhaustive, so clients may also choose to re-fetch the full info in some other conditions to make sure the info is always up to date (for example when opening a profile page, or when receiving some RPC errors in other cases), see this section on quality of life checks » for more info.

Quality of life checks

-

Note the following: peer information is also used for quality-of-life improvements, i.e. to directly prevent the user from doing an operation that is denied by the peer information.

+

Note the following: peer information is also used for quality-of-life improvements, i.e. to directly prevent the user from doing an operation that is denied by the peer information, instead of allowing the operation and then showing an error.

These improvements should be implemented by advanced clients, but they are entirely optional, as the server will always prevent the user from doing illegal operations, by emitting an appropriate RPC error, and sometimes it is still possible to make an illegal operation, even if a local check is implemented (see below).

Instead of (or along with) preventing users from doing illegal operations on the client side, clients should always provide localized versions of errors returned by the server (as listed in the JSON file downloadable from the RPC error page), to inform the user as to why an attempted operation has failed.

-

In other words, if the client didn't prevent the method call locally because:

+

In other words, if the client didn't prevent the failed method call locally because: