Понимаю

Сам в телеге сижу, пока можно🙌

Пока можно используем по МАКСимуму

Какой Васап, вы чего? Мы же в Максе :)))

Васап программист

Хэллоу ворлд :)

Вообще я планирую переделать авторизацию и я буду отправлять ему так:

>> ATH <stealth_login> <sha256_hash_password>
<< ATH RDT login.sneakdeak.fun - сервер просит авторизоваться клиента через домен

>> ATH ticket=<base64_ticket> - тикет будет получен от сервера login.sneakdeak.fun
<< ATH OK stealth_token=<base64_token>

...

Странные? Не думаю, вот небольшая документация к моему протоколу:

Протокол работает на TCP-соединении,

клиент подключается к порту 5890 и отправляет команду SVP

Всего я придумал 5 команды:

SVP (Stealth Version Protocol) - обмен версиями протокола STTP
SVC (Stealth Version Client) - обмен версиями Stealth Messenger
ATH (Authorization User) - авторизация пользователя в системе Stealth
SRO (Synchronization) - синхронизация пользователя, обычно получение список контактов пользователя
STS (Set Status) - пользователь может установить статус (их всего 4: Online, Offline, Away, Busy)

Пример сессии:

Тип SUP указывает на поддержку чего либо

>> SVP SUP 1.0
<< SVP 1.0 - сервер выбирает версию протокола

>> SVC Stealth_Messenger 1.0.0
<< SVC 1.0.0 - сервер выбирает поддерживаемую версию клиента

>> ATH <stealth_login> <sha256_hash_password>
<< ATH OK stealth_token=<base64_token>

>> SRO <list_version>
<< SRO <contact_list_json>

>> STS Online
<< STS OK Online

что за странные махинации

stealth_token'ы придумал я, это токен доступа который в base64 кодируется

чего

я его и использую

stealth token это скорее всего внутренний функционал чтобы отключать устаревшие токены или типо того

так и используй его целиком в чем беда

ну да

неправда, в бейс64 закодирован только первый и второй блок джвт токена, третий блок это хеш подпись чтобы данных, чтобы их нельзя было подделать

после него идёт jsonwebtoken закодированный в base64

stealth_token= это параметр

так бери токен целиком, stealth_token= это не жвт