Дайте разобраться и запустить, позже открою код, но без тех модулей что будут составлять коммерческую тайну. Судя по скорости разработки не раньше чем через год.
Нет, идея в том что сервер выступает связующим звеном.
Немного подробней, у команды организуется сеть по совместной работе. Каждый видит каждого и все что есть у каждого полная копия других, конечно то что они выделил в совместную работу. Это удобно при работе с проектами, задачами и заметками. Сервер только арбитр по инкрементам, т.е. он следить за тем кто первый кто последний, полностью не обладая знаниями о содержании. Так мы достигаем и конфиденциальности и совместной работы.
Опять же идея пока находится в теоретическом поле и требует детально проработки.
К сожалению места расхватали очень быстро, я выделил всего 100 для бета тестеров. Сейчас проведем ревизию мертвый и не достойных и я думаю места еще появляться и скорее всего мы увеличим лимит. Следите за новостями: https://t.me/yttri_app
я так понимаю на сайте вы это увидели? Ну сайт еще сыроват и начал создаваться тогда когда мы еще использовали концепцию по файлового хранения для упрощения, как это сделано в Obsidian. Но позже отказались от этой идеи. Хотя формат данных сохранили, там действительно markdown. Но так как все хранится в БД SQLite сравнение и командная работа упрощается. Тем более что концепция командной работы это облако, т.е. то что находится в совместной работе обрабатывается сервером с локальной копией и прямой синхнонизацией и версионирование на лету, чтобы не допустить наложений. Концепция уже есть, но детально ее я еще не продумывал. Как референс могу привести пример командной работы над заметками в icloud.
Да и в этом суть. В приложении есть такая сущность как связь. Вы можете явно связывать любые объекты через связи самостоятельно, а также в этом вам помогает AI.
Граф строится НЕ только по векторной схожести. Это ключевой момент. Граф использует 9 типов рёбер:
Тип ребра | Вес | Источник
Wiki-ссылки | 1.0 | Явные [[...]] в тексте
Project-связи | 0.9 | Общий project_id
Document links | 0.8 | Связи документов
Task links | 0.8 | Связи задач
Universal links | 0.7 | Ручные N:M связи
Meeting↔Contact | 0.7 | Участники встреч
Mail↔Contact | 0.6 | Участники переписок
Co-tag | 0.3–1.0 | Общие теги
Semantic по score Векторная схожесть
По вашему пример:
«квартальный отчет» и «зарплатный проект» — они будут связаны если:
Оба принадлежат одному проекту (project edge, вес 0.9)
Пользователь вручную создал связь (universal link, вес 0.7)
Есть общие теги, например «финансы» (co-tag edge)
Есть wiki-ссылка из одного в другой (вес 1.0)
Они упоминают одних и тех же людей/контакты
Но вы правы — автоматически эти два документа могут остаться несвязанными, если пользователь не создал явных связей и векторно они далеки. Это реальный gap.
Ответ на ваш вопрос без реальных примеров дать сложно, предлагаю вам подключиться к нашему сообществу в телеграм: https://t.me/yttri_chat. Я смогу вам ответить там подробно и с примерами в виде скриншотов.
Мы запланировали серию из 8 статей, с подробными примерами и описаниями.
Версия может работать у вас бесконечно и бесплатно, но без таких важных функций как AI, RAG и еще нескольких. Вы правы это нужно было бы обозначить на сайте явно.
На текущий момент идет бета тестирование, всем бетатестерам приложение будет доступно бесплатно как минимум до 1 мая 2026 года. А если все пойдет хорошо бетатестеры смогут получить приложение на пожизненное пользование бесплатно. Потому количество бетатестеров мы и ограничили, но места пока еще есть.
По поводу раскрытия кода, я принял решение, что этого не будет и суть этого решения в том, что я вложил очень много интеллектуального труда в проектирование и создание основных алгоритмов работы с AI и я не хочу делиться этим с миром бесплатно.
В облако точно не переедем, это главная суть проекта. В будущем у пользователей появится возможность облачной синхронизации, как через шифрование на наших серверах, так и через собственные типа icloude, google или yandex диск. Но это большая работа, а проект уже хотелось запустить. Также впереди у нас разработка командной работы и еще очень много планов.
Риски закрытия проекта или переезд в другое государство есть у всех проектов кроме государственных и даже у них риск закрытия существует. А открытый код это тоже не панацея очень много проектов за последние несколько лет отказались от open source.
Еще раз спасибо за ваш ответ, он был действительно полезным.
Думаю что по удобству Tauri мне ближе, так как имею огромный опыт в Web разработке могу слепить что угодно. А вот с iced скажем честно я мало знаком, только смотрел и делал небольшие работы. Думаю что как и большинство нативных UI изучив его подробно можно делать интересные вещи. Но мне было проще идти через знакомый html, css, js (ts).
Чистого и глубокого исследования рынка я не делал, смотрел на то что есть в приложениях управления знаниями. Много использовал Obsidian и понял что мне очень много чего не хватает, и пытаться набивать это плагинами тоже не очень то получалось. В итоге, примерно год назад я задумался о том что было бы неплохо иметь помощника который с помощью LLM может находит мне отрывки знаний, соединять их воедино. После я подумал что не только заметками и задачами живу, есть еще много почты с разных ящиков, встречи на которых много всего обсуждается и иногда через день или два сложно вспомнить что было в деталях. После первых тестов, примерно спустя полгода я задумался о том что часто ищу информацию в корпоративном confluence и поисковый движок там не очень то хорошо, понял что могу это интегрировать и как хвостик понял что и Jira можно прикрутить.
Есть еще много идей которые хотелось бы реализовать, это и облачная синхронизация и командная работа и собственная модель. Идей полно, нужно финансирование и время.
Особенно хотел бы отметить логику работы AI. Тут есть ряд инновационных решений, я не стал использовать популярный https://docs.langchain.com/, а продумал архитектуру и написал свой движок.
Да, как раз релизнули реализацию на Rust + Candle, так что с ONNX можно не мучаться :) Сейчас пока всё работает на safetensors (f16/f32), это родной формат для стека. Насчет GGUF — мысль интересная ради квантования (чтобы модель меньше весила и быстрее крутилась на CPU), возможно, в будущем добавим поддержку, если будет запрос на запуск на совсем слабом железе. Но пока фокус на стабильной работе текущей версии. Да и для такой маленькой модели как GigaAM это не очень актуально.
Поймали баг в candle пришлось сделать форк https://github.com/askidmobile/candle, после всех тестов добавлю в основную репу RustASR. Проблема в том что Rust ловит panic при определенных событиях, чтобы не костылить было принято решение сделать форк и провести тестирование. 2 дня полет нормальный.
Спасибо за совет, обязательно сделаю перевод как дойдут руки. А вот сравнение с другими TTS это точно не ко мне, пусть авторы моделей этим занимают. Полагаю не нужно отбирать у них хлеб, да и изощренных способов показать что их TTS лучше они точно знают побольше моего. Одно могу сказать, на текущий момент из OpenSource TTS Qwen3-TTS прям очень хороша.
Дайте разобраться и запустить, позже открою код, но без тех модулей что будут составлять коммерческую тайну. Судя по скорости разработки не раньше чем через год.
Код закрытый, выход в интернет нужен для авторизации, загрузке моделей и проверки подписки раз в 7 дней.
Еще в разработке, есть бета портал там работают баг репорты, можно туда.
Ну или в телеграм в комьюнити группу.
Нет, идея в том что сервер выступает связующим звеном.
Немного подробней, у команды организуется сеть по совместной работе. Каждый видит каждого и все что есть у каждого полная копия других, конечно то что они выделил в совместную работу. Это удобно при работе с проектами, задачами и заметками. Сервер только арбитр по инкрементам, т.е. он следить за тем кто первый кто последний, полностью не обладая знаниями о содержании. Так мы достигаем и конфиденциальности и совместной работы.
Опять же идея пока находится в теоретическом поле и требует детально проработки.
Вы правы, первая сотня ушла очень быстро.
К сожалению места расхватали очень быстро, я выделил всего 100 для бета тестеров. Сейчас проведем ревизию мертвый и не достойных и я думаю места еще появляться и скорее всего мы увеличим лимит. Следите за новостями: https://t.me/yttri_app
я так понимаю на сайте вы это увидели? Ну сайт еще сыроват и начал создаваться тогда когда мы еще использовали концепцию по файлового хранения для упрощения, как это сделано в Obsidian. Но позже отказались от этой идеи. Хотя формат данных сохранили, там действительно markdown. Но так как все хранится в БД SQLite сравнение и командная работа упрощается. Тем более что концепция командной работы это облако, т.е. то что находится в совместной работе обрабатывается сервером с локальной копией и прямой синхнонизацией и версионирование на лету, чтобы не допустить наложений. Концепция уже есть, но детально ее я еще не продумывал. Как референс могу привести пример командной работы над заметками в icloud.
но у нас не хранятся в .md =)))))
Подробней эти аспекты я разберу в будущих статьях.
Ответить в комментарии не просто потому как он получится очень длинным.
Подождите следующих статей, я все подробно распишу.
Да и в этом суть. В приложении есть такая сущность как связь. Вы можете явно связывать любые объекты через связи самостоятельно, а также в этом вам помогает AI.
Постараюсь ответить кратко.
Что касается графа:
Граф строится НЕ только по векторной схожести. Это ключевой момент. Граф использует 9 типов рёбер:
Тип ребра | Вес | Источник
Wiki-ссылки | 1.0 | Явные [[...]] в тексте
Project-связи | 0.9 | Общий project_id
Document links | 0.8 | Связи документов
Task links | 0.8 | Связи задач
Universal links | 0.7 | Ручные N:M связи
Meeting↔Contact | 0.7 | Участники встреч
Mail↔Contact | 0.6 | Участники переписок
Co-tag | 0.3–1.0 | Общие теги
Semantic по score Векторная схожесть
По вашему пример:
«квартальный отчет» и «зарплатный проект» — они будут связаны если:
Оба принадлежат одному проекту (project edge, вес 0.9)
Пользователь вручную создал связь (universal link, вес 0.7)
Есть общие теги, например «финансы» (co-tag edge)
Есть wiki-ссылка из одного в другой (вес 1.0)
Они упоминают одних и тех же людей/контакты
Но вы правы — автоматически эти два документа могут остаться несвязанными, если пользователь не создал явных связей и векторно они далеки. Это реальный gap.
Ответ на ваш вопрос без реальных примеров дать сложно, предлагаю вам подключиться к нашему сообществу в телеграм: https://t.me/yttri_chat. Я смогу вам ответить там подробно и с примерами в виде скриншотов.
Мы запланировали серию из 8 статей, с подробными примерами и описаниями.
В планах, и мобильная версия тоже.
Версия может работать у вас бесконечно и бесплатно, но без таких важных функций как AI, RAG и еще нескольких. Вы правы это нужно было бы обозначить на сайте явно.
На текущий момент идет бета тестирование, всем бетатестерам приложение будет доступно бесплатно как минимум до 1 мая 2026 года. А если все пойдет хорошо бетатестеры смогут получить приложение на пожизненное пользование бесплатно. Потому количество бетатестеров мы и ограничили, но места пока еще есть.
По поводу раскрытия кода, я принял решение, что этого не будет и суть этого решения в том, что я вложил очень много интеллектуального труда в проектирование и создание основных алгоритмов работы с AI и я не хочу делиться этим с миром бесплатно.
В облако точно не переедем, это главная суть проекта. В будущем у пользователей появится возможность облачной синхронизации, как через шифрование на наших серверах, так и через собственные типа icloude, google или yandex диск. Но это большая работа, а проект уже хотелось запустить. Также впереди у нас разработка командной работы и еще очень много планов.
Риски закрытия проекта или переезд в другое государство есть у всех проектов кроме государственных и даже у них риск закрытия существует. А открытый код это тоже не панацея очень много проектов за последние несколько лет отказались от open source.
Еще раз спасибо за ваш ответ, он был действительно полезным.
Думаю что по удобству Tauri мне ближе, так как имею огромный опыт в Web разработке могу слепить что угодно. А вот с iced скажем честно я мало знаком, только смотрел и делал небольшие работы. Думаю что как и большинство нативных UI изучив его подробно можно делать интересные вещи. Но мне было проще идти через знакомый html, css, js (ts).
Чистого и глубокого исследования рынка я не делал, смотрел на то что есть в приложениях управления знаниями. Много использовал Obsidian и понял что мне очень много чего не хватает, и пытаться набивать это плагинами тоже не очень то получалось. В итоге, примерно год назад я задумался о том что было бы неплохо иметь помощника который с помощью LLM может находит мне отрывки знаний, соединять их воедино. После я подумал что не только заметками и задачами живу, есть еще много почты с разных ящиков, встречи на которых много всего обсуждается и иногда через день или два сложно вспомнить что было в деталях. После первых тестов, примерно спустя полгода я задумался о том что часто ищу информацию в корпоративном confluence и поисковый движок там не очень то хорошо, понял что могу это интегрировать и как хвостик понял что и Jira можно прикрутить.
Есть еще много идей которые хотелось бы реализовать, это и облачная синхронизация и командная работа и собственная модель. Идей полно, нужно финансирование и время.
Особенно хотел бы отметить логику работы AI. Тут есть ряд инновационных решений, я не стал использовать популярный https://docs.langchain.com/, а продумал архитектуру и написал свой движок.
Да, как раз релизнули реализацию на Rust + Candle, так что с ONNX можно не мучаться :) Сейчас пока всё работает на safetensors (f16/f32), это родной формат для стека. Насчет GGUF — мысль интересная ради квантования (чтобы модель меньше весила и быстрее крутилась на CPU), возможно, в будущем добавим поддержку, если будет запрос на запуск на совсем слабом железе. Но пока фокус на стабильной работе текущей версии. Да и для такой маленькой модели как GigaAM это не очень актуально.
Поймали баг в candle пришлось сделать форк https://github.com/askidmobile/candle, после всех тестов добавлю в основную репу RustASR. Проблема в том что Rust ловит panic при определенных событиях, чтобы не костылить было принято решение сделать форк и провести тестирование. 2 дня полет нормальный.
Пробовал на другом проекте, качество так себе.
Доберусь, сделаю релиз, а пока только собирать самостоятельно.
Спасибо за совет, обязательно сделаю перевод как дойдут руки. А вот сравнение с другими TTS это точно не ко мне, пусть авторы моделей этим занимают. Полагаю не нужно отбирать у них хлеб, да и изощренных способов показать что их TTS лучше они точно знают побольше моего. Одно могу сказать, на текущий момент из OpenSource TTS Qwen3-TTS прям очень хороша.