Hacker News Digest

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

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

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

Sequoia ведёт раунд $32 млн для Zed
Суммарное финансирование превысило $42 млн. Четыре года мы строили самый быстрый IDE, но это лишь фундамент. Следующая цель — живое, непрерывное сотрудничество, где разговоры о коде всегда связаны с актуальным состоянием проекта.

Проблема снимков
Git ограничивает обсуждение коммитами и ветками. Между коммитами разработчик работает изолированно; обсуждения в чатах быстро теряют связь с кодом. ИИ-агенты тем более страдают: каждый их шаг требует снимка, что тормозит итерации.

DeltaDB: версионирование операций
Мы создаём DeltaDB — систему, которая фиксирует каждое изменение на уровне операций через CRDT. Она совместима с Git, но позволяет:

• реальное время без снимков;
• пермалинки на символы, выживающие при любом рефакторинге;
• сохранение диалогов и контекста навсегда.

Как это работает
Инженер видит ошибку, кликает на строку и мгновенно получает историю обсуждений, предположений ИИ и решений команды. Всё — внутри IDE, без переключения на внешние сервисы.

Zed и DeltaDB будут open-source с платными опциями. Набираем команду — присоединяйтесь.

• Вокруг Zed спор: продукт вызывает восторг качеством кода и скоростью, но $42 млн от Sequoia вызывают тревогу VC-«эншитификации».
• Главные сомнения: окупится ли такой капитал на «просто редакторе» и не приведёт ли к навязыванию AI-фич и сбора данных.
• Плюсы: финансирование даст ресурсы догнать Cursor/VS Code по AI и снизить трения миграции.
• Тех-фишка: анонс DeltaDB — версионирование уровня каждого символа через CRDT, совместимое с git.
• Часть пользователей уже ищет форки (Zedless) или возвращается к Sublime, опасаясь потери приватности и роста требований.

Алгоритм CRDT для совместного текста

Каждый символ получает уникальный id: site (идентификатор узла) и clock (локальный счётчик, увеличиваемый после каждой операции), а также parent — указатель на предыдущий символ.

• Вставка
  parent ставится на символ перед точкой вставки (null — в начало). Порядок символов задаётся прямым обходом дерева: родители идут раньше потомков.

• Сортировка при одинаковом parent
  Сначала по убыванию counter, затем по site. При вставке перед символом с тем же parent берём его counter + 1.

• Удаление
  id символа попадает в множество удалённых (tombstone). Значение можно забыть, но позиция нужна для корректного порядка.

Оптимизации

1. Последовательные вставки одного узла объединяются в блок: массовая вставка стоит как одна операция.
2. Блоки хранятся в отсортированном массиве; вставка — O(log n) без явного дерева.
3. Удаления группируются диапазонами по site и clock.

Плюсы и минусы

• Плюсы: разумный расход памяти, быстрые запросы/обновления.
• Минусы: сложная логика слияния, только рост метаданных, сборка мусора требует координации.

Интерактивный пример
Четыре пира, задержка сети, редактирование кликом. Исходник — crdt-text-buffer.js.

Полезные ссылки

• josephg.com/blog/crdts-go-brrr/ — эффективная реализация.
• archagon.net/blog/2018/03/24/data-laced-with-history/ — деревья и сборка мусора.

• Обсуждали RGA — CRDT-алгоритм для списков и текста, который Automerge раньше использовал до перехода на FugueMax.
• У RGA есть редкая проблема: при вставке элементов в обратном порядке у разных пользователей возникает чередование.
• Упомянули Eg-Walker — новый подход от Loro.dev, который вызвал интерес у участников.

Итоги постройки синхронизатора и реактивной системы на SQLite

Первый опыт: PGlite + Electric

• PostgreSQL в WASM + Electric даёт точную синхронизацию и LISTEN-реактивность.
• Недостатки: Electric ещё молод, старт до минуты без компакции; PGlite в single-user-режиме течёт памятью и тормозит при росте БД.

Переосмысление задачи

• SQLite-WASM стал зрелым; моё приложение однопользовательское и почти всегда онлайн.
• Значит, достаточно простого собственного решения.

Минимальный синхронизатор

1. При первом запуске клиент вытягивает всё по updated_at.
2. Каждые 2–3 с опрашивает сервер за записями новее этой метки и делает upsert.
3. Локально при каждом UPDATE ставится флаг modified = 1; фоновый процесс отправляет изменения.
4. Для текстов можно добавить CRDT (Yjs) на случай конфликтов.
   Для отслеживания изменений используется триггер, который игнорируется во время синхронизации через таблицу sync_control.

Реактивность на SQLite

• SQLite не умеет LISTEN, но:
  1. Триггер пишет в лог-таблицу пару «таблица + id».
  2. Broadcast Channel API рассылает это в другие вкладки/воркеры.
  3. UI подписывается на канал и перечитывает нужные строки.
• Использую wa-sqlite: стабильно, без сбоев с момента установки.

• Сообщество обсуждает проблемы PGlite и Electric, поэтому Electric развивает Tanstack DB как «sync-native» JS-решение без привязки к бэкенду.
• Предлагаются альтернативы: Evolu, SQLite-Sync, CouchDB и CRDT-движки, но авторы предупреждают, что продакшен-синхронизация сложнее PoC.
• Некоторые отказались от SQLite в браузере вовсе, храня лишь простые индексы и рассылая дельты.
• Участники подчёркивают важность консенсуса (Lamport/CRDT/raft) и отмечают, что гранулярная синхронизация не гарантирует консистентность без транзакций или разрешения конфликтов.
• В итоге рекомендуют использовать готовые движки, а не изобретать велосипед, особенно если нужны офлайн, e2e-шифрование и многопользовательский доступ.

Начав использовать 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; часть аудитории всё ещё ищет простое объяснение, «что именно делает» инструмент.