Как записать "круглое" видео в мессенджере "CONCORD".

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

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

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

Особенности видеосообщений:

• Лимит времени: Максимальная длительность одного ролика составляет 10 секунд.

• Формат: Видео автоматически обрезается в форме круга и записывается на фронтальную камеру.

• Воспроизведение: В чате такие ролики проигрываются один раз при нажатии "Play".

Способ 1

Бэкенд приводит видео к "квадратному" формату с соотношением сторон 1:1 и возвращает ссылку на него обратно в чат собеседникам.

Ниже пример выполнения преобразования видео в "квадратный" формат с помощью "ffmpeg":

ffmpeg 
  -i input.mp4 
  -vf "crop=480:480:0:(ih-480)/2" 
  -c:v libx264 -crf 23 
  -c:a copy output.mp4

Чтобы отобразить "квадратное" видео в виде круга на Java, я создаю шаблон (ViewOutlineProvider). Он принудительно задает графическому элементу (View) форму идеального круга фиксированного размера:

private static final ViewOutlineProvider CIRCLE_PROVIDER = new ViewOutlineProvider() {
  @Override
  public void getOutline(View view, Outline outline) {
    int sizeInPx = (int) TypedValue.applyDimension(
      TypedValue.COMPLEX_UNIT_DIP, 270, view.getResources().getDisplayMetrics()
    );
    outline.setOval(0, 0, sizeInPx, sizeInPx);
  }
};

Затем в холдере применяю описанный выше шаблон к TextureView и ImageView:

static class CircleVideoViewHolder extends BaseViewHolder {
  TextureView texture;
  ImageView   preview;

  VidCrViewHolder(View v) {
    super(v);
          
    texture = v.findViewById(R.id.video_texture);
    preview = v.findViewById(R.id.video_preview);

    texture.setOutlineProvider(CIRCLE_PROVIDER);
    preview.setOutlineProvider(CIRCLE_PROVIDER);

    texture.setClipToOutline(true);
    preview.setClipToOutline(true);
  }
}

В результате выполнения этого кода видео примет "круглый" вид.

Способ 2

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

Так как камера смартфона снимает видео не в "квадратном" формате, я воспользовался матрицей преобразования, центрировал кадр и обрезал лишние стороны.

//фиксированный размер видео с камеры смартфона: 480x640
float scaleY = h / (w * 480 / 640); 
Matrix matrix = new Matrix();
matrix.setScale(1.0f, scaleY, w / 2f, h / 2f);
CircleVideoViewHolder vch = (CircleVideoViewHolder) holder;
vch.texture.setTransform(matrix);

При таком подходе вся работа выполняется на стороне графического процессора (GPU) самого смартфона с максимальной скоростью. Это полностью избавляет от необходимости обрабатывать видео на бэкенде.

В результате получилась вот такая красота:

Итог:

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

Спасибо за вашу поддержку. Это придает стимул писать дальше.

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

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

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

Поскольку я являюсь разработчиком и основателем собственного мессенджера, реализовать эту схему для меня не составило особого труда. Главный секрет заключается в понимании принципов работы криптографических алгоритмов, таких как 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 с использованием блокчейна позволяет оперативно выполнять оплату за предоставленный сервис без лишних трат и банковских процедур. При этом все транзакции становятся видны в блокчейне уже через несколько минут.

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

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

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

Облачный сервис с безграничными возможностями: Бот или не бот - вот в чем вопрос.

Друзьям и коллегам, привет!

Недавно опубликовал на Хабр новую статью с разбором моего Web3-мессенджера. В ней описал личный кейс: как внедрить децентрализованные Web3 технологии и монетизировать внутренние функции приложения без подключения классических платежных систем. Почитать можно здесь: https://habr.com/ru/articles/1052088/

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

Создав так называемых "юзер-ботов" (user-bots), я снабдил платформу дополнительными функциями. В моей реализации такой "Бот" - это полноценный внешний сервис, который имеет точку входа - Endpoint на стороннем облаке и строгий протокол взаимодействия через его API.

В таких популярных приложениях как Telegram или WhatsApp, боты представляют собой отдельные сущности, которые привязываются к основному аккаунту пользователя. Кстати, вопреки расхожему мнению, один аккаунт в Telegram может создать через BotFather не безграничное число ботов, а строго до 20 штук (до 40 для Premium-пользователей).

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

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

• Полный контроль и безопасность окружения: бот изолирован и работает строго в рамках правил реального пользователя.

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

• Готовая монетизация: в профиле каждого пользователя уже прописаны платежные данные в виде Web3-кошелька. Соответственно, они автоматически доступны и боту, если тот реализует платные услуги.

РЕАЛИЗАЦИЯ НА БЭКЕНДЕ

Ниже упрощенный код класса реализующий передачу сообщений на Endpoint:

public async Task<string> ExecuteCommand(string cmd, string uid, string token, string url)
{
    using var client = new HttpClient();
    client.DefaultRequestHeaders.Authorization = new ("Bearer", token);
    
    var body = new StringContent(JsonConvert.SerializeObject(new { data = cmd, user_id = uid }), Encoding.UTF8, "application/json");
    var res = await client.PostAsync(url, body);
    var json = JObject.Parse(await res.Content.ReadAsStringAsync());

    return json["success"]?.Value<bool>() == true 
        ? json["data"]?.ToString() 
        : $"Error: {json["error"]}";
}  

Рабочий шаблон внешнего Endpoint сервиса:

<?php
session_start();
header('Content-Type: text/html; charset=utf-8');

//AUTHENTICATION BEGIN

$allowedToken   = 'super-secret-token';
$providedToken  = '';

if (isset($_SERVER['HTTP_AUTHORIZATION'])) {
    if (preg_match('/Bearer\s+(.+)/i', $_SERVER['HTTP_AUTHORIZATION'], $m)) {
        $providedToken = trim($m[1]);
    }
}

if (empty($providedToken) || $providedToken !== $allowedToken) {
    echo json_encode(['success' => false, 'error' => 'error token']);
    exit;
}

//AUTHENTICATION END

$rawInput = file_get_contents('php://input');
$userData = json_decode($rawInput, true); 

echo json_encode(['success' => true, 'data' => 'Bot answer: ' . $userData['data'] ?? null]);

?>

ВЫВОД

Используя описанную концепцию, можно в теории реализовать любой сервис не изменяя при этом основное приложение. Всё что нужно сделать, построить бот!

Очевидно, что для практического применения такого подхода необходимо обеспечить высокий уровень безопасности: внедрить защиту от SSRF (через валидацию URL и фильтрацию локальных хостов), настроить лимиты для предотвращения DoS-атак (проверяя размер заголовков и длину полученной строки), и так далее.

Всем успехов в разработке!

Благодарю за внимание.