Incoming and outgoing encrypted files can be forwarded to other secret chats using the constructor inputEncryptedFile to avoid saving the same content on the server twice.
Secret chats are associated with specific devices (or rather with authorization keys), not users. A conventional message box, which uses pts to describe the client’s status, is not suitable, because it is designed for long-term message storage and message access from different devices.
+Secret chats are associated with specific devices (or rather with authorization keys), not users. A conventional message box, which uses pts to describe the client’s status, is not suitable, because it is designed for long-term message storage and message access from different devices.
An additional temporary message queue is introduced as a solution to this problem. When an update regarding a message from a secret chat is sent, a new value of qts is sent, which helps reconstruct the difference if there has been a long break in the connection or in case of loss of an update.
As the number of events increases, the value of qts increases monotonically (not always by 1). The initial value may not (and will not) be equal to 0.
The fact that events from the temporary queue have been received and stored by the client is acknowledged explicitly by a call to the messages.receivedQueue method or implicitly by a call to updates.getDifference (the value of qts passed, not the final state). All messages acknowledged as delivered by the client, as well as any messages older than 7 days, may (and will) be deleted from the server.
diff --git a/data/corefork.telegram.org/api/layers.html b/data/corefork.telegram.org/api/layers.html index 4f57585caf..9dabb47608 100644 --- a/data/corefork.telegram.org/api/layers.html +++ b/data/corefork.telegram.org/api/layers.html @@ -1977,7 +1977,7 @@ invokeWithLayer4#dea0d430 {X:Type} query:!X = X;Support for link changes for a contact when a message is sent. Now, if user X has user Y in the contact list and if user Y writes a message to user X, number X will become available for him. More...
+Support for link changes for a contact when a message is sent. Now, if user X has user Y in the contact list and if user Y writes a message to user X, number X will become available for him.
Let's consider several typical interaction scenarios for two users.
-User A knows phone number of B (for instance, A has B's number in the phone book). But B does not know А's number. User A sends message to B. Immediately prior to sending a message relevant check is executed at the server side and the link between A and B will change automatically: A's number becomes available for B (user A is then presented as constructor userRequest). -The same happens if user B not having A's number sends a message to the latter. A's number also becomes available to B.
-User A has found user B in a chat, geochat or any other way. For both of them phone numbers are not available (in API - constructor userForeign). A starts chat with B. When messaging A's number will not become available for B and vice versa. To provide B with A's number it is necessary to send him personal message with contact info (phone number should be transferred in constructor inputMediaContact using method messages.sendMedia). -Now B having personal message with A's phone number can store it in his phone book and import it using method contacts.importContacts to have it in contacts. With all that, it is not mandatory for him to send his number: after any message later between them B's number will be available for A (see One user knows the other's number).
-This is quite obvious: messaging does not change links since target state has been reached.
-Since when sending messages to a current user updates on changed links are not sent constructors containing updated links were added to resulting types of messaging methods:
-messages.statedMessagesLinks messages:Vector<Message> chats:Vector<Chat> users:Vector<User> links:Vector<contacts.Link> pts:int seq:int = messages.StatedMessages;
-messages.statedMessageLink message:Message chats:Vector<Chat> users:Vector<User> links:Vector<contacts.Link> pts:int seq:int = messages.StatedMessage;
-messages.sentMessageLink id:int date:int pts:int seq:int links:Vector<contacts.Link> = messages.SentMessage;To indicate for clients that these constructors are supported one should use 3rd layer.
If the user is already logged in and has forgotten their 2FA password, account.resetPassword can be used to initiate a password reset.
On success, the call will initially return a account.resetPasswordRequestedWait constructor and start a 7-day server-side timer, during which the user can abort the reset process using a button sent by the Telegram service account or directly in-UI using account.declinePasswordReset.
When the time comes, account.resetPassword is invoked once more, returning a account.resetPasswordOk to indicate that the password was successfully reset.
-If the user recently requested a password reset that was canceled, account.resetPasswordFailedWait will be returned by the initial account.resetPassword call, and they must wait until the specified date before requesting another reset.
+If the user recently requested a password reset that was canceled, account.resetPasswordFailedWait will be returned by the initial account.resetPassword call, and they must wait until the specified date before requesting another reset.
Note that if the user already knows their 2FA password and simply wants to disable 2FA, the same process used to enable the password must also be used to disable it ».
A user that is not a contact of the current user.
-Constructor schema is available as of layer 18. Switch »| Name | -Type | -Description | -
|---|---|---|
| id | -int | -User identifier | -
| first_name | -string | -First name as supplied by the user | -
| last_name | -string | -Last name as supplied by the user | -
| access_hash | -long | -Checksum dependent on the user identifier | -
| photo | -UserProfilePhoto | -Profile photo | -
| status | -UserStatus | -Current status | -
| username | -string | -Username Parameter added in Layer 18. |
-
A user that is not a contact of the current user, but whose phone number is available.
-Constructor schema is available as of layer 18. Switch »| Name | -Type | -Description | -
|---|---|---|
| id | -int | -User identifier | -
| first_name | -string | -First name the user supplied | -
| last_name | -string | -Last name the user supplied | -
| access_hash | -long | -Checksum dependent on the user identifier | -
| phone | -string | -Phone number | -
| photo | -UserProfilePhoto | -Profile photo | -
| status | -UserStatus | -Current status | -
| username | -string | -Username Parameter added in Layer 18. |
-
Edit information about a given group call participant
+ Method schema is available as of layer 123. Switch »
+| flags | +# | +Flags, see TL conditional fields | +
| muted | +flags.0?true | +Whether to mute or unmute the user | +
| call | +InputGroupCall | +Group call | +
| user_id | +InputUser | +The user in question | +