From 0838e985249dd358e6409adb8b0c54f37ecdcb84 Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Tue, 19 Oct 2021 17:06:31 +0000 Subject: [PATCH] Update content of files --- data/corefork.telegram.org/api/channel.html | 17 ++++++++++------- data/corefork.telegram.org/api/config.html | 3 ++- data/corefork.telegram.org/api/layers.html | 2 +- data/corefork.telegram.org/api/updates.html | 12 ++++++------ .../constructor/inputBotInlineMessageID.html | 8 ++++---- .../constructor/wallPaperNoFile.html | 9 +++++---- .../method/messages.exportChatInvite | 2 +- 7 files changed, 29 insertions(+), 24 deletions(-) diff --git a/data/corefork.telegram.org/api/channel.html b/data/corefork.telegram.org/api/channel.html index 4d66e83b03..cf99f14d2a 100644 --- a/data/corefork.telegram.org/api/channel.html +++ b/data/corefork.telegram.org/api/channel.html @@ -41,13 +41,16 @@
-

Channels, chats & supergroups

-

Channels are a tool for broadcasting your messages to large audiences. They can have an unlimited number of subscribers, they can be public with a permanent URL and each post in a channel has its own view counter. -Technically, they are represented by channel constructors.

-

Supergroups are a powerful tool for building communities and can support up to 200,000 members each. -Technically, supergroups are actually channels: they are represented by channel constructors, with the megagroup flag set to true.

-

Channels and supergroup can be created using the channels.createChannel method, by setting the appropriate broadcast or megagroup flags. -Supergroups can also be assigned a geo_point to become geochats.

+

Channels, chats, supergroups & gigagroups

+

Channels are a tool for broadcasting your messages to large audiences. They can have an unlimited number of subscribers, they can be public with a permanent URL and each post in a channel has its own view counter.
+Technically, they are represented by channel constructors.

+

Supergroups are a powerful tool for building communities and can support up to 200,000 members each.
+Technically, supergroups are actually channels: they are represented by channel constructors, with the megagroup flag set to true.

+

Gigagroups are something inbetween a channel and a supergroup.
+An admin, when prompted by the API using suggestions », can convert a megagroup into a gigagroup using channels.convertToGigagroup (one way only). After that, only admins will be able to write in the group (like when send_messages rights are disabled for all group participants by default), but the participant limit is removed and the group can become much bigger than a supergroup (e.g. >200,000 currently).
+Also, one can't invite people into gigagroups and participants of voice chats in gigagroups are muted by default.

+

Channels and supergroup can be created using the channels.createChannel method, by setting the appropriate broadcast or megagroup flags.
+Supergroups can also be assigned a geo_point to become geochats.

In previous versions of telegram, only normal groups (represented by chat constructors) could be created using messages.createChat: these groups have fewer features, and can only have 200 members at max.

Migration

To upgrade a legacy group to a supergroup, messages.migrateChat can be used. diff --git a/data/corefork.telegram.org/api/config.html b/data/corefork.telegram.org/api/config.html index d8ca119201..8543dcf884 100644 --- a/data/corefork.telegram.org/api/config.html +++ b/data/corefork.telegram.org/api/config.html @@ -76,6 +76,8 @@ While help.getConfig returns MTProto-specif

  • emojies_sounds - A map of soundbites to be played when the user clicks on the specified animated emoji; the file reference field should be base64-decoded before downloading the file (map of file IDs, with emoji string keys)
  • gif_search_branding - Specifies the name of the service providing GIF search through gif_search_username (string)
  • gif_search_emojies - Specifies a list of emojies that should be suggested as search term in a bar above the GIF search box (array of string emojis)
    • +
  • stickers_emoji_suggest_only_api - Specifies that the app should not display local sticker suggestions for emojis at all and just use the result of messages.getStickers (bool)
    • +
  • stickers_emoji_cache_time - Specifies the validity period of the local cache of messages.getStickers, also relevant when generating the pagination hash when invoking the method. (int)
  • qr_login_camera - Whether the Settings->Devices menu should show an option to scan a QR login code (boolean)
  • qr_login_code - Whether the login screen should show a QR code login option, possibly as default login method (string, "disabled", "primary" or "secondary")
  • dialog_filters_enabled - Whether clients should show an option for managing dialog filters AKA folders (boolean)
    • @@ -188,7 +190,6 @@ While help.getConfig returns MTProto-specif ], "stickers_emoji_suggest_only_api": false, "stickers_emoji_cache_time": 86400, - "groupcall_video_participants_max": 1000, "qr_login_camera": false, "qr_login_code": "disabled", "dialog_filters_enabled": true, diff --git a/data/corefork.telegram.org/api/layers.html b/data/corefork.telegram.org/api/layers.html index 0e747c68f8..4f57585caf 100644 --- a/data/corefork.telegram.org/api/layers.html +++ b/data/corefork.telegram.org/api/layers.html @@ -1335,7 +1335,7 @@ Notice that all PINNED_* baseThemeTinted - Tinted theme
  • Added baseThemeArctic - Arctic theme
  • Added inputWallPaperNoFile - Wallpaper with no file access hash, used for example when deleting (unsave=true) wallpapers using account.saveWallPaper, specifying just the wallpaper ID.
    • -
  • Added wallPaperNoFile - No file wallpaper
    • +
  • Added wallPaperNoFile - Wallpaper with no file access hash, used for example when deleting (unsave=true) wallpapers using account.saveWallPaper, specifying just the wallpaper ID.
  • Added inputThemeSettings - Theme settings
  • Added themeSettings - Theme settings
  • Added webPageAttributeTheme - Page theme
    • diff --git a/data/corefork.telegram.org/api/updates.html b/data/corefork.telegram.org/api/updates.html index 85553f140e..d257074053 100644 --- a/data/corefork.telegram.org/api/updates.html +++ b/data/corefork.telegram.org/api/updates.html @@ -64,18 +64,18 @@

    The updateShortMessage, updateShortSentMessage and updateShortChatMessage constructors are redundant but help significantly reduce the transmitted message size for 90% of the updates. They should be transformed to updateShort upon receiving.

    Two remaining constructors updates and updatesCombined are part of the Updates sequence. Both of them have seq attribute, which indicates the remote Updates state after the generation of the Updates, and seq_start indicates the remote Updates state after the first of the Updates in the packet is generated. For updates, seq_start attribute is omitted, because it is assumed that it is always equal to seq.

    Message-related event sequences

    -

    Each event related to a message box (message created, message edited, message deleted, etc) is identified by a unique autoincremented pts (or qts in case of secret chats).

    +

    Each event related to a message box (message created, message edited, message deleted, etc) is identified by a unique autoincremented pts, or qts in case of secret chat updates, certain bot updates, etc.

    Each message box can be considered as some server-side DB table that stores messages and events associated with them. All boxes are completely independent, and each pts sequence is tied to just one box (see below).

    Update object may contain info about multiple events (for example, updateDeleteMessages). That's why all single updates might have pts_count parameter indicating the number of events contained in the received update (with some exceptions, in this case, the pts_count is considered to be 0).

    Each channel and supergroup has its message box and its event sequence as a result; private chats and legacy groups of one user have another common event sequence. -User's Secret chats have yet another common secret event sequence.

    +Secret chats, certain bot events and other kinds of updates have yet another common secondary event sequence.

    To recap, the client has to take care of the integrity of the following sequences to properly handle updates: