Мобильная разработка

Голосовой ассистент в мессенджере Bitcord: живой разговор вместо переписки.

Наконец могу объявить о внедрении новой фишки в мессенджере Bitcord — функция живого голосового диалога с AI‑ассистентом. Не голосовое сообщение «записал — отправил — жду», а обычный разговор: говорите и сразу слышите ответ. При этом можно выбирать голос асистента и задавать его личные настройки: пол, возраст, манеру общения и прочее.

КАК ЭТО РАБОТАЕТ

1. Запускаете мессенджер Bitcord.

2. Выбираете в меню пункт — «GPT voice live».

3. При необходимости настраиваете стиль ответа (промпт) и голос.

4. Нажимаете «Connect».

5. Удерживаете кнопку с изображением микрофона, пока общаетесь.

6. Отпускаете кнопку — микрофон выключается для экономии ресурсов смартфона.

7. Нажимаете снова и продолжаете общаться.

Это режим push‑to‑talk: контроль остаётся у вас. Пока кнопка зажата — идёт ваша речь; отпустили — микрофон выключается. Если ассистент ещё говорил, ответ можно оборвать тем же жестом.

Вcё ради удобства

Скорость. Иногда удобнее сказать в голос, чем набирать текст — особенно в пути, за рулём (если это безопасно) или когда руки заняты.

Естественность. Голосовой ответ воспринимается как короткий созвон, а не как переписка с ботом. Удобно уточнять детали, просить перефразировать, вести диалог «вопрос — ответ» без лишних тапов.

Контроль. Нет постоянного прослушивания: микрофон работает только пока вы держите кнопку. Настройки голоса и поведения ассистента сохраняются и применяются при создании новой сессии подключения.

Доступность. Голосовой канал проще для тех, кому тяжело много печатать, или когда экран неудобен.

Для чего в мессенджере?

Ассистент остаётся рядом с чатами, файлами и звонками — в том же привычном пространстве. Можно быстро спросить, уточнить формулировку, набросать план или просто «проговорить» мысль, не переключаясь в отдельное приложение. Можно настроить системный промпт на любого персонажа и даже включить взрослый контент. Указать имя, пол, возраст, описать игровую ситуацию и включиться в ролеплей без «тормозов».

Дальше, используя голосовой интерактив, планирую реализовать командный процессор, который будет вызывать другие сервисы: проверка погоды, курсы валют, актуальные новости с фильтром по теме и многое другое. И это в мессенджере размером в 3,5 мегабайта!

Github: https://github.com/BitcordMessenger

Фирменную анимацию раскрытия интерфейса iPhone Duo повторили на Samsung Galaxy Z Fold 8. Разработчик с Reddit использовал штатный датчик шарнира и шейдеры, доказав, что Samsung способна добавить такую же фишку в обычном обновлении One UI.

Данные с сенсора в реальном времени управляют шейдером AGSL через Android Presentation API. Шейдер интерполирует изображение между скриншотами внешнего и внутреннего экранов в зависимости от того, под каким углом сейчас раскрыт корпус.

ВКонтакте ограничила работу Kate Mobile

Популярный Android-клиент Kate Mobile перестал работать с сервисами ВКонтакте. О проблеме разработчики сообщили в официальном сообществе приложения.

Причиной стали новые условия доступа к VK API. С 7 сентября ВКонтакте ввела ежемесячные лимиты на количество запросов для сторонних приложений и объявила о переходе к платному доступу.

Разработчики Kate Mobile утверждают, что заранее пытались выяснить у представителей ВКонтакте стоимость и условия работы по новым правилам, но ответа не получили.

Лимита недостаточно даже при оптимизации

Технические детали команда раскрыла в теме Kate Mobile на 4PDA.

По их оценке, верифицированным партнёрам доступен лимит 100 млн запросов в месяц. Для аудитории Kate Mobile этого объёма может хватить примерно на полтора дня.

Проблема особенно заметна на операциях, которые невозможно вынести в кеш. Например, один только метод messages.send, отвечающий за отправку личных сообщений, по расчётам разработчиков, способен превысить установленный месячный лимит вдвое.

В команде Kate Mobile считают, что новые условия фактически делают работу неофициальных клиентов невозможной. По их мнению, речь идёт скорее о вытеснении сторонних приложений, чем о попытке монетизировать API.

Сам Kate Mobile существует уже много лет и до сих пор оставался альтернативой официальному приложению ВКонтакте. На 4PDA у проекта по-прежнему сохраняется отдельная тема с актуальными версиями и обсуждением клиента.

Для пользователей это означает главное: один из самых известных сторонних клиентов ВКонтакте оказался заблокирован не из-за технической ошибки приложения, а из-за новых ограничений самой платформы.

В комментариях сообщества пользователи уже называют происходящее «концом эпохи» и жалуются, что не хотят переходить на официальный клиент из-за перегруженного интерфейса и рекламы.

Источник: https://t.me/kodjournal/268

BITCORD - объявляет конкурс на разработку: Валютный конвертер и Прогноз погоды!

Привет, Хабр! Мы ищем талантливых PHP-разработчиков, готовых создать два полезных, легковесных сервиса для нашей площадки. Главная фишка — ориентация на текстовый интерфейс (режим чата) и полная автономность кода.

Ниже представлены подробные требования к конкурсным работам.

Что нужно разработать?

Предстоит создать два независимых сервиса. Каждый сервис должен быть оформлен в виде одного самостоятельного PHP-файла, который внутри себя обращается к любым популярным сторонним API, но не привязан к жестким собственным эндпоинтам. Сервисы обязательно должны быть мультиязычными и возвращать результаты на том языке (локали), который передан в качестве входного параметра (ru, en, es...).

1. Сервис конвертации валют (converter.php)

• Интерфейс: Строго текстовый, адаптированный под логику чат-бота.

• Функциональность: Возможность выбора исходной и целевой валюты из динамического или предзаданного списка, ввод суммы и моментальное получение результата.

• Интеграция: Использование надежных внешних API для получения актуальных курсов валют.

2. Сервис прогноза погоды (weather.php)

• Интерфейс: Строго текстовый, структурированный для удобного чтения в чате.

• Объем данных: Сервис должен возвращать текстовую сводку погоды на:

  • Текущий день

  • Завтрашний день

  • Ближайшие 10 дней

• Интеграция: Использование популярных погодных API (например, OpenWeatherMap, WeatherAPI и т.д.).

Технические требования

• Язык программирования: PHP 8.x (чистый код, без тяжелых фреймворков вроде Laravel/Symfony на базовом уровне).

• Формат вывода: Только структурированный текст. Никакого HTML-структурирования или тяжелой графики - результат должен идеально смотреться в обычном CLI-терминале или окне мессенджера.

• Архитектура: Код должен быть чистым и легко встраиваемым в существующие чат-платформы.

• Безопасность: В каждом файле должна выполняться аутентификация по токену (Bearer Token) для защиты доступа к сервису.

Призы и сроки

• Победителю: Умная колонка Яндекс станция мини (с Алисой) или контракт на долгосрочное сотрудничество.

• Другие интересные решения: Денежный приз в криптовалюте мессенджера Bitcord (BTCD). Сумма будет зачислена на ваш кошелек в приложении Bitcord.

Сроки

• Дедлайн приема работ: 1 Октября 2026 г.

Как принять участие?

Опубликуйте ваш код на GitHub (публичный репозиторий) и отправьте ссылку в комментарии к этому посту или в мессенджер Bitcord на имя администратора @administrator. В README обязательно приложите пример передачи Bearer-токена в заголовках, краткую инструкцию по запуску и примеры текстовых команд.

Желаем всем удачи и чистого кода! Вопросы задавайте в комментариях.

Собираем интерфейс приложения как LEGO — проект M3E Canvas позволяет расставлять кнопки, поля ввода, навигацию и другие UI‑элементы, а затем генерирует готовый промпт для ИИ. Можно менять цвета, шрифты и настраивать переходы между экранами. После сборки достаточно скопировать промпт и вставить его в нейросеть, чтобы быстро получить приложение.

Наконец мой мессенджер прошёл тест в Google Play . За время тестирования он научился совершать звонки по udp. Это позволило по udp получать не только голос, но и пинок от сервера на проверку сообщений в реальном времени. Осталось придумать как без внешних сервисов, вроде FCM, не засыпать вместе с системой и не давать андроиду прибить процесс приложения, чтоб принять udp пендаль в любое время. Так как мессенджер ориентирован на пользователей роутеров Mikrotik, на роутер и была возложена такая задача. Не давать телефону спать :). В качестве энергетика будет выступать DHCP Lease. В приложении я подписываюсь на изменения параметров сети, и выполняю задачу в обычном executor.

private void registerNetworkCallback() {
        ConnectivityManager connectivityManager = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
        if (connectivityManager != null) {
            connectivityManager.registerDefaultNetworkCallback(new ConnectivityManager.NetworkCallback() {
                @Override
                public void onAvailable(@NonNull Network network) {
                    isNetworkActive.set(true);
                    if (userId > 0) {
                        tickUdp();
                        startDownloadNewMsg(true);
                    }
                    offlineHandler.removeCallbacks(resetStatusesRunnable);
                    Log.d(LOG_TAG, "Network: WiFi Connected. " + network);
                }

                @Override
                public void onLinkPropertiesChanged(@NonNull Network network, @NonNull LinkProperties linkProperties) {
                    Log.d(LOG_TAG, "LINK CHANGED DNS=" + linkProperties.getDnsServers());
                    if (userId > 0 && isNetworkActive.get()) {
                        tickUdp();
                        startDownloadNewMsg(true);
                    }
                }

                @Override
                public void onLost(@NonNull Network network) {
                    isNetworkActive.set(false);
                    offlineHandler.postDelayed(resetStatusesRunnable, 15000);
                    Log.d(LOG_TAG, "Network lost. Scheduled offline reset in 15s...");
                }
            });
        }
    }

который тригерится в том числе и на изменение списка DNS серверов. В роутере я указываю время аренды DHCP для подключённых устройств 6 минут. Соответственно устройства будут обновлять аренду каждые 3 минуты. С таким же интервалом 3 минуты, скриптом меняем список DNS серверов для локальной сети.

:local netId [/ip dhcp-server network find address="192.168.88.0/24"];
:local currentDns [/ip dhcp-server network get $netId dns-server];
:if ($currentDns = "192.168.88.1,8.8.8.8") do={
    /ip dhcp-server network set $netId dns-server="192.168.88.1,8.8.4.4";
} else={
    /ip dhcp-server network set $netId dns-server="192.168.88.1,8.8.8.8";
}

Этих трёх минут вполне хватает чтоб не заснуть, и пингануть разочек сервер для прогрева udp порта.

Расход заряда в планшете с таким энергетиком от роутера я специальными приборами не замерял. Но на глазок, за 12 часов бездействия ни одного процента зарядка не потяряла, и через 12 часов и планшет и телефон приняли и звонок и сообщение мгновенно.

Представлен открытый проект Phone Farm iOS - TikTok-ферма на устройствах с iOS. Подключаем iPhone к Mac, регистрируем в панели и управляем прямо из браузера: можно смотреть экран в реальном времени, тапать, свайпать и запускать автоматизацию TikTok. Встроенный планировщик публикует посты и слайд-шоу по расписанию, а очередь и история запусков хранятся в PostgreSQL. Проект работает без джейлбрейка и полностью локально.

Представлен открытый проект vphone-cli для загрузки виртуального iPhone с помощью фреймворка Virtualization.framework от Apple, используя инфраструктуру виртуальных машин PCC Research.

Хороший код: как понять, что его будет удобно менять

Понятные имена, небольшие методы и аккуратное форматирование делают код проще для чтения. Но даже аккуратный файл может оказаться дорогим в работе, если небольшое изменение требует восстановить много контекста и затронуть несколько частей системы.

Вместе с Ринатом, iOS-разработчиком в Naumen, разбираемся, почему хороший код проверяется следующей задачей, как проявляется сложность изменений и на что стоит смотреть при оценке кода.

Код проверяется следующей задачей

Пока работа над задачей еще свежая, почти любой код кажется понятным. Автор помнит, почему вызовы стоят именно в таком порядке, какой случай обсуждали на ревью и что здесь собирались переделать позже. Коллеги тоже держат часть контекста в голове.

Так что даже не самое удачное решение какое‑то время не доставляет особых проблем.

Через полгода ситуация меняется: исходная задача давно закрыта, участники обсуждения заняты другими частями проекта, а другому разработчику нужно внести небольшое изменение.

Именно в этот момент становится понятно, насколько код вообще рассчитан на изменения.

Простая задача может оказаться дорогой

Одна из задач у нас на планировании звучала безобидно:

После ошибки авторизации запрос повторять не нужно, после временной сетевой ошибки — нужно, причем с увеличивающейся задержкой.

Само условие укладывается в несколько строк. Но сначала приходится выяснить, где на самом деле живет это правило: в сетевом клиенте, в сервисе авторизации, в middleware.

А еще нужно понять, не запускает ли часть повторов таймер внутри другого объекта и не зависит ли соседний сценарий от текущего порядка вызовов. В итоге сам код меняется быстро, но день уходит на восстановление картины вокруг него.

Смотреть нужно на изменение, а не на файл

У кода есть свойства, которые легко заметить сразу: понятные имена, небольшие методы, аккуратное форматирование и простая структура. Все это полезно, но само по себе еще не говорит, насколько удобно систему менять.

Можно открыть класс и довольно быстро разобраться в каждом его методе. А потом выяснить, что для добавления одного состояния нужно исправить еще четыре модуля, обновить несколько почти одинаковых преобразований данных и соблюсти порядок вызовов, который нигде явно не зафиксирован.

Файл может выглядеть вполне нормально, а изменение при этом оказывается дорогим.

Мне в этом контексте близко описание сложности изменений у Джона Оустерхаута. Он выделяет три характерных проявления.

• Маленькая правка расползается по системе

Добавили поле в модель и приходится менять сетевой слой, хранилище, аналитику, несколько экранов и тестовые данные.

Иногда это естественная цена изменения контракта, а иногда — признак того, что одно знание размазано по проекту.

• Для локальной работы нужно слишком много контекста

Чтобы поправить один обработчик, нужно знать устройство навигации, жизненный цикл экрана, особенности кэша и два исторических обхода старых ошибок.

• Есть зависимости, о которых разработчик даже не знает

Они обнаруживаются уже после изменения. Например, перестановка двух вызовов отключает сетевую проверку: первый метод использует закэшированное состояние и завершает сценарий раньше времени.

Эти признаки полезнее многих разговоров о «чистом коде»: о длине метода можно спорить, а вот с последствиями изменения — сложнее.

Обычно я смотрю на три вещи

1. Сколько мест потребуется затронуть?

2. Сколько информации нужно восстановить перед работой?

3. Как быстро мы узнаем, что ошиблись?

Чем меньше ответ зависит от памяти конкретного человека, тем спокойнее живется проекту.

Wildberries выпустила собственный мессенджер WB Chat

У Wildberries появился собственный мессенджер WB Chat. Приложение уже доступно пользователям на Android и iOS, а авторизация проходит через WB ID.

Интерфейс построен по знакомой схеме: диалоги разделены на чаты, группы и каналы, причём создать собственную группу или канал можно непосредственно из приложения. Есть отдельный раздел профиля с аватаром, именем, статусом и возможностью выбрать юзернейм, а для организации переписок предусмотрены папки.

Набор функций тоже постепенно расширяется. Сейчас WB Chat позволяет:

• отправлять сообщения, фото, видео и файлы;

• пересылать сообщения и отвечать на них;

• использовать реакции, эмодзи и стикеры;

• создавать публичные и приватные группы и каналы;

• закреплять важные сообщения;

• искать людей, чаты и сообщения;

• совершать аудиозвонки;

• расшифровывать голосовые сообщения в текст.

Последняя функция особенно интересна для повседневного использования: рядом с кнопкой воспроизведения голосового сообщения появляется возможность получить его текстовую расшифровку. То есть длинное голосовое необязательно прослушивать целиком.

При этом проект пока активно развивается. Например, в последних версиях разработчики отдельно сообщают об исправлениях синхронизации, работе контактов, медиафайлов, звонков и повышении стабильности приложения.

В Google Play приложение опубликовано компанией WB FZE, зарегистрированной в Hamriyah Free Zone в эмирате Шарджа, ОАЭ. На момент проверки там указано 1 тыс.+ скачиваний.

