diff --git a/data/web/corefork.telegram.org/api/account-deletion.html b/data/web/corefork.telegram.org/api/account-deletion.html index ac9db92932..54044c91cf 100644 --- a/data/web/corefork.telegram.org/api/account-deletion.html +++ b/data/web/corefork.telegram.org/api/account-deletion.html @@ -44,16 +44,15 @@

A user can delete their Telegram account using account.deleteAccount. 

---functions---
-account.deleteAccount#a2c0cf74 flags:# reason:string password:flags.0?InputCheckPasswordSRP = Bool;
+account.deleteAccount#a2c0cf74 flags:# reason:string password:flags.0?InputCheckPasswordSRP = Bool; + +account.confirmPhone#5f2178c3 phone_code_hash:string phone_code:string = Bool; +account.sendConfirmPhoneCode#1b3faa88 hash:string settings:CodeSettings = auth.SentCode;

Calling this method while specifying the account's 2FA password (if one is set) will immediately delete the Telegram account.

If the account has a 2FA password but the user doesn't remember it, password reset may be requested first », or otherwise, the password field may simply be left empty.

-

In this case, if the account's 2FA password was modified more than 7 days ago and was active in the last 7 days, account deletion will be delayed for 7 days.
-A service message will be sent to the user, containing a link in one of the following formats:

- -

When clicked, account.sendConfirmPhoneCode must be called with the specified hash, using the account with the specified phone number. +

In this case, if the account's 2FA password was modified more than 7 days ago and was active in the last 7 days, account deletion will be delayed for 7 days.

+

A service message will be sent to the user, containing a phone number confirmation link ».

+

When such a link is clicked, account.sendConfirmPhoneCode must be called with the specified hash, using the account with the specified phone number. This will send a phone number verification code to the phone number associated with the account. The phone code settings are the same as for the login code, and auth.cancelCode with auth.resendCode can be used as well, to resend or cancel the phone code as for the login code.

Once the SMS code is received, the account.confirmPhone method will have to be called with the SMS code and the phone hash received from the account.sendConfirmPhoneCode method.

diff --git a/data/web/corefork.telegram.org/mtproto/mtproto-transports.html b/data/web/corefork.telegram.org/mtproto/mtproto-transports.html index d7fd3af695..91bca40f39 100644 --- a/data/web/corefork.telegram.org/mtproto/mtproto-transports.html +++ b/data/web/corefork.telegram.org/mtproto/mtproto-transports.html @@ -173,7 +173,7 @@ The encoding simply consist of the DC ID in two-byte signed little-endian form;

Two keys are extracted from both initialization payloads, using bytes at offsets 8-40: the key extracted from the primary payload is used as encryption key, the key extracted from the secondary payload is used as decryption key.

Two IVs are extracted from both initialization payloads, using bytes at offsets 40-56: the IV extracted from the primary payload is used as encryption IV, the IV extracted from the secondary payload is used as decryption IV.

Only if using MTProxy, the secret is used to provide connection with the MTProxy server. -The secret is a 16-byte string, usually distributed in its hexadecimal form along with the MTProxy host and port.

+The secret is a 16-byte string, usually distributed in its hexadecimal form along with the MTProxy host and port in proxy deep links ».

Often, a 17-byte version of the secret can be found: this simply indicates that the client should use a specific MTProto transport (based on the first byte, usually it's 0xdd, to indicate that the padded intermediate protocol should be used 0xdddddddd; however, clients should default to the padded intermediate transport whenever an additional byte in the secret is encountered).

The extracted encryption and decryption keys must be concatenated with the secret (the first byte of which should be ignored if it's the 17-byte version), and the SHA256 hash of such string should be used as encryption/decryption key.

The obtained encryption and decryption key/IV pairs must then be used with AES-256-CTR to encrypt and decrypt all outgoing and incoming payloads.