#react_native — Public Fediverse posts

Outbox-паттерн для мобильного мессенджера: как Telegram не теряет сообщения и почему ваш код их теряет

Это седьмая статья про инженерные решения в ONEMIX. Тема узкая, но болезненная для каждого кто делал мобильное приложение с отправкой сообщений или файлов. Сценарий с которого всё началось у меня. Пользователь в чате выбирает большое видео, нажимает отправить. Видео начинает грузиться. Пользователь нетерпеливый, прокручивает вверх посмотреть переписку, потом переходит в другой чат, потом возвращается. Что должен он увидеть? В Telegram он увидит свой видео-бабл с прогрессбаром, как и оставил. В большинстве самописных мессенджеров он увидит пустой чат без своего сообщения , потому что upload жил в state экрана, а экран размонтировался. XHR продолжал работать в фоне, файл загрузился на сервер, но результат пришёл в null, потому что setter уже не существует. Сообщение фактически отправлено, но пользователь об этом не знает. Это боль которая лечится не "правильным useState", а отдельным архитектурным слоем . Этот слой называется outbox. В этой статье разберу свою реализацию из ONEMIX, это 820 строк TypeScript которые делают то что в Telegram кажется естественным.

https://habr.com/ru/articles/1034690/

#react_native #мессенджер #optimistic_update #outbox #мобильная_разработка #архитектура #telegram #асинхронность #обработка_ошибок #retry

Как я сделал групповые звонки в React Native мессенджере: WebRTC, CallKit и грабли production'а

Это третья статья из серии про инженерные решения в ONEMIX — моём мессенджере на React Native. В первой я разбирал трёхуровневый кэш сообщений, во второй — реализацию Double Ratchet E2E. Сегодня — про звонки. Звонки в мессенджере — это та функция, которая работает либо отлично, либо никак. Пользователь привык что WhatsApp/Telegram звонят мгновенно, показывают входящие на заблокированном экране, переживают переключения Wi-Fi/LTE, и работают из фона. Если твоя реализация делает хоть что-то из этого хуже — пользователь это сразу заметит и переключится на "нормальный" мессенджер. Я потратил несколько месяцев на то чтобы довести звонки в ONEMIX до production-уровня. В процессе пришлось изучить WebRTC изнутри, разобраться с iOS CallKit и VoIP push notifications, и собрать десяток граблей которые в туториалах не упоминают. В этой статье — как это устроено, какие решения оказались критичными, и что бы я сделал по-другому. Сразу оговорка. Я не использую готовые SDK типа Agora, Twilio, 100ms. У них отличное качество и поддержка, но они не дают полного контроля над процессом — а для мессенджера контроль критичен. Когда звонок не проходит, пользователь винит приложение, а не "SDK от третьей стороны". Плюс готовые SDK стоят денег, которые на раннем этапе продукта лучше направить в другие места.

https://habr.com/ru/articles/1033930/

#webrtc #react_native #livekit #callkit #voip_push_notifications #trickle_ice #мобильная_разработка #звонки #мессенджер

Я реализовал Double Ratchet в React Native мессенджере. Разбор протокола и кода

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES-GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку . Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст. Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему. Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

https://habr.com/ru/articles/1033830/

#double_ratchet #signal_protocol #e2e #endtoend_encryption #react_native #криптография #мессенджер #ecdh #hkdf #web_crypto_api

Я реализовал Double Ratchet в React Native мессенджере. Разбор протокола и кода

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES-GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку . Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст. Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему. Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

https://habr.com/ru/articles/1033830/

#double_ratchet #signal_protocol #e2e #endtoend_encryption #react_native #криптография #мессенджер #ecdh #hkdf #web_crypto_api

Я реализовал Double Ratchet в React Native мессенджере. Разбор протокола и кода

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES-GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку . Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст. Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему. Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

https://habr.com/ru/articles/1033830/

#double_ratchet #signal_protocol #e2e #endtoend_encryption #react_native #криптография #мессенджер #ecdh #hkdf #web_crypto_api

Я реализовал Double Ratchet в React Native мессенджере. Разбор протокола и кода

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES-GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку . Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст. Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему. Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

https://habr.com/ru/articles/1033830/

#double_ratchet #signal_protocol #e2e #endtoend_encryption #react_native #криптография #мессенджер #ecdh #hkdf #web_crypto_api

Как я сделал трёхуровневый кэш сообщений в мессенджере на React Native — и что узнал по дороге

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат. Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой. Я разбирался с этим несколько месяцев. В итоге пришёл к трёхуровневой архитектуре кэша, которую и хочу разобрать. Это не теория — это код, который сейчас работает в продакшне. Покажу как реализовано, какие были тупики и какие решения оказались критичными.

https://habr.com/ru/articles/1033502/

#react_native #sqlite #кэширование #expo #мессенджер #drizzle_orm #мобильная_разработка #производительность #архитектура #telegram

Как мы написали React Native библиотеку для Яндекс Карт за два дня с Claude

Сначала коротко о том, зачем нам это было нужно. Мы в основном пилим решения для фудтеха, а для мобилок используем React Native (почему, рассказывали тут ). В одном из таких проектов (российская сеть ресторанов по франшизе) нам нужно было прикрутить Яндекс Карты. Изначально хотели взять либу react-native-yamap (респект тем, кто ее делал) — но как выяснилось, она работает только на старой архитектуре RN. После обновления до 0.76 версии, где Fabric стала использоваться по умолчанию, приложения на iOS начали падать: карта не рендерится, события не доходят до JS, приложение крашится при взаимодействии с картой и вот это вот всё. И судя по открытым тикетам, мы не одни, кто столкнулся с этой проблемой. Полезли искать, написал ли кто-то уже библиотеку под новую архитектуру — но либо таких людей нет, либо ни с кем не делятся. Спойлер: мы пока тоже не будем, ещё обкатываем либу на своих проектах — но уже сейчас хотим рассказать, как собрали новый пакет с помощью Claude Code за два дня.

https://habr.com/ru/articles/1004576/

#React_Native #Яндекс_Карты #Fabric #TurboModules #Codegen #Claude #iOS #Android #нативные_модули #новая_архитектура

React Native. Часть 2: Bare Workflow, Expo, стили и платформенные особенности

В первой части мы разобрали эволюцию архитектуры React Native. Теперь перейдем к практическим вопросам: как организован процесс разработки и какие платформенные особенности встретятся в работе. Процесс разработки Выбор между классическим подходом и Expo – одно из первых архитектурных решений в проекте. Разберем оба варианта. Bare React Native Процесс требует настройки окружения (Xcode для iOS, Android Studio для Android). В упрощенном виде процесс запуска приложения для разработки выглядит следующим образом:

https://habr.com/ru/articles/990818/

#React_Native #Expo #EAS #Стилизация #Мобильная_разработка #Bare

Подборка атак через библиотеки: CVE в React Native и не только

Итак, 5 ноября команда JFrog опубликовала предупреждение об уязвимости CVE-2025-11953 в инструментах командной строки проекта React Native Community CLI. React Native — это платформа которую используют тысячи разработчиков для создания мобильных приложений, которые мы видим в App Store или Google Play. А React Native Community CLI через командную строку предоставляет инструменты для разработки и сборки этих приложений, куда как раз и входил злополучный пакет. На первый взгляд, это еще один CVE в длинном списке. Но проблема глубже: уязвимость в популярном пакете может затронуть сотни проектов одновременно и ударить не только по продакшену, но и по устройствам разработчиков и CI-пайплайнам. В статье разберем, как библиотеки из удобных помощников превращаются в точку входа для злоумышленников, почему такие инциденты не решаются простым апдейтом и какие механики атак через зависимости встречаются чаще всего. В конце обсудим дилемму — стоит ли вообще полагаться на сторонние фреймворки или лучше писать нативно. Детали под катом.

https://habr.com/ru/companies/selectel/articles/979572/

#selectel #информационная_безопасность #уязвимости #CVE #информационные_технологии #фреймворки #атаки_на_библиотеки #атаки_на_инфраструктуру #React_Native

Написать приложение без опыта. Часть 1. Вводная

Отпуск, целых две недели, без программирования. К вечеру первого дня уже не знал чем себя занять. Работать мне запретили.. гады. Как ещё может отдыхать программист? Делать новый pet-project. Надеюсь на картинке не я...

https://habr.com/ru/articles/973068/

#flutter #react_native #мобильная_разработка #petproject

Какой фреймворк выбрать для MVP стартапа: опыт разработчика и фаундера

Автор: разработчик и фаундер с опытом запуска стартапов в сферах туризма , HR tech , а сейчас — в музыкальной индустрии . По образованию — Data Scientist , по призванию — Android-разработчик и продукт-менеджер . Работал в крупных продуктах вроде X5 и Uzum , где впервые познакомился с Kotlin Multiplatform Mobile (KMM) . Когда настал момент создавать прототип для своего музыкального стартапа, выбор был очевиден: я уже знал Kotlin , имел боевой опыт с KMM — и хотел быстро двигаться без лишних компромиссов. Но KMM — не единственный путь. На столе были и Flutter , и React Native , и даже классическая нативка . В этой статье я расскажу:

https://habr.com/ru/articles/902336/

#kotlin_multiplatform #android #ios #react_native #flutter #kotlin #software_engineering #multiplatform #startups #startup