Есть и отдельный момент, на который стоит обратить внимание перед регистрацией: в информации Google Play разработчик указывает, что приложение может собирать фотографии и видео, файлы и документы, а также передавать некоторые категории данных третьим сторонам. При этом передача данных заявлена как шифруемая.

Скачать WB Chat для Android можно через Google Play, для iPhone и iPad — через App Store. Также заявлена веб-версия WB Chat.

Пока это выглядит скорее как новый игрок на рынке мессенджеров, чем полностью сформировавшаяся альтернатива привычным сервисам. Но наличие чатов, групп, каналов, звонков, поиска, папок и расшифровки голосовых показывает, что Wildberries постепенно собирает полноценную коммуникационную платформу.

✔ Код — журнал о технологиях https://t.me/kodjournal подпишитесь на наш Telegram-канал! 😎

ИИ-ревью кода как сомнительное удовольствие

Этот пост написан как реакция на сегодняшнюю хабровскую публикацию - Проблема «принципал — агент» в эпоху ИИ‑агентов

В ней рассматривается "интересная" такая схема - отдавать результаты человеческого ревью кода ИИ-агенту.

Меня это в определенной мере удивило, потому что, судя по тому, что сейчас пишут в сети, то и код пишет агент, и ревью тоже агент делает. Чаще всего другой.

Например, код пишет Claude Code, а ревью делает Codex (И это еще хорошо, если они по своим возможностям в написании кода примерно равны, а то ведь агенты-ревьюверы могут быть и гораздо слабее агентов-кодеров).

Но вот остается вопрос: как решаются случаи, когда они расходятся во мнениях? Кому доверять больше? Устраивать дискуссии? И кто принимает окончательное решение?

Или, реальный случай: Claude Code в "холодной сессии" написал ревью своего же кода из порядка 20 пунктов. Тот же код и Codex пишет ревью на 8 пунктов.

Что дальше? - Разбираться самому человеку или снова устроить дискуссию между агентами?

И сколько токенов они сожгут в этой дискуссии? И сколько времени это займет? И где гарантия от того, что если они по отдельности галюционируют, то и вместе они не начнут делать то же самое, а то и провоцировать друг друга на эти самые галюцинации?

Т.е., получается, что выигрыш от такого "автоматизированного" под ИИ ревью становится сомнительным удовольствием.

Jetpack Room 3.0 теперь stable с кучей преимуществ для мультиплатформы и не только. Запланируйте интеграцию нового мажора.

У меня как раз есть статья

Около €170 тыс. заработал разработчик, создавший приложение, которое позволяет светить вспышкой смартфона в лицо пользователя — за подписку в нём люди платят €70 в год. Автор уверяет, что такие вспышки помогают расслабиться, уснуть и войти в состояние, похожее на транс. За прошлый месяц приложение скачали 70 тысяч раз. Весь продукт состоит из фонарика и таймера.

[пожалуйста, не злоупотребляйте эмодзи]

😻 Привет Халчане! Новое обновление HalChat for Android 1.0.3 (Pin, read and react)

Что нового?
🥷 Теперь можно закреплять сообщения
🤗 Поиск по чату
😳 Реакции на сообщения
🤓 Возможность выделять и копировать текст
🤖 Синхронизация действий в реальном времени
🫢 Возможность вернуться в самый низ, когда зашли далеко

Что исправлено?
🤠 Проведена оптимизация от улучшения распределения задач до ускорение процессов синхронизации
👻 Исправлены баги (опросы показывали зашифрованный текст, не всегда загружались люди, терялась синхронизация и данные и т.п.)
🫩 Добавлен выбранный вариант в опросе

Что дальше?
🙀 В следующем обновлении будут дополнительно добавлен локальный ИИ. Благодаря однобитным ИИ моделям, это новая технология уже доступна на HalChatWeb.
🤔 Также я дообучил собственную ИИ модель HalChat-RP с которой сняты больше ограничений и дообучена на RP общении, в том числе все 1к+ ИИ персонажей из генератора HalChatRP

И хотел бы попросить вас всем пройти опрос, проголосовало мало людей, а от этого выбора зависят новые звуковые эффекты мессенджера: https://halwarsing.questionpro.com/t/AddsYZ9TdN

😈 До новых встреч!

Google Play: https://play.google.com/store/apps/details?id=halwarsing.net.halchatandroid
RuStore: https://www.rustore.ru/catalog/app/halwarsing.net.halchatandroid
HalChat Web: https://halch.at/c/tZgWWT
GitHub: https://github.com/halwarsing/HalChat/tree/dev

Представлен открытый проект Send it, with PairDrop (веб-версия проекта) — AirDrop для всех. Это универсальный способ передачи файлов на ПК и мобильных устройствах в браузере между Windows, Linux, Android, iOS, macOS и другими ОС:

• работает без скачиваний драйверов и утилит и дополнительного ПО;

• просто открываем сайт на обоих устройствах в браузере и начинаем передачу;

• если используете одну сеть Wi‑Fi — устройства сразу увидят друг друга;

• если используете разные сети — нужно один раз ввести шестизначный код, создать пару устройств, и дальше устройства будут находить друг друга автоматом;

• передача файлов идем напрямую между устройствами;

• можно передавать большие объёмы данных без ограничений.

Перед каждым релизом прохожу по одному и тому же списку. Не потому что умный, а потому что каждый пункт там появился после того как я облажался.

Три вещи которые горели чаще всего.

Разные версии Android. На эмуляторе всё красиво. На реальном устройстве со старой версией что-то обязательно едет. Держу под рукой старый телефон с Android 10, туда ставлю перед каждым релизом.

Разрешения. Забываешь добавить в манифест, на новых версиях система спрашивает пользователя, пользователь жмёт «запретить» и половина функций молча перестаёт работать. Без каких-либо ошибок в логах.

ProGuard и минификация. Локально всё работает. В release сборке падает что-то что ты вообще не трогал. Потому что минификатор убрал класс который использовался через рефлексию.

Список не длинный но каждый раз спасает от как минимум одного стыдного бага в продакшене.

Что у вас в чеклисте перед релизом чего нет у большинства?

Открытый проект RepoStore для смартфонов на Android превращает GitHub в Google Play и помогает найти любые Android‑приложения среди репозиториев. С помощью RepoStore можно быстро найти и открыть APK‑файл — у него будут описание и даже рейтинг. Всё разделено по категориям.

Сравнение Claude Code Fable и Codex Open AI по ходу работы над одним и тем же проектом

Вчера, 1-го июля, программисты и активисты начали бурную трудовую неделю. А именно: вернулась модель Claude Fable 5 и она будет доступна в вольном режиме до (или по) 7 июля. Так что есть 7 дней, чтобы сделать буст своим проектам.

Я тоже не избежал этой участи и вот уже почти целый день делаю polishing своему текущему проекту мобильного приложения.

Что сказать про впечатления? - Ощущение вот того самого вайб кодинга, о котором говорил Карпаты. Говоришь модели что делать и она делает. Технических ошибок просто нет, от слова совсем. Есть ошибки архитектурные, но не существенные, исправляются одной-двумя итерациями.

И кстати, получилось сравнить с Codex'ом от Open AI, который решил попробовать на старте этого же проекта. Результат сравнения такой: Codex очень сильно подтянулся в работе с кодом, иногда даже кажется, что нет различий.

Но вот вокруг кода хуже: болтливые они оба, но у Codex больше какой-то разболтанности, разбрасывания в стороны. Особенно это видно на написании документации, пишет незначительные детали, теряет главное. И слабее держит инструкции.

Claude Code Fable в этом отношении гораздо чётче действует. Более жёстко держит инструкции, больше памяти, что характерно, помнит предыдущий и даже предыдущие чаты. Меньше разбрасывания на второстепенные детали, чётче фокус. Даже чек-лист у него выглядит проще, чётче и понятнее, чем у Codex.

Единственное, что может я так натаскал Claude. С другой стороны, не использую MCP, RAG, даже скилы и хуки. Зашил все в память, их там три: общая пользовательская, описание проекта и правила работы.

И напоследок обнаружил в Claude очень полезную функцию оценки загруженности контекстного окна.

Может она уже давно там была, о ней вроде писали, но что-то казалось, что это в CLI. А теперь оказывается её можно использовать и в декстопной версии. Думаю и другим пользователям это тоже пригодится.

