Технические заметки
Подробный разбор peer-to-peer-архитектуры, транспортного уровня и криптографии PlainApp — из первых рук, по исходному коду.
DLNA Cast: Создание UPnP-отправителя и получателя с нуля
Как PlainApp реализует DLNA/UPnP AV-кастинг с обеих сторон: сканирование и управление телевизорами через SOAP в роли отправителя, и превращение самого телефона в UPnP MediaRenderer в роли получателя — с SSDP-обнаружением, DIDL-Lite метаданными, медиасервером с поддержкой Range-запросов, GENA-колбэками событий и моделью доверия на основе разрешённых/запрещённых IP-адресов отправителей, всё на чистом Kotlin Multiplatform.
Screen Mirror: архитектура низкозадержкового транслирования
В этой статье рассматривается сквозная архитектура системы Screen Mirror в PlainApp: как Android захватывает и аппаратно кодирует H.264/Opus через MediaCodec, как кадры передаются по WebSocket с использованием кастомного бинарного протокола, как веб-сторона декодирует через WebCodecs и рендерит через WebGL2 без копирования через CPU, а также обработка потери пакетов, смена ориентации и удалённое управление касаниями.
PlainApp Безопасность: глубокий анализ
Как PlainApp защищает ваши данные в локальной сети Wi-Fi — с доказательствами из открытого исходного кода.
Дизайн транспорта Wi-Fi Aware — обнаружение соседей и data paths
В этой статье объясняется, как PlainApp использует Wi-Fi Aware (NAN — Neighbor Awareness Networking) как средний уровень своей цепочки fallback'а peer-транспорта, между LAN (HTTPS в одной подсети) и BLE (GATT RPC последней инстанции). Wi-Fi Aware — это то, что позволяет двум устройствам PlainApp общаться, когда они в разных SSID, guest vs IoT VLANs, или вообще без Wi-Fi-инфраструктуры — без необходимости в IP-адресе от DHCP-сервера.
Дизайн BLE-транспорта — Сообщения и загрузка файлов
В этой статье объясняется, как PlainApp отправляет сообщения чата и скачивает файлы по Bluetooth Low Energy, когда ни LAN, ни Wi-Fi Aware недоступны. BLE — это гарантированный fallback: медленный, но работающий вообще без какой-либо IP-связности. Статья описывает формат кадров, двухуровневую схему фрагментации, как (и как не) приоритизируется параллельный трафик и почему каждое соединение разрывается после каждого запроса.
Архитектура peer- и channel-чата
В этой статье end-to-end объясняется, как работает offline-first чат PlainApp: как сообщение проходит от нажатия в UI до другого устройства через peer-транспорт, как групповые каналы распределяют сообщения множеству участников и как система сохраняет устойчивость при исчезновении сетей. Сопряжение (доверие и обмен ключами, бутстрапящий два устройства) рассмотрено в отдельной статье «Pairing Flow».
Процесс сопряжения
В этой статье объясняется, как два устройства PlainApp впервые устанавливают доверие — как они обнаруживают друг друга, обмениваются ключами и приходят к общему транспортному ключу ChaCha20, которым впоследствии шифруется каждое сообщение чата, передача файла и presence-пинг. Архитектура чата и каналов, использующая этот ключ, рассмотрена в отдельной статье «Chat Architecture».