Соглашение. Пользовательское соглашение https://onemix.me/#privacy. Политика конфиденциальности onemix.me/privacy, трансграничная передача разобрана в разделе 7.
Про тексты и ошибки. Готовлю с помощью AI и редактирую сам, так что ответственность на мне. Кинь конкретные места с ошибками, поправлю, без споров. Про трансграничную передачу и AI. Тут как раз наоборот, я это не прячу, а спрашиваю явно. При включении Нейроответчика (это облачная AI-функция) всплывает отдельное согласие, дословно:
«Нейроответчик использует облачный ИИ-сервис Anthropic (США). Фрагменты текста сообщения передаются обезличенно по защищённому каналу для генерации ответа. Идентификаторы пользователя, номер телефона и контакты НЕ передаются. Это трансграничная передача данных согласно ст. 12 ФЗ № 152-ФЗ. США не отнесены Роскомнадзором к странам с адекватной защитой данных.»
Без кнопки «Согласен» функция не включается. То есть «новое соглашение при включении AI», про которое ты спрашиваешь, ровно так и работает.
Про «передача в США невозможна». Невозможна без согласия субъекта. С явным информированным согласием по ст. 12 передача в страну без адекватной защиты допустима, это и делает модалка. США не «запрещены», они просто не в списке адекватной защиты, что в тексте согласия прямо и написано.
Про фильтрацию переписки, возраст и злоумышленника. Читать содержимое переписки я не могу, это сквозное шифрование, текст у меня зашифрован. Это осознанный размен, такой же как у Signal и WhatsApp: либо реальное E2E и провайдер не читает, либо модерация контента и тогда это уже не E2E. Среднего нет. Если заведётся злоумышленник, по законному запросу отдам то, что физически есть: метаданные и серверные данные. Содержимое чатов отдать не смогу, ключей нет. В этом любой E2E-мессенджер ровно в такой же лодке.
ИИ анализирует только задачи, переписку не передаем ей. А по закону это трансграничная передача данных, перед использованием есть Согласие или отказ на это. Если отказ то подключается локальная ИИ
Разделю на слои, иначе получится враньё. Переписка полное сквозное шифрование на Double Ratchet, ключи на устройствах. Содержимое чатов я физически расшифровать не могу. Задачи, голоса, бюджеты, OTIF на сервере в открытом виде, потому что сервер обязан проверять ранги и считать кворум. Шифровать то, что движок должен читать, бессмысленно, и я честно написал об этом в статье.
AI-функции (Лира, нейроответчик) опциональны: включаешь их контекст уходит в модель (Claude от Anthropic), не включаешь нет. Про органы: законный судебный запрос обязателен для любого юрлица в РФ. Но отдать я могу только серверные данные и метаданные, не содержимое переписки, ключей у меня нет.
Кому критично ставим на ваш сервер, тогда данные к нам вообще не попадают. По программе on-premise, как писал в предыдущей статье.
Приветствую! Как говорил в одном из постов, веб-версия и десктоп ещё сырые MVP, самое главное это мобильная версия, которую вы можете скачать в Google Play или App Store
Нет, ONEMIX не FOSS. Исходники закрытые, на GitHub публичных репозиториев нет — это коммерческий продукт, разрабатывается под ООО «ПАКС ЛАЙВ». Сквозное шифрование переписки реализовано на открытом протоколе Double Ratchet (тот же что в Signal/WhatsApp) поверх библиотек @noble/* то есть сам криптослой стоит на проверенных open source примитивах, но клиент и сервер закрыты. В планах открыть отдельные модули (например крипто-обёртку) но это не FOSS-проект и таковым не позиционируется.
Хороший вопрос. Если коротко: ONEMIX пока не подпадает под обязанности ОРИ по 374-ФЗ. Реестр ОРИ имеет триггеры по аудитории и функционалу, и пока мы остаёмся в B2B-сегменте с ~100 активных пользователей в коммерческих командах, мы вне периметра.
Когда дойдём до порогов которые формально включают нас в реестр придётся принимать архитектурное решение. Варианты которые я вижу:
Сохранить E2E, отказаться от групповых функций которые делают нас ОРИ — узкая интерпретация закона, риск штрафа но не блокировки
Гибрид: E2E для приватных диалогов, серверное шифрование для бизнес-чатов — тогда «бизнес-режим» (для которого мы и существуем) формально дешифруемый, а приватка остаётся E2E как у Signal/Telegram Secret
Релокация юрлица — выход из российской юрисдикции, но тогда нет смысла позиционироваться как «российский мессенджер»
Текущий приоритет продуктовая зрелость. Юридическую архитектуру допроектируем когда будет угроза попасть в реестр. Это правильный порядок: сначала продукт который кому-то нужен, потом compliance.
По делу пишете. Действительно, в статье нет разбора как работают сами протоколы APNs/FCM на низком уровне persistent TCP-соединения, очереди доставки на стороне Apple/Google, heartbeat’ы, fallback на WNS/Huawei push services. Это отдельная и большая тема. Статья про другое про клиентскую обработку push в кросс-платформенном приложении на React Native, и про edge cases которые ловятся в реальном проде (не в туториалах). Признаю что пометка “Сложный” может вводить в заблуждение. Имел в виду “сложно отладить”, а не “глубокий разбор протокола”.
Про “костыли в реакте” не спорю. iOS и Android устроены настолько по-разному, что любой кросс-платформенный код для пушей это компромисс. Нативная реализация на Swift/Kotlin будет чище но для соло-разработчика мобильной части это экономически нереалистично. Это в статье как раз упомянул. Если интересен глубокий разбор протокола APNs там реально есть что разобрать (binary protocol legacy, HTTP/2 token-based auth, universal payload, app-thinning). Возможно сделаю отдельной статьёй, тема большая.
Понимаю вашу боль. Я и сам с грустью смотрю на то как современный десктоп массово ушёл в Electron-обёртки. WhatsApp на UWP был действительно лучше нынешней веб-версии, тут не поспоришь. Но давайте честно. Я соло-разработчик, делаю мессенджер на React Native для iOS и Android. Десктоп нужен потому что часть моих пользователей пишут с компьютера. У меня два варианта:
Не делать десктоп вообще. Часть пользователей теряется.
Сделать на Electron за неделю, переиспользовав UI-логику с веба.
Нанять нативного Windows/macOS-разработчика и делать полгода отдельные приложения на UWP/Swift/AppKit.
Третий вариант для меня экономически невозможен. Я выбрал второй. Это не “потому что Electron хороший”, это “потому что 50МБ лишней памяти у пользователя меньшее зло чем отсутствие десктопа вовсе”. Согласен что нативное приложение всегда будет лучше для конечного пользователя. И если бы у меня была команда я бы туда смотрел. Пока команды нет, Electron это компромисс с открытыми глазами.
P.S. Про IPC в рамках одного приложения это болезненная история у меня тоже. main process и renderer process с разными ограничениями api это не самая чистая архитектура, согласен. Но обходное решение всегда находится. В статье я как раз про несколько таких рассказал.
Полностью соглашусь. Присяжные это живой контур между формальным законом и текущей моралью общества. LLM этого делать не может в принципе, она работает с зафиксированными паттернами. В нашей нише это пока не критично нормы «выполнил работу, получи деньги» стабильны десятилетиями. Но для дел где общественная мораль быстро меняется, ИИ выдаст устаревшее решение с твёрдой уверенностью. Это надо помнить.
Ссылка на 5 эпизод точная. Я этот сериал смотрел и сцена с эмуляцией присяжных как раз и запомнилась тем что граница тонкая. От «помощник судьи» до «судья» дорожка короче чем кажется. Соглашусь с двумя пунктами разом. ИИ это действительно кубики с тюнингом просто подкручены в сторону того что было в обучающих данных. И арбитраж в нашей среде это действительно не вынесение вердикта в правовом смысле, а попытка авторитетом разрулить чтобы стороны сами договорились. Я это в статье не очень акцентировал, но по сути так оно и есть. Теперь про slippery slope это реальный риск. Я о нём думал, поэтому в систему встроены вещи которые специально мешают скатываться:
Вердикты не имеют юридической силы это в правилах, в дисклеймере, в самом сообщении пользователю при первом запуске. Стороны соглашаются добровольно, и любая может уйти в обычный суд по той же фактуре. Опция «вызвать живого админа» доступна на любом этапе. Не «оспорить вердикт» (это можно), а прямо вмешаться в процесс если ИИ ушёл в неадекват. Кнопка большая.
Это коммерческий сервис, а не государственная функция. Если завтра ИИ выдаст что-то странное в нашем боте, последствия недовольный клиент пишет в чат и я разбираюсь. Если бы это была государственная система последствия другие. Но вы правы в общем смысле: каждый кто строит автоматизацию решений должен помнить «контупер сказал». Я стараюсь помнить. Не уверен что у всех получится так же.
Справедливо) Один кейс это не статистика, это анекдот. В статье я об этом сказал: «прогнал ещё 4 старых дела в 3 из 4 совпало». То есть 4 из 5, что тоже не выборка для серьёзной работы. Для нормальной валидации нужны хотя бы сотни кейсов с блайнд-сравнением, и над этим думаем. Пока что наш единственный честный аргумент это что в типовых спорах (фриланс не сдал, клиент не оплатил) ИИ выдаёт логичные решения за минуты вместо недель. А «логичные» не означает «всегда правильные» означает «обычно те же что вынес бы здравомыслящий арбитр».
Кубики тоже выдают результат за секунды, но логику в нём искать сложно)
Очень точное наблюдение про прецедентное право я сам долго думал как это описать, и в статье обошёл, потому что объяснение получалось длинным. По сути да, любой LLM в режиме арбитража работает как common-law судья: ищет похожие паттерны в обучающих данных и в векторной памяти прошлых дел, применяет логику аналогии. Из-за этого ИИ-арбитр будет систематически лучше на типовых кейсах (фриланс не сдал работу, клиент не оплатил, недопонимание по объёму) там паттернов хватает и в training set’е, и в нашей базе. И систематически хуже на нестандартных кейсах где нужно применить право к ситуации которая раньше не разбиралась. Кстати, по нашей статистике это сейчас примерно 80/20: 80% дел типовые, 20% уникальные. Первые ИИ закрывает быстро и качественно, вторые мы перенаправляем живому арбитру. Так мы и расслаиваем поток в практике.
По второму вопросу соглашусь полностью. В классическом арбитраже/суде половина работы это сбор доказательств: запросы в банки, экспертизы, повестки, допрос свидетелей. У нас этого нет. ИИ работает с тем что стороны принесли сами. В этом ограничение модели. Поэтому в статье я честно пишу что ИИ не заменит сложные кейсы. Реальная судебная система не сводится к «вынеси вердикт по фактам» она про правоприменение, доказывание, процессуальную справедливость. Этих частей у нас нет и быть не может. Что ИИ хорошо делает: быстрый формальный разбор по уже собранным сторонами материалам. Что не делает: расследование. Это две разные задачи, и наш бот закрывает только первую.
Спасибо за дотошность, отвечу по пунктам.
Соглашение. Пользовательское соглашение https://onemix.me/#privacy. Политика конфиденциальности onemix.me/privacy, трансграничная передача разобрана в разделе 7.
Про тексты и ошибки. Готовлю с помощью AI и редактирую сам, так что ответственность на мне. Кинь конкретные места с ошибками, поправлю, без споров. Про трансграничную передачу и AI. Тут как раз наоборот, я это не прячу, а спрашиваю явно. При включении Нейроответчика (это облачная AI-функция) всплывает отдельное согласие, дословно:
«Нейроответчик использует облачный ИИ-сервис Anthropic (США). Фрагменты текста сообщения передаются обезличенно по защищённому каналу для генерации ответа. Идентификаторы пользователя, номер телефона и контакты НЕ передаются. Это трансграничная передача данных согласно ст. 12 ФЗ № 152-ФЗ. США не отнесены Роскомнадзором к странам с адекватной защитой данных.»
Без кнопки «Согласен» функция не включается. То есть «новое соглашение при включении AI», про которое ты спрашиваешь, ровно так и работает.
Про «передача в США невозможна». Невозможна без согласия субъекта. С явным информированным согласием по ст. 12 передача в страну без адекватной защиты допустима, это и делает модалка. США не «запрещены», они просто не в списке адекватной защиты, что в тексте согласия прямо и написано.
Про фильтрацию переписки, возраст и злоумышленника. Читать содержимое переписки я не могу, это сквозное шифрование, текст у меня зашифрован. Это осознанный размен, такой же как у Signal и WhatsApp: либо реальное E2E и провайдер не читает, либо модерация контента и тогда это уже не E2E. Среднего нет. Если заведётся злоумышленник, по законному запросу отдам то, что физически есть: метаданные и серверные данные. Содержимое чатов отдать не смогу, ключей нет. В этом любой E2E-мессенджер ровно в такой же лодке.
ИИ анализирует только задачи, переписку не передаем ей. А по закону это трансграничная передача данных, перед использованием есть Согласие или отказ на это. Если отказ то подключается локальная ИИ
Разделю на слои, иначе получится враньё. Переписка полное сквозное шифрование на Double Ratchet, ключи на устройствах. Содержимое чатов я физически расшифровать не могу. Задачи, голоса, бюджеты, OTIF на сервере в открытом виде, потому что сервер обязан проверять ранги и считать кворум. Шифровать то, что движок должен читать, бессмысленно, и я честно написал об этом в статье.
AI-функции (Лира, нейроответчик) опциональны: включаешь их контекст уходит в модель (Claude от Anthropic), не включаешь нет. Про органы: законный судебный запрос обязателен для любого юрлица в РФ. Но отдать я могу только серверные данные и метаданные, не содержимое переписки, ключей у меня нет.
Кому критично ставим на ваш сервер, тогда данные к нам вообще не попадают. По программе on-premise, как писал в предыдущей статье.
Тег добавлю
250+ человек уже доверяют и активно пользуются
Приветствую! Как говорил в одном из постов, веб-версия и десктоп ещё сырые MVP, самое главное это мобильная версия, которую вы можете скачать в Google Play или App Store
Будем верить все вместе только в самое хорошее и идти вперед!
Нет, ONEMIX не FOSS. Исходники закрытые, на GitHub публичных репозиториев нет — это коммерческий продукт, разрабатывается под ООО «ПАКС ЛАЙВ». Сквозное шифрование переписки реализовано на открытом протоколе Double Ratchet (тот же что в Signal/WhatsApp) поверх библиотек @noble/* то есть сам криптослой стоит на проверенных open source примитивах, но клиент и сервер закрыты. В планах открыть отдельные модули (например крипто-обёртку) но это не FOSS-проект и таковым не позиционируется.
Да, десктоп ещё в MVP, больше всего проработаны мобильные версии в гугл плей и апп стор
Пока что сервис на старте и на данном этапе мы не планируем брать плату за использование бизнес-режима.
Хороший вопрос. Если коротко: ONEMIX пока не подпадает под обязанности ОРИ по 374-ФЗ. Реестр ОРИ имеет триггеры по аудитории и функционалу, и пока мы остаёмся в B2B-сегменте с ~100 активных пользователей в коммерческих командах, мы вне периметра.
Когда дойдём до порогов которые формально включают нас в реестр придётся принимать архитектурное решение. Варианты которые я вижу:
Сохранить E2E, отказаться от групповых функций которые делают нас ОРИ — узкая интерпретация закона, риск штрафа но не блокировки
Гибрид: E2E для приватных диалогов, серверное шифрование для бизнес-чатов — тогда «бизнес-режим» (для которого мы и существуем) формально дешифруемый, а приватка остаётся E2E как у Signal/Telegram Secret
Релокация юрлица — выход из российской юрисдикции, но тогда нет смысла позиционироваться как «российский мессенджер»
Текущий приоритет продуктовая зрелость. Юридическую архитектуру допроектируем когда будет угроза попасть в реестр. Это правильный порядок: сначала продукт который кому-то нужен, потом compliance.
Да
Да
По делу пишете. Действительно, в статье нет разбора как работают сами протоколы APNs/FCM на низком уровне persistent TCP-соединения, очереди доставки на стороне Apple/Google, heartbeat’ы, fallback на WNS/Huawei push services. Это отдельная и большая тема. Статья про другое про клиентскую обработку push в кросс-платформенном приложении на React Native, и про edge cases которые ловятся в реальном проде (не в туториалах). Признаю что пометка “Сложный” может вводить в заблуждение. Имел в виду “сложно отладить”, а не “глубокий разбор протокола”.
Про “костыли в реакте” не спорю. iOS и Android устроены настолько по-разному, что любой кросс-платформенный код для пушей это компромисс. Нативная реализация на Swift/Kotlin будет чище но для соло-разработчика мобильной части это экономически нереалистично. Это в статье как раз упомянул. Если интересен глубокий разбор протокола APNs там реально есть что разобрать (binary protocol legacy, HTTP/2 token-based auth, universal payload, app-thinning). Возможно сделаю отдельной статьёй, тема большая.
Понимаю вашу боль. Я и сам с грустью смотрю на то как современный десктоп массово ушёл в Electron-обёртки. WhatsApp на UWP был действительно лучше нынешней веб-версии, тут не поспоришь. Но давайте честно. Я соло-разработчик, делаю мессенджер на React Native для iOS и Android. Десктоп нужен потому что часть моих пользователей пишут с компьютера. У меня два варианта:
Не делать десктоп вообще. Часть пользователей теряется.
Сделать на Electron за неделю, переиспользовав UI-логику с веба.
Нанять нативного Windows/macOS-разработчика и делать полгода отдельные приложения на UWP/Swift/AppKit.
Третий вариант для меня экономически невозможен. Я выбрал второй. Это не “потому что Electron хороший”, это “потому что 50МБ лишней памяти у пользователя меньшее зло чем отсутствие десктопа вовсе”. Согласен что нативное приложение всегда будет лучше для конечного пользователя. И если бы у меня была команда я бы туда смотрел. Пока команды нет, Electron это компромисс с открытыми глазами.
P.S. Про IPC в рамках одного приложения это болезненная история у меня тоже. main process и renderer process с разными ограничениями api это не самая чистая архитектура, согласен. Но обходное решение всегда находится. В статье я как раз про несколько таких рассказал.
Полностью соглашусь. Присяжные это живой контур между формальным законом и текущей моралью общества. LLM этого делать не может в принципе, она работает с зафиксированными паттернами. В нашей нише это пока не критично нормы «выполнил работу, получи деньги» стабильны десятилетиями. Но для дел где общественная мораль быстро меняется, ИИ выдаст устаревшее решение с твёрдой уверенностью. Это надо помнить.
Хороший аргумент, спасибо что подсветили.
Ссылка на 5 эпизод точная. Я этот сериал смотрел и сцена с эмуляцией присяжных как раз и запомнилась тем что граница тонкая. От «помощник судьи» до «судья» дорожка короче чем кажется. Соглашусь с двумя пунктами разом. ИИ это действительно кубики с тюнингом просто подкручены в сторону того что было в обучающих данных. И арбитраж в нашей среде это действительно не вынесение вердикта в правовом смысле, а попытка авторитетом разрулить чтобы стороны сами договорились. Я это в статье не очень акцентировал, но по сути так оно и есть. Теперь про slippery slope это реальный риск. Я о нём думал, поэтому в систему встроены вещи которые специально мешают скатываться:
Вердикты не имеют юридической силы это в правилах, в дисклеймере, в самом сообщении пользователю при первом запуске. Стороны соглашаются добровольно, и любая может уйти в обычный суд по той же фактуре. Опция «вызвать живого админа» доступна на любом этапе. Не «оспорить вердикт» (это можно), а прямо вмешаться в процесс если ИИ ушёл в неадекват. Кнопка большая.
Это коммерческий сервис, а не государственная функция. Если завтра ИИ выдаст что-то странное в нашем боте, последствия недовольный клиент пишет в чат и я разбираюсь. Если бы это была государственная система последствия другие. Но вы правы в общем смысле: каждый кто строит автоматизацию решений должен помнить «контупер сказал». Я стараюсь помнить. Не уверен что у всех получится так же.
Справедливо) Один кейс это не статистика, это анекдот. В статье я об этом сказал: «прогнал ещё 4 старых дела в 3 из 4 совпало». То есть 4 из 5, что тоже не выборка для серьёзной работы. Для нормальной валидации нужны хотя бы сотни кейсов с блайнд-сравнением, и над этим думаем. Пока что наш единственный честный аргумент это что в типовых спорах (фриланс не сдал, клиент не оплатил) ИИ выдаёт логичные решения за минуты вместо недель. А «логичные» не означает «всегда правильные» означает «обычно те же что вынес бы здравомыслящий арбитр».
Кубики тоже выдают результат за секунды, но логику в нём искать сложно)
Очень точное наблюдение про прецедентное право я сам долго думал как это описать, и в статье обошёл, потому что объяснение получалось длинным. По сути да, любой LLM в режиме арбитража работает как common-law судья: ищет похожие паттерны в обучающих данных и в векторной памяти прошлых дел, применяет логику аналогии. Из-за этого ИИ-арбитр будет систематически лучше на типовых кейсах (фриланс не сдал работу, клиент не оплатил, недопонимание по объёму) там паттернов хватает и в training set’е, и в нашей базе. И систематически хуже на нестандартных кейсах где нужно применить право к ситуации которая раньше не разбиралась. Кстати, по нашей статистике это сейчас примерно 80/20: 80% дел типовые, 20% уникальные. Первые ИИ закрывает быстро и качественно, вторые мы перенаправляем живому арбитру. Так мы и расслаиваем поток в практике.
По второму вопросу соглашусь полностью. В классическом арбитраже/суде половина работы это сбор доказательств: запросы в банки, экспертизы, повестки, допрос свидетелей. У нас этого нет. ИИ работает с тем что стороны принесли сами. В этом ограничение модели. Поэтому в статье я честно пишу что ИИ не заменит сложные кейсы. Реальная судебная система не сводится к «вынеси вердикт по фактам» она про правоприменение, доказывание, процессуальную справедливость. Этих частей у нас нет и быть не может. Что ИИ хорошо делает: быстрый формальный разбор по уже собранным сторонами материалам. Что не делает: расследование. Это две разные задачи, и наш бот закрывает только первую.
Я указал в статье что это не настоящий третейский судья, а больше развлечение для участников группы и не более
С одной стороны ИИ выслушивает обе стороны, задает им вопросы и так далее. С другой стороны, это просто ИИ внутри группы и не более...