Обычно смотришь, если чат начинает тормозить, значит пора. Или спросишь саму модель, но она обычно отвечает, что если на глаз, то загружена на 75%, но лучше начать новый чат. А теперь можно точно увидеть процент загруженности. Более того, можно даже увидеть чем именно загружено контекстное окно.

Для этого в чате Claude Code, в поле ввода достаточно ввести слэш команду - /context

Прикрепляю скриншот как это выглядит вживую

И ещё такое впечатление, что Claude Fable стал жечь меньше токенов за счёт какого-то более делового, но все ещё дружелюбного стиля общения.

Так что, удачи всем с проектами на этой бурной трудовой неделе!))

Сквозное шифрование, или как Telegram и Bitcord защищают переписку.

Хочу написать небольшой пост о сквозном шифровании, или, если использовать технический термин, E2EE (End-to-End Encryption).

Сегодня эта технология широко применяется во многих мессенджерах. Я тоже реализовал E2EE в мессенджере Bitcord . Однако далеко не все понимают, как именно работает этот механизм, поэтому попробую объяснить простыми словами.

Поскольку я являюсь разработчиком и основателем собственного мессенджера, реализовать эту схему для меня не составило особого труда. Главный секрет заключается в понимании принципов работы криптографических алгоритмов, таких как AES и RSA. Хотя современные реализации E2EE обычно используют не RSA, а алгоритмы на эллиптических кривых (например, X25519), я не стал прибегать к усложнениям.

Алгоритм AES я использовал для непосредственного шифрования текстового сообщения, которое один пользователь отправляет другому. Для шифрования применяется секретный ключ (или пароль). Основная проблема такого подхода заключается в том, что этот ключ необходимо каким-то образом передать получателю. Если злоумышленник перехватит ключ, он сможет расшифровать сообщение.

Чтобы этого не произошло, я использовал ещё один алгоритм - RSA. Для его работы требуется пара криптографических ключей: публичный и приватный. Так как RSA не предназначен для шифрования больших объёмов данных, я его использовал для безопасной передачи того самого секретного ключа, который используется алгоритмом AES.

В результате схема выглядит так.

Сначала текст сообщения шифруется алгоритмом AES с использованием случайного секретного ключа. Затем этот ключ шифруется алгоритмом RSA с использованием публичного ключа получателя. Когда получатель отправляет ответ, он выполняет ту же самую операцию, но уже с публичным ключом аппонента.

Важно понимать, что публичный ключ предназначен только для шифрования. Расшифровать данные с его помощью невозможно. Для расшифровки существует только соответствующий ему приватный ключ.

Когда получатель открывает сообщение, его устройство сначала с помощью приватного ключа RSA расшифровывает секретный ключ AES, а затем уже этим ключом расшифровывает само сообщение.

В моём приложении это работает следующим образом. Публичные ключи пользователей хранятся на сервере. Когда пользователь отправляет сообщение, приложение запрашивает у сервера публичный ключ получателя, шифрует сообщение на устройстве пользователя и отправляет на сервер уже зашифрованные данные. Сервер выступает лишь в роли посредника и пересылает этот зашифрованный пакет получателю. Сам сервер приватные ключи не хранит.

При этом приватные ключи никогда не покидают устройство пользователя. Они хранятся в защищённом хранилище смартфона, и получить к ним доступ не может ни сервер, ни разработчик приложения, ни кто-либо ещё. Поэтому расшифровать переписку может только владелец соответствующего приватного ключа.

В этом и заключается смысл сквозного шифрования: сервер передаёт сообщения, но не имеет возможности их прочитать.

Именно поэтому было довольно забавно наблюдать, как спецслужбы требовали у Павла Дурова "ключи шифрования", чтобы получить доступ к переписке пользователей Telegram. Никаких универсальных ключей у него нет и быть не может - приватные ключи находятся только на устройствах самих пользователей.

Именно поэтому требование "передать ключи" технически лишено смысла. Передавать попросту нечего.

П.С.

Я - сетевой долгожитель и начинал свой путь еще в эпоху Фидонета (FidoNet). Эта сеть была по-настоящему децентрализованной: никаких общих серверов и никакого DNS. Все строилось просто: компьютер, модем и терминальная программа для связи. Часто в роли узла (ноды) выступал сервер в банке, где знакомый сисадмин выделял адреса. При этом подключиться можно было к любому другому участнику, даже к частному лицу. Вот это и была настоящая децентрализация! Думаю, учитывая растущее давление регуляторов на современный интернет, мы скоро снова вернемся к проверенным идеям старого доброго Фидо.

Прямая Web3-монетизация без посредников (Peer-to-Peer) для артистов на радио.

Буквально вчера закончил написание сервисного бота для коммерческих нужд в мессенджере "Concord". Основной целью проекта является автоматизация процессов публикации авторского материала на интернет-радио. Бот был создан как помощник для авторов аудиоконтента: музыкантов, продюсеров, подкастеров и т. п.

Задача была непростой. Нужно было объединить возможности мессенджера с его токеномикой и реализовать передачу медиаконтента (картинок, аудиофайлов, текстовых данных) на удаленный сервер в формате JSON. Для этого я написал серверную страницу на PHP, в которой реализовал весь необходимый API.

При передаче медиаданных пользователь запускает нужного бота и отправляет ему в личные сообщения весь необходимый материал. Отправка изображения артиста и аудиофайла выполняется напрямую, без каких-либо команд. Бот сам идентифицирует тип данных, полученных от пользователя, и записывает их в локальные файлы. Вот как я реализовал проверку принадлежности данных к типу файлов:

function isJpeg(string $data): bool
{
    return substr($data,0,2) === "\xFF\xD8";
}

function isMp3(string $data): bool
{
    if (substr($data,0,3)==="ID3") {
        return true;
    }

    return isset($data[1])
        &&
        ord($data[0])===0xFF
        &&
        (ord($data[1]) & 0xE0)===0xE0;
}

После получения данных нужно сразу определить что именно пришло - команда или файл:

if (preg_match('/^\/(help|bio|title|tracks|done)\b/i', $data))
{
    processCommand($db, $uuid, $data);
    exit;
}

if (isBase64($data))
{
    saveBinary($db, $uuid, $data);
    exit;
}

reply("Unknown command, please use /help.", false);

Описание профиля артиста и названия его треков передаются в текстовом виде используя специальный набор команд:

• /help - Show this help

• /bio text - Update artist biography

• /tracks - Show info of all tracks

• /title text - Update current track title

• /pay amount - Pay for service

• /done - Finalize current track

• Send JPG image to update artist image

• Send MP3 audio to update current track

Используя бота, артист может отправлять свои материалы в ротацию на радио для продвижения своего творчества. Протокол взаимодействия с ботом довольно простой:

1. артист отправляет фото профиля

2. артист отправляет описание профиля

3. артист загружает трек

4. артист отправляет описание трека

5. артист выполняет оплату сервиса

6. артист финализирует трек

   Пока трек не финализирован, артист может изменять любые данные. Финализация трека возможна только после выполнения всех вышеуказанных действий. После этого любые отправленные артистом данные активируют запись уже нового трека, и процесс повторяется. При этом данные профиля артиста можно изменять без ограничений.

МОНЕТИЗАЦИЯ

Отправка материала артистом требует платы за сервис. Когда артист подтверждает оплату, бот списывает с его кошелька требуемую сумму и зачисляет её на кошелек владельца радиосервиса. Это значительно упрощает обмен активами между плательщиком и получателем.

Таким образом, технология Web3 с использованием блокчейна позволяет оперативно выполнять оплату за предоставленный сервис без лишних трат и банковских процедур. При этом все транзакции становятся видны в блокчейне уже через несколько минут.

Следующим этапом разработки я планирую реализовать возможность начисления роялти каждому автору музыкального материала. Для этого потребуется создать публичную таблицу рейтинга на сайте радио, где слушатели смогут голосовать за понравившиеся треки, продвигая артиста на верх списка. Исходя из количества прослушиваний конкретного трека, можно будет рассчитать сумму роялти и автоматически выплачивать её на личный кошелек автора в мессенджере.

Таким образом, объединение двух разных сущностей, а именно интернет-радио с приложением для обмена сообщениями, является неким ноу-хау для оказания помощи в развитии молодых дарований. Лично для меня как для разработчика это отличный вызов и прекрасная возможность "пошевелить мозгами".

Если у вас появятся предложения, буду рад подискуссировать.