Это понятно, только там нюанс в том, что ботов в максе кто попало делать не может, там эта тема только для юрлиц (MAX изменил правила: публиковать ботов и мини-приложения можно только через верифицированные юрлица РФ / Хабр), вдобавок боты проходят модерацию, поэтому всякое такое там вряд ли пролезет, а если пролезет долго не проживет. С яндексом примерно та же история, нужен яндекс 360 для бизнеса. Мне в эти истории впутываться совершенно не хочется. ВК API единственный реальный вариант, но там все завязано на сообщества, пока было лень разбираться. (плюс есть ощущение что его скоро прикроют или тоже завяжут на юр лица).
Пока что прикрутил управление через сам яндекс диск. Кидаю ссылки в блекхол директорию на диске, которую приложение постоянно мониторит, оно их оттуда забирает в работу. Но это конечно не юзер френдли.
А, не знал. Зря поверил в эту говноплощадку тогда.
Тогда либо юзербота (можно один и тот же акк и бот и клиент, текстовыми командами в избранных), либо ВК, но там думаю лимиты мелкие, можно видео через MAX юзербота, а интерфейс (кнопки) в ВК.
Я когда-то уже делал бота в вк, там не сложно.
Не, это сразу смерть ВК. Там куча пользовательских сообществ с кучей ботов. Это разрушит всю экосистему.
Это была моя мысль, когда я начинал писать этот проект. Но теперь я уже в этом не уверен.
Я взаимодействую с API ВК начиная с 2016 года. Не часто, но раз в год-два приходилось что-то автоматизировать. И с каждым разом я видел, что это API все больше урезалось и ограничивалось. Особенно это было видно в отношении сторонних клиентов.
Когда я первый раз засветил мой проект на публику в одном чате ТГ, то спустя ~неделю из документации ВК исчезли несколько важных методов которые этот проект использует. Эти методы не отключили, просто убрали их из публичной документации. И если ты о них никогда не знал, то сразу и не поймешь, что здесь что-то не так. Также для получения доступа к некоторым методам ты должен написать в их саппорт, а они уже будут решать давать тебе его или нет. А также есть вообще защищенные методы, для получения которых ты должен быть юрлицом.
Так что не надо обольщаться. Если надо будет, они ограничат или прикроют все что нужно.
Opera mini еще жива, можно с целью экономии гнать ее трафик через обход БС
А если ипользовать тестовый чат для транспорта?
Написать расширение для Chrome по типу
Client socks → TCP → Local HTTP/TCP relay payload(sock data, socks cmd) →struct {total_len_u16, stream_id_u32, SOCK_PAYLOAD) → Browser.
Browser ext → HTTP(S) → Local HTTP (long‑poll / chunked response) (js stream api).
Browser (raw stream data) → WhiteList (text, webrtc)
Браузер пересылает его через БС сервисы текстом, webrtc, тд (js)
Браузер занимется только пересылкой octet-stream туда и обратно, он ничего не должен знать о формате
Данные о формате, их парсингом и реконструкцией занимаются Local HTTP/TCP Relay
На другой строне такой же порядок, только указываем для Local HTTP/TCP Relay (demux по streamid) реальный адрес SOCKS Proxy
Пока я сделал такое мультиплексование socks (на каждое входящее локальное socks соединение, новый streamid) без браузера через TLS и HTTP (буферезация ( по времени или размеру пакета)→ u16,streamid,sockpayload → post)
Затем новый post при входящих даных
Читаю ответы из одного потока GET (TE: Chunked) тот же формат total_len_u16, stream_id_u32, SOCK_PAYLOAD
Пересылаю по соединениям по streamid обратно socks клиенту
Ну и сделал авторизацию по подписям ed25519 (timestamp) в заголовках http
Проходит даже через CloudFlare
Еще заметил что с резидентных IP (зарубежная esim в роуминге в РФ, IP зарубежного моб оператора ) нет блокировки по IP (от датацетра) сервисами в РФ. Т.е нужно еще чтобы IP зарубежом был резиденсткий для рабочего обхода
Ваш код на Rust - это TCP forwarder с кастомным мультиплексированием на уровне приложения. Для взаимодействия с ним нужно писать отдельного клиента который понимает этот кастомный протокол. TCP forwarder пересылает байты только к одному конкретному адресу напрямую. В качестве SOCKS-прокси этот проект не получится использовать.
Как я понимаю вы имели в виду реализацию на уровне клиента конвертации SOCKS в этот кастомный протокол. Значит, мультиплексирование будет осуществляться через remote соединение, а не local. В условиях нормального интернета Cloudflare и подобные позволяют long-lived TCP, также вы можете отправлять напрямую к своему серверу. Но в условиях белого списка все это работать не будет.
Если реализовывать транспорт с кастомным мультиплексированием не через HTTP GET/POST, а через API чата, то кастомное мультиплексирование становится не нужно и потребность в кастомном протоколе пропадает. В этом случае гораздо проще сразу реализовать SOCKS-прокси чтобы не было потребности в кастомных клиентах. И получится проект из топика
В этом посте я написал, что документацию можно брать из других источников. Но 5 дней назад ВК обновила правила API:
ВКонтакте обновляет политику работы с VK API для сторонних сервисов и приложений. Все интеграции должны использовать только методы, опубликованные в официальной документации, и соблюдать установленные лимиты. Методы, не входящие в публичную документацию, будут поэтапно ограничены.
ВКонтакте оставляет за собой право ограничивать доступ к API для приложений, которые нарушают правила платформы, создают избыточную нагрузку на инфраструктуру или не обеспечивают надлежащую защиту данных пользователей. Изменения направлены на повышение безопасности и стабильности платформы для пользователей, авторов и партнёров.
2 апреля 2026 года
Видимо они решили резать свой API, а также выявлять приложения которые используют незадокументированные методы и банить их.
