Hacker News Digest

Keyhive исследует децентрализованное управление доступом для local-приложений, где каждый участник имеет полную копию данных. Традиционные облачные системы аутентификации не подходят, так как требуют центрального сервера. Вместо этого предлагается подход, аналогичный Signal для документов: безопасное сотрудничество без ущерба для удобства, с чёткими правилами доступа даже при конфликтующих изменениях.

Сейчас многие local-приложения полагаются на «безопасность через неясность» — например, доступ к документу Automerge по ID, что рискованно при утечке. Keyhive совмещает самосертификацию, мощь облачных решений и контроль пользователя, позволяя гибко управлять правами (чтение/запись) и отзывать доступ, отслеживая историю изменений даже в офлайн-режиме. Это важно для сценариев вроде планирования событий или юридических документов, где ошибки в доступе критичны.

• Обсуждение статьи о протоколе BeeKEM (децентрализованный аналог TreeKEM из MLS) для использования в распределенном чат-приложении.
• Несколько пользователей отметили необычный и отвлекающий дизайн сайта с публикацией (наклонная карточка, подчеркивания).
• Высказано положительное мнение о работе исследовательской группы Ink and Switch и их альтернативном подходе к разработке ПО.
• Предложено рассмотреть использование CRDT поверх протокола Nostr как уже готового решения с похожими свойствами.
• Запрос к автору предложения разъяснить техническую реализацию использования Nostr для аудитории, не знакомой с этим протоколом.

• CRDTs предлагаются как техническое решение для бесконфликтной синхронизации данных, но их реализация сложна и требует глубоких знаний.
• Основными барьерами для популярности local-first приложений называются экономические причины: SaaS-модели более прибыльны, а монетизация офлайн-приложений затруднена.
• Многие пользователи не видят ценности в офлайн-работе из-за повсеместного доступа к интернету, что снижает мотивацию разработчиков.
• Синхронизация и совместная работа требуют серверной инфраструктуры, что противоречит идее локальности и усложняет архитектуру.
• Разработчики сталкиваются с техническими сложностями, отсутствием готовых библиотек и необходимостью решать проблемы конфликтов данных.

Zedless — форк редактора Zed, ориентированный на приватность и локальную разработку (без облака). Проект в стадии WIP.

• Пользователи спорят о необходимости форка Zed без AI, телеметрии и облачных сервисов: одни рады приватной версии, другие считают её преждевременной.
• Сторонники отмечают: официальный Zed уже позволяет отключить AI и телеметрию, так что форк может лишь фрагментировать сообщество.
• Автор форка (zedless-editor) последовательно вырезает телеметрию, облачные AI, авто-обновления и кнопку входа, но пока изменений всего ~20 коммитов против 30 000 в оригинале.
• Некоторые хотят, чтобы эти «выключатели» просто добавили в основной репозиторий как флаги компиляции, избегая форка.
• В дискуссии всплывают сравнения с Chromium/Chrome, IO.js/Node.js и опасения по поводу товарных знаков и хостинга на GitHub.

Whispering — микросервис в репозитории epicenter-so/epicenter, каталог apps/whispering.
Предназначен для быстрого распознавания речи через OpenAI Whisper: принимает аудио-файл, возвращает текст.

Ключевые файлы

• main.py — FastAPI-endpoint /transcribe (POST, multipart/form-data).
• requirements.txt — fastapi, uvicorn, openai-whisper.
• Dockerfile — лёгкий образ на python:3.11-slim, порт 8000.

Запуск

docker build -t whispering .
docker run -p 8000:8000 whispering

или

pip install -r requirements.txt
uvicorn main:app --host 0.0.0.0 --port 8000

Использование

curl -F "file=@audio.mp3" http://localhost:8000/transcribe

Ответ: {"text": "распознанный текст"}.

• Пользователи делятся «костыльными», но рабочими схемами диктовки на Linux и обсуждают, как локально запускать Whisper/Parakeet без облаков.
• Epicenter продвигает идею «local-first»: plaintext + SQLite, прозрачные данные, открытый код, совместимые инструменты.
• Постоянно сравнивают альтернативы (VoiceInk, Superwhisper, Wispr Flow, Willow, whishper, Vibe) и жалуются на подписки, задержки, качество и отсутствие разметки динамиков.
• Разработчик Epicenter уже добавляет whisper.cpp и планирует Parakeet; просит помощи в PR для ускорения.

Начав использовать Linear, я углубился в «локально-ориентированные» приложения: клиент хранит полную БД, изменения сначала пишутся локально, а фоновый sync-рантайн рассылает их по WebSocket/GraphQL. Пользователь видит мгновенные обновления без сетевой задержки.

Проанализировав реверс-инжиниринг и доклады команды Linear, я понял: их sync-движок — это месяцы работы, чтобы решить офлайн-режим, конфликты, частичную синхронизацию, миграции схем и безопасность.

В 2025-м экосистема уже готова:

• Electric SQL — Postgres-синхронизация
• PowerSync — корпоративный уровень
• Jazz — «обновляешь локальный state — всё синхронизируется»
• Zero, Instant, Triplit, LiveStore — упрощают разработку

Jazz предлагает CoValues: схема на Zod + автоматическая репликация. Пример:

const Post = co.map({
  title: z.string(),
  comments: co.list(Comment)
});

Меняешь post.title — изменение мгновенно отражается у всех участников.

• Участники обсуждают преимущества и недостатки подходов local-first (Zero, Electric, Jazz, CRDT, PouchDB, Turso и др.).
• Ключевые плюсы: мгновенный UX, офлайн-работа, упрощённая синхронизация через запросы (Zero) и отсутствие конфликтов (CRDT).
• Минусы: рост данных, проблемы разрешения конфликтов, сложность прав и миграций, ограниченная поддержка SSR-ценящих разработчиков.
• Некоторые считают, что SSR всё ещё важен для первой загрузки, но не решает офлайн/коллаборацию.
• Подводный камень: большинство инструментов заточены под веб, хотя мобильные сценарии офлайна выглядят более естественными.

Automerge — это движок синхронизации данных с приоритетом локальной работы, упрощающий создание коллаборативных приложений. Выпущена версия 3.0.

Главное обновление — резкое снижение потребления памяти. Ранее хранение полной истории документов могло приводить к гигабайтам в ОЗУ. В 3.0 память сокращена более чем в 10 раз (иногда значительно больше), что делает Automerge применимым в куда большем числе сценариев.

Также упразднены избыточные API, особенно при работе со строками.

Если вы уже используете Automerge, обновляйтесь: формат файлов тот же, API почти полностью обратно совместим. Подробности — в руководстве по миграции. Если вы ещё не пробовали, сейчас хорошее время — производительность и надежность сильно выросли.

Чтобы узнать, как достигнуты улучшения, читайте далее.

• Улучшенное использование памяти

  • Automerge хранит каждое изменение для офлайн-работы, конфликтов и истории; это требует большого объёма метаданных.
  • Раньше: сжатый колоночный формат «на диске», но при загрузке в память — несжатый вид, из-за чего ОЗУ раздувалось.
  • Теперь: сжатое представление используется и во время выполнения, давая огромную экономию. Пример: вставка «Моби Дика» — было ~700 МБ в v2, стало ~1,3 МБ в v3.
  • Меньше памяти — стабильнее нагруженные сервера синхронизации.
  • Для документов с длинной историей существенно ускорена загрузка (пример: с «не загрузилось за 17 часов» до 9 секунд).

• Упрощение API

  • Два типа строк: «коллаборативные» (сливают правки) и «неколлаборативные».
  • В 1.0: обычные строки для неколлаборативных, класс Text — для коллаборативных.
  • В 2.0 (namespace next): сделали коллаборативный текст по умолчанию — строки для него, RawString для неколлаборативного.
  • В 3.0: закрепили новый подход — удалён Text, API next стал дефолтным; RawString переименован в ImmutableString.

• Попробовать

  • Automerge 3.0 используется по умолчанию в последних @automerge/automerge-repo и @automerge/react (версия 2.1.0).
  • Новичкам — туториал. Существующим кодовым базам — руководство по миграции; если зависите от @automerge/automerge-repo, выполните npm update @automerge/automerge.
  • Проблемы — создавайте issue; вопросы — в Discord.

• Обсуждение вокруг Automerge 3.0: многие впечатлены скачком производительности и «local‑first» подходом к CRDT; сравнивают с Yjs, ElectricSQL, Convex, Zero и интересуются бенчмарками.
• Ключевой апгрейд: сжатое представление данных теперь используется на рантайме — память и время загрузки резко снижены (пример: «Моби Дик»: ~700 МБ → ~1,3 МБ в v3).
• Вопросы по применимости: когда выбирать Automerge/Yjs (совместное редактирование, rich text) vs ElectricSQL (сервер — источник истины, синхронизация приложения). Также интерес к настройкам для «одиночной» кросс‑девайс синхронизации.
• Технические вопросы: структура полурешётки, тип регистра карт (MV-Register vs LWW), поддержка перемещений в деревьях, permissioned-блоки в документе, интеграция с TipTap/ProseMirror, терминальные UI, C/Rust API и состояние C-обёртки.
• Ответы/подсказки: TipTap можно использовать, обернув схему атрибутами Automerge; undo/redo меняется соответствующим образом; ссылки на конфликты в доках; перемещения в деревьях прототипировались (Клепманн), но, похоже, ещё не в основном релизе.
• Практические интересы: какие железо/серверные ресурсы нужны для синка и сколько чтений/записей выдержит; запрос бенчмарков против Yjs и рекомендации по альтернативам (jsonjoy для перформанса).
• Сообщество делится опытом кастомных CRDT, типобезопасностью, бизнес‑правилами и тем, как это вписать в Automerge; часть аудитории всё ещё ищет простое объяснение, «что именно делает» инструмент.