Denis Evsyukov

Lists: список дел, который хранится у вас

denis@evsyukov.org (Denis Evsyukov) — Sun, 11 Oct 2026 16:05:20 +0300

Пока все мои устройства были от Apple, список дел я вёл в Things . Это красивое и удобное приложение, и менять его я не собирался.

Потом телефон сменился на Android, а приложения для Android у Things нет. Я перепробовал замены: TickTick, 2Do и многие другие. Ни одна не прижилась.

В итоге я сделал свой список дел: с помощью Claude написал Lists . Возможности взяты у 2Do, внешний вид у Things. Данные лежат на устройстве, а синхронизируются через хранилище, которое у вас уже есть: каталог WebDAV или сервер CalDAV.

Что получилось

Lists состоит из трёх частей: приложение для macOS, приложение для Android и веб-интерфейс, который ставится на свой сервер. Все три работают с одними данными и умеют одно и то же; где платформа отличается, это описано в руководстве¹.

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

Интерфейс английский и русский, язык берётся из системы. Оформление светлое и тёмное, по умолчанию как в системе.

Задачи

Обязательно у задачи только название. Остальное добавляется по мере надобности:

заметка в Markdown;
дата начала и срок, день или день со временем;
приоритет и теги;
повтор и напоминание;
вложения и подзадачи.

Даты хранятся без часового пояса: «завтра в 9:00» останется девятью утра и после перелёта. Задача с датой начала в будущем не показывается в «Сегодня», пока этот день не наступит.

Заметки. Markdown оформляется прямо при наборе, отдельного режима просмотра нет. Знаки разметки скрыты везде, кроме абзаца, в котором стоит курсор. Чекбоксы - [ ] переключаются щелчком, таблицы рисуются сеткой, ссылки открываются. Хранится заметка так, как набрана, поэтому поиск и CalDAV видят обычный текст.

Вложения. К задаче прикладывается любое число файлов. Скачанный файл открывается без сети. Изображения и PDF показываются внутри приложения, остальное открывается в программе по умолчанию. Файл можно сохранить наружу или передать в другое приложение.

Подзадачи и проекты. Подзадача — это строка с отметкой и названием, своих дат и заметок у неё нет. Когда нужно больше, задачу можно сделать проектом. Проект появляется в боковой панели со счётчиком «сделано/всего», а его задачи полноценные, со всеми полями и своими подзадачами.

Повторы. Готовые варианты: каждый день, по будням, раз в неделю, раз в две недели, раз в месяц, раз в квартал, раз в год. Своё правило повторяет задачу каждые N дней, недель, месяцев или лет, по выбранным дням недели или, например, в последнюю пятницу месяца. Отсчёт идёт от срока или от дня, когда задача выполнена. Правило заканчивается после N повторов, в назначенный день или не заканчивается вовсе.

«Не буду делать». Задачу, которую делать уже не нужно, а удалять жалко, можно закрыть вторым исходом. Она уходит из работы, остаётся в истории и не попадает в счётчики проекта.

Отмена. Выполненная задача не исчезает сразу: несколько секунд она стоит на месте зачёркнутой, и её можно вернуть. Удаление отменяется, удалённое лежит в корзине, пока её не очистят вручную.

Кроме списков, есть постоянные представления: «Входящие», «Сегодня», «Предстоящие», «Все», «Выполненные», «Не буду делать» и «Корзина». Сохранённые фильтры собирают задачи из разных списков по сроку, спискам, тегам, приоритету, состоянию и словам в тексте. Поиск идёт по названиям и заметкам во всех списках.

Быстрый ввод

Задача должна записываться быстрее, чем забывается. Для этого хватает одной строки:

купить молоко завтра 18:30 !! #дом @Покупки

Получится задача «купить молоко» со сроком на завтра в 18:30, средним приоритетом и тегом «дом» в списке «Покупки». Даты понимаются на русском и английском. То, что приложение распознало, оно показывает плашками до сохранения, а распознавание можно выключить.

Мест, откуда задачу можно добавить, много:

macOS: ⌘N в основном окне, окно поверх любой программы по ⌃⌥Пробел, значок в строке меню со списком задач на сегодня, «Поделиться», меню «Службы» и адрес lists://add?text=…;
Android: кнопка «+», «Поделиться», меню выделенного текста, ярлык на значке приложения, плитка быстрых настроек и виджеты;
веб: поле «Новая задача» в списке.

Окно быстрого ввода начинает заметку с содержимого буфера обмена. Скопировали ссылку, нажали клавишу, набрали название — ссылка уже в заметке. Каждая копия используется один раз, а то, что менеджер паролей пометил скрытым, приложение не читает.

Android

На телефоне Lists выглядит так же, как на Mac, насколько это позволяет экран: крупное название представления, задача в одну строку, карточка задачи выезжает снизу.

Сегодня Задача Быстрый ввод Список Панель списков Настройки

Смахивание вправо выполняет задачу, влево открывает выбор срока. Долгое нажатие открывает меню, а из него включается выбор нескольких задач: их можно разом выполнить, перенести или удалить, и всё действие отменяется одной кнопкой.

На главный экран ставятся два виджета, 2×2 и 4×4. Каждый показывает «Сегодня», «Входящие» или выбранный список, и задачу можно отметить прямо в нём. В шторке можно держать постоянное уведомление с задачами на сегодня и кнопкой «Новая задача».

Напоминания настраиваются на каждом устройстве отдельно: за сколько предупреждать о сроке, в котором часу напоминать о задачах на день, присылать ли сводку дня. И на Android, и на macOS в «Сегодня» можно показать события дня из календарей устройства. Они только читаются и никуда не отправляются.

Синхронизация

Это главная часть приложения. Своего сервера у Lists нет. Устройства обмениваются изменениями через хранилище, от которого нужно только читать, писать, перечислять и удалять файлы. Хранилищ три вида:

Вид	Что лежит в хранилище	Когда выбирать
WebDAV	журнал изменений приложения, передаётся всё	любой сервер WebDAV, в том числе Nextcloud
Папка	то же самое	каталог, который синхронизирует другая программа: Syncthing, iCloud Drive
CalDAV	по одному VTODO на задачу, календарь на список	задачи должны быть видны и в других клиентах CalDAV

Папку умеют приложение для macOS и веб-сервер, на Android этого вида нет.

Как сливаются правки. Каждое поле каждой задачи хранится отдельно и несёт метку времени. Если на телефоне изменили срок, а на компьютере в это время дописали заметку, сохранятся обе правки. Если на двух устройствах изменили одно и то же поле, побеждает более поздняя правка. Итог не зависит от того, в каком порядке изменения дошли: два устройства с одинаковым набором изменений показывают одно и то же².

Что лежит в хранилище. Каждое устройство пишет туда файлы только под своим именем и чужие не трогает. Поэтому двум устройствам нечего делить на сервере, и блокировки не нужны. Вложения лежат отдельно, под именем хеша содержимого. Задача доходит до других устройств раньше своих файлов: синхронизация сначала передаёт поля, показывает результат и только потом берётся за вложения.

CalDAV. Здесь списки становятся календарями, а задачи обычными VTODO, так что их видят Tasks.org, DAVx5 и другие клиенты. Всё, чего в стандарте нет, Lists кладёт в собственное свойство рядом со стандартными. Правки, сделанные в других клиентах, подхватываются, а их свойства сохраняются. Ограничения такие: общие настройки через CalDAV не передаются, вложения ограничены 5 МБ на файл и 20 МБ на задачу. Сервер, который вырезает неизвестные свойства, оставит от задачи только стандартные поля³.

Когда запускается. После правки на устройстве синхронизация идёт через две секунды тишины. Пока приложение открыто, она повторяется раз в минуту и ещё раз при возврате в приложение. На Android запуск после правки отдан системе, поэтому изменение уйдёт, даже если приложение сразу закрыли, а без сети дождётся её появления. Там же синхронизация идёт в фоне раз в 15 минут. Сбой сети ничего не теряет, ошибка синхронизации работе не мешает.

Если подключить к непустому хранилищу устройство, на котором уже есть задачи, приложение спросит, что оставить: слить обе стороны, взять данные хранилища или заменить хранилище данными устройства.

Быстрая доставка

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

Lists сокращает это ожидание уведомлениями. Устройство, которое выгрузило изменения, просит остальные синхронизироваться, и они делают это за несколько секунд. В проекте такой запрос называется толчком.

Данных толчок не несёт. В нём одно слово, sync, а задачи по-прежнему идут через ваше хранилище.

Настраивается это так:

macOS и веб-сервер получают толчки через сервер ntfy , общий https://ntfy.sh или свой. Адрес задаётся в настройках синхронизации, у веб-сервера — в переменной LISTS_PUSH_SERVER.
Android получает толчки через UnifiedPush . На телефон ставится приложение-распространитель, например ntfy, и в настройках синхронизации Lists включается «Синхронизировать сразу после правки на другом устройстве». Работает это и при закрытом приложении.

Об адресах устройства договариваются сами, через то же хранилище: каждое публикует там, куда ему слать толчок. Mac и веб-сервер, которые пользуются одним сервером ntfy, слушают одну тему со случайным именем из 32 знаков, и один запрос будит всех. Телефон остаётся при адресе, который выдал распространитель.

На сервере без входа имя темы — единственная защита. Сервер ntfy при этом видит, когда вы что-то правили, но не видит, что именно. Для своего сервера ntfy с закрытым доступом Lists принимает токен; он хранится в связке ключей macOS или шифруется ключом из Android Keystore.

Толчок необязателен. Запросы уходят уже после синхронизации и её не задерживают, а потерянный толчок означает только то, что изменение придёт по расписанию. При проверке на эмуляторе задача, добавленная на другом устройстве, дошла до телефона с убитым процессом приложения примерно за три секунды⁴.

Телефон, который ограничивает фоновую работу, такие запуски откладывает. В настройках синхронизации Lists показывает, ограничено ли приложение, и предлагает снять ограничение батареи; то же стоит сделать для приложения ntfy.

Веб-интерфейс

Приложения для iOS нет, и вместо него сделан веб-интерфейс. Чисто браузерным он быть не может: серверы WebDAV и CalDAV не разрешают запросы с чужих страниц. Поэтому вместе с ним идёт небольшой сервер lists-web. Для остальных это ещё одно устройство: он держит свою копию данных и синхронизируется наравне с приложениями.

Сегодня Задача

Запускается он одной командой:

docker run -d --name lists \
 -p 8080:8080 \
 -v lists-data:/data \
 -e LISTS_WEB_PASSWORD='придумайте пароль' \
 ghcr.io/juev/lists:0.2.0

Образ собран для amd64 и arm64. Вход по паролю или через OpenID Connect, синхронизация задаётся переменными окружения. Страница рассчитана и на телефон, её можно добавить на экран «Домой». Сервер сделан для одного человека: все, кто вошёл, видят одни и те же данные⁵.

Чем Lists отличается

Данные у вас. Они лежат на устройстве и в хранилище, которое вы выбрали сами. Учётной записи нет, чужого сервера с вашими задачами тоже. Если проект завтра остановится, приложение продолжит работать, а с CalDAV задачи останутся ещё и в стандартном формате.

Работает без сети. Сеть нужна только для обмена изменениями. Самолёт, метро и упавший сервер ничего не меняют.

Одна логика на всех платформах. Хранение, слияние правок, синхронизация, повторы и разбор строки быстрого ввода написаны один раз, на Rust, и подключены к приложениям на Swift и Kotlin. Два независимо написанных слияния рано или поздно разошлись бы в мелочи. Интерфейс при этом у каждой платформы свой: SwiftUI на macOS, Jetpack Compose на Android⁶.

Правки не теряются. Слияние по полям избавляет от файлов вида «конфликтная копия» и от вопросов, какую версию оставить.

Переезд несложный. Lists читает резервную копию 2Do, CSV из Todoist, доску Trello в JSON и списки Microsoft To Do. Повторный импорт того же файла обновляет уже перенесённое.

Резервные копии. Приложения для macOS и Android раз в сутки сохраняют копию данных на устройстве и хранят последние пять. Копию можно восстановить, сохранить в другое место или перенести на другое устройство. Перед обновлением, которое меняет формат хранения, копия делается сама.

Код открыт. Лицензия MIT, спецификации лежат в репозитории рядом с кодом.

Что ещё не сделано

Проекту неделя. Первый коммит сделан 5 октября, с тех пор вышло тринадцать версий, считая предварительные; последняя стабильная 0.2.0, готовится 0.3.0. Работа продолжается, и вот чего пока нет:

приложения для iOS; телефон от Apple обслуживает веб-интерфейс;
шифрования данных в хранилище: приложение кладёт их туда открыто;
перетаскивания задач и списков на Android, и дата окончания повтора там не задаётся;
своих правил повтора и уведомлений в веб-интерфейсе;
сборок под Intel для macOS и под что-либо, кроме arm64, для Android.

Часть сделанного проверена тестами и на эмуляторе, но не на разных настоящих устройствах и серверах. Что именно и чем проверено, записано в конце спецификации⁷. Ошибки тоже есть: найденные записаны в задачах репозитория.

Как попробовать

Сборки лежат на странице релизов :

macOS 14 или новее на Apple silicon: образ диска .dmg;
Android 8.0 или новее на arm64: файл .apk, подписанный одним и тем же ключом от версии к версии;
веб-сервер: образ ghcr.io/juev/lists.

Начать можно без синхронизации, она подключается позже. Если уже есть список дел в другом приложении, его можно импортировать.

Попробуйте. Замечания, ошибки и пожелания оставляйте в задачах репозитория : разбираю я их именно там.

docs/usage.md — руководство по приложениям и веб-интерфейсу. ↩︎
docs/specs/sync.md — модель данных, правила слияния и формат хранилища. ↩︎
docs/specs/caldav.md — что передаётся через CalDAV и что нет. ↩︎
Раздел «Толчок между устройствами» в docs/specs/sync.md : проверка от 6 октября на эмуляторе с приложением ntfy 1.25.2. ↩︎
docs/self-hosting.md — Docker, настройки, вход и обратный прокси. ↩︎
docs/architecture.md — принятые решения и отклонённые варианты. ↩︎
Раздел «Что реализовано» в docs/specs/product.md . ↩︎

Читайте оригинал на странице: Lists: список дел, который хранится у вас (Denis Evsyukov)

freshgo: порт FreshRSS на Go, который перестал быть портом

denis@evsyukov.org (Denis Evsyukov) — Sat, 10 Oct 2026 21:20:10 +0300

RSS мне нравится тем, что между мной и автором никого нет. Я сам выбираю сайты, и их обновления приходят ко мне все и по порядку. Лента не решает за меня, что показать первым, а что придержать.

Читалки при этом я менял. Долгое время пользовался miniflux и даже переносил его на отдельный хостинг¹. Потом перешёл на FreshRSS и поставил его на свой сервер². Он меня в целом устраивал: ленты обновлялись, клиенты на телефоне работали. Но постоянно что-то не нравилось, по мелочи и в разных местах, и ни одна из этих мелочей не тянула на причину переезжать.

В итоге я сделал свою читалку: с помощью Claude написал freshgo .

Сначала порт

Задумывался freshgo как полный порт FreshRSS на Go: один исполняемый файл, который забирает данные работающей установки и встаёт на её место. Первый коммит сделан утром 6 октября. К вечеру того же дня в репозитории были хранение в SQLite и PostgreSQL, импорт из FreshRSS, разбор лент всех видов, которые умеет оригинал, его язык поиска и фильтры, Google Reader API и каркас веб-интерфейса³.

Образцом служил запущенный FreshRSS 1.30.1. В репозитории лежит то, что он выдал на фиксированном наборе лент и что ответил на список запросов API, и тесты сверяют поведение freshgo с этими ответами⁴.

Переезд занимает одну команду: freshgo import читает каталог данных FreshRSS и переносит пользователей с паролями, ленты с настройками, статьи с отметками о прочтении, метки и значки. Мои 84 ленты и шесть тысяч статей импорт перенёс за 1,1 секунды. Обратной дороги нет, базу freshgo в FreshRSS не вернуть, поэтому каталог оригинала лучше сохранить, пока не убедитесь, что всё на месте.

Клиентам о переезде знать не нужно. FreshRSS отдаёт Google Reader API по адресу /api/greader.php, и freshgo отвечает по тому же пути, с прежними паролями API, уже выданными токенами и идентификаторами статей. Тот же API доступен и по обычным путям Google Reader, /accounts/ и /reader/, так что клиенту можно дать просто адрес сервера. Fever API не реализован.

Потом своё

Чистым портом freshgo пробыл недолго. Версия 0.1.0 вышла 8 октября, и уже в ней было то, чего в оригинале нет; остальное добавилось за следующие два дня.

Интерфейс Google Reader. Веб-интерфейс у freshgo свой, и собран он по образцу Google Reader: слева дерево категорий и лент, справа статьи по одной строке, статья раскрывается на месте. Оформлений два, «Reader classic» и «Reader 2011», по двум версиям оригинала. У каждого есть светлые и тёмные цвета; тёмные пришлось придумывать, у Google Reader их не было. Страницы собирает сервер, любое действие остаётся ссылкой или формой и работает без JavaScript, а скрипт добавляет клавиши и действия без перезагрузки страницы.

Телефон и PWA. Под узкий экран интерфейс доработан отдельно. Меню и управление списком убираются за кнопки. Касание строки раскрывает статью и закрывает предыдущую. Внизу закреплена панель: следующая и предыдущая статья, отметка о прочтении, звёздочка. freshgo можно установить как приложение, с телефона через «На экран Домой», с компьютера через «Установить». Для этого нужен HTTPS, и читать без сети нельзя: это тот же сайт в отдельном окне.

Список Статья Подписки

Картинки через сервер. Обычно картинки статьи браузер грузит с тех сайтов, где они лежат, и эти сайты видят адрес читателя и время, когда он открыл статью. freshgo может отдавать картинки со своего адреса. Схему я взял у miniflux⁵: адреса подменяются в момент показа, каждый подписан, и сервер загружает только то, что сам вставил в статью. Режимов три: все картинки, только те, что отдаются по http (их страница на https иначе не покажет вовсе), и никакие. Картинки нигде не сохраняются, сервер передаёт их насквозь. Работает это и в веб-интерфейсе, и для клиентов Google Reader API.

Полный текст. Многие ленты отдают только анонс. FreshRSS умеет забирать текст со страницы статьи по CSS-селектору, и селектор для каждой ленты надо написать самому. В freshgo к этому добавились три вещи:

статья находится на странице без селектора, так же, как её находит режим чтения в браузере;
текст можно запросить для одной статьи клавишей f, что бы ни было настроено у ленты;
страницы ленты может читать настоящий браузер.

Третий пункт появился из-за сайтов за проверкой Cloudflare. Лента у openai.com читается, а на запрос страницы статьи сервер получает 403 и «Just a moment…», напрямую и через прокси, с User-Agent и curl, и Firefox⁶. Теперь рядом с freshgo можно запустить браузер с протоколом DevTools и отметить ленты, страницы которых читает он. Из того, что я пробовал, самым лёгким оказался Lightpanda : около 30 МиБ в простое и несколько сотен, пока он читает страницу. Проверку, которая требует щёлкнуть или собрать картинку, так не пройти; статья в этом случае остаётся с текстом из ленты.

Перевод. У раскрытой статьи есть действие «Перевести», клавиша T. Переводит языковая модель: подходит любой сервис с API, совместимым с OpenAI, адрес, ключ и модель задаются тремя настройками сервера. Текст уходит в модель по абзацам и появляется на экране по мере готовности. Разметку модель не видит совсем: ссылки, картинки и код заменяются номерными метками и возвращаются на место без изменений. Готовый перевод хранится вместе со статьёй, второй раз за него платить не придётся. Помнить стоит одно: текст статьи при каждом запросе перевода уходит с вашего сервера в тот сервис, который вы назвали.

WebSub. Если лента объявляет хаб, freshgo подписывается на него, и новые статьи приходят в момент публикации; сама лента после этого опрашивается раз в сутки. В первой версии подписка зависела от опроса: пока документ ленты не менялся, сервер к хабу не обращался, и редко обновляемая лента могла неделями оставаться без подписки. Теперь адрес хаба хранится вместе с лентой, читается и из заголовков Link, а подписки продлеваются по сроку⁷.

Остальное перечислю коротко: вход через OpenID Connect, один прокси на все ленты с возможностью задать лентам свой, управление с клавиатуры с палитрой команд по Ctrl+K.

Что показали замеры

Писать на Go ради того, чтобы было на Go, смысла мало, поэтому я попросил сравнение. Оба сервера работали на одной машине с одними и теми же подписками: один пользователь, 84 ленты, около 6000 статей, база в SQLite⁸.

	FreshRSS 1.30.1	freshgo
Процессорное время за сутки	109 с	95 с
Память без дискового кэша, средняя / наибольшая	116 / 178 МиБ	42 / 64 МиБ
Образ контейнера	384 МБ	38,3 МБ
Данные на диске	189 МиБ	49 МиБ
Записано на диск за сутки	1,2 ГиБ	0,54 ГиБ

Процессора оба тратят одинаково мало: время обновления лент уходит на ожидание чужих сайтов, а не на вычисления. Памяти freshgo нужно втрое меньше. На диске разница вчетверо, и почти вся она в кэше: FreshRSS хранит копию каждого загруженного документа ленты, freshgo запоминает только ETag и Last-Modified. Сами статьи занимают в обеих базах одинаково.

Со скоростью ответов получилось интереснее. В первом замере freshgo версии 0.2.3 проиграл оригиналу именно там, где клиент проводит время при синхронизации:

Запрос	FreshRSS	freshgo 0.2.3	freshgo 0.2.7
`stream/contents`, 50 статей	4,6 мс	7,3 мс	3,3–3,7 мс
`stream/contents`, 200 статей	13,8–18,4 мс	25,7 мс	11,3–11,7 мс
Список непрочитанных	1,5 мс	9,7 мс	0,7 мс
Главная страница, 20 непрочитанных	8,8 мс	10,2 мс	5,3–5,8 мс
`stream/contents`, 8 соединений	694 запроса/с	426 запросов/с	1118–1125 запросов/с

Причины нашлись обычные. Список непрочитанных открывал каждую строку пользователя ради одного флага. Текст статьи чистился заново при каждом показе. Адреса картинок подменялись через полный разбор HTML. После индексов, чистки текста при записи и подмены адресов без разбора документа freshgo отвечает быстрее FreshRSS на девяти запросах из десяти и наравне на одном.

Для одного читателя всё это несколько миллисекунд в любую сторону. Разница станет заметной при многих пользователях или с клиентами, которые забирают статьи тысячами.

Чего ждать

Проекту меньше недели. За это время вышло двенадцать версий, считая три предварительные; последняя 0.2.7.
Проверен он одной установкой, моей: один пользователь, SQLite. PostgreSQL поддерживается и покрыт тестами, но в сравнении не участвовал.
Импорт читает FreshRSS на SQLite и PostgreSQL. MySQL и MariaDB он не читает.
PHP-расширения FreshRSS не работают. Точки расширения есть, но обработчики для них собираются вместе с сервером.
Часть поведения отличается от оригинала намеренно, список есть в README⁹.
Это независимый проект. Вопросы по нему авторам FreshRSS задавать не нужно.

Теперь на моём сервере работает freshgo, и я могу рекомендовать его вам. Код и инструкции лежат в репозитории juev/freshgo , образ опубликован как ghcr.io/juev/freshgo. Если что-то работает не так или чего-то не хватает, заведите issue.

Miniflux on Heroku . ↩︎
Настройка Docker для работы с локальным прокси-сервером : заметка времён переноса FreshRSS на свой сервер. ↩︎
История коммитов juev/freshgo . ↩︎
testdata/reference и спецификации в docs/specs . ↩︎
Issue #4 : разбор того, как отдаёт картинки miniflux, и что из этого взято. ↩︎
Issue #55 : что было испробовано против проверки Cloudflare и сколько памяти занимает каждый вариант. ↩︎
Issue #18 . ↩︎
freshgo and FreshRSS measured side by side — условия, полные таблицы и способ повторить. Процессор, память и диск измерены у версии 0.2.3, время ответов у версии 0.2.7. ↩︎
Раздел What behaves differently . ↩︎

Читайте оригинал на странице: freshgo: порт FreshRSS на Go, который перестал быть портом (Denis Evsyukov)

Ссылки #411

denis@evsyukov.org (Denis Evsyukov) — Sat, 10 Oct 2026 09:31:16 +0300

На этой неделе в подборке: скрытые функции слежки в мессенджере Max, разбор ссылок в Git, HTTP-туннели на SSH и nginx с временными ссылками и документация вместо памяти для AI-агентов.

🔐 Безопасность

The Max Messenger: An Analysis of Russia’s State-Mandated Messaging Application | InterSecLab Max — российский мессенджер, функции которого VK может менять для отдельных пользователей. В исследовании рассматриваются возможности слежки, которые могут включаться незаметно для пользователя.

💻 Разработка

On Git Refs Фрагмент посвящён тому, как автор уточнил своё понимание Git. Для этого он предлагает рассмотреть две команды, но сами команды и объяснение в предоставленном тексте отсутствуют.

🖥️ Инфраструктура

Self-hosted HTTP tunnels with SSH and nginx Связка OpenSSH и nginx позволяет организовать HTTP-туннель без установки дополнительного ПО: для этого используются удалённая переадресация портов и модуль secure_link. Результат — доступная для передачи HTTPS-ссылка с токеном, срок действия которого истекает.

🤖 Агенты

Agents Don’t Need Memory. They Need Documentation. | Kevin Liao Для AI-агентов предлагается использовать документацию проекта вместо извлечения нужного контекста из старых разговоров. Краткое описание формулирует этот подход, но не раскрывает, как вести документацию, и не приводит результатов сравнения.

А ещё

За прошедшую неделю собрал 57 ссылок.

Хорошей вам недели!

Читайте оригинал на странице: Ссылки #411 (Denis Evsyukov)

Ссылки #410

denis@evsyukov.org (Denis Evsyukov) — Sat, 03 Oct 2026 11:57:42 +0300

На этой неделе в подборке: как водяные знаки меняют поведение LLM-агентов, четырёхкратное ускорение prompt lookup в llama.cpp, подводные камни AT TIME ZONE ‘UTC’ в Postgres и сайт, спрятанный в Tor.

🤖 ИИ

The Provenance Tax: Understanding the Impact of LLM Watermarking on AI Agent Behavior Проверка водяных знаков SynthID-Text на шести моделях выявила, что маркировка меняет точность вызовов инструментов и ослабляет отказы при атаке через внедрение подсказок. На некоторых моделях вызванные маркировкой изменения поведения сильнее, чем при изменении температуры.

⚡ Производительность

42x Faster Prompt Lookup Drafting in llama.cpp Четыре изменения кэшей n-грамм в llama.cpp ускоряют подготовку токенов для prompt lookup decoding: обработка одного чернового токена становится быстрее до 41,6 раза, загрузка статического кэша — до 23,5 раза. Пиковое потребление памяти при этом снижается до 2,65 раза, но это верхние значения улучшений, а не гарантированный результат для каждого запуска.

🗄️ Базы данных

Postgres AT TIME ZONE ‘UTC’ does NOT do what you think it does В PostgreSQL выражение AT TIME ZONE ‘UTC’ преобразует timestamptz в timestamp без часового пояса, поэтому дальнейшие операции уже не учитывают исходный тип времени. При сравнении такого значения с timestamptz результат зависит от часового пояса сервера: равенство сработает, только если он установлен в UTC.

🔍 Приватность

Self-Hosting on the Dark Web | David Álvarez Rosa Сайт размещён как скрытый сервис Tor и доступен по адресу .onion, который работает только внутри сети Tor. Описание сообщает о доступности сайта через Tor, но не раскрывает подробностей настройки или способа размещения.

А ещё

За прошедшую неделю собрал 87 ссылок.

Хорошей вам недели!

Читайте оригинал на странице: Ссылки #410 (Denis Evsyukov)

linkding на Go: сутки на порт и неделя на то, что всплыло после

denis@evsyukov.org (Denis Evsyukov) — Fri, 02 Oct 2026 10:05:17 +0300

Закладки я давно храню в linkding . Привык к нему настолько, что на прошлой неделе написал для него клиент под Android¹. К самому серверу претензия у меня была одна, зато постоянная.

linkding написан на Python и Django. Настройки запуска я не менял, а по умолчанию образ поднимает uWSGI в два процесса по два потока². Одновременно сервер обрабатывает четыре запроса, остальные ждут в очереди. При этом мой linkding смотрит в интернет, и кроме меня к нему ходят сканеры и боты, которые перебирают адреса. Время от времени он просто переставал отвечать, и приходилось ждать, пока отпустит. Число процессов можно поднять, но каждый занимает память, а пользуется сервисом один человек.

В какой-то момент я задумался, нельзя ли перенести linkding на Go. Писать руками порт чужого проекта с админкой, OIDC, импортом, снимками страниц и двумя базами данных я бы не стал. Поэтому поручил анализ и работу Codex.

Сутки

Сначала появился документ с условиями приёмки³. В нём зафиксирована версия оригинала, v1.47.0, и перечислено, что должно совпасть: маршруты, поля JSON, коды ответов, тексты ошибок, внешний вид страниц, настройки LD_*. Отдельной строкой записано главное правило всей работы: если документация и код оригинала расходятся, образцом считается ответ запущенного linkding этой версии.

Так и шла работа. Каждый шаг сверялся с Python-версией, и при любом расхождении порт дорабатывался. По истории репозитория это видно лучше, чем по моему пересказу: десятки коммитов подряд начинаются со слова match. Совпадение формы ошибки при битом заголовке с токеном. Совпадение ответов на HEAD и OPTIONS. Порядок вариантов сортировки в выпадающем списке. Счётчики в фильтрах админки. Переводы админки, взятые из каталогов Django.

Первый коммит датирован вечером 25 сентября, релиз v1.47.0 вышел днём 26-го⁴. Между ними 76 коммитов. Codex работал чуть больше суток почти без остановок, и на выходе получился сервер, который собирается без CGO в один исполняемый файл и умеет SQLite и PostgreSQL.

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

Первый запуск: OIDC

Я перенёс данные, запустил порт на месте оригинала и не смог войти.

Перед linkding у меня стоит Caddy: он принимает HTTPS, а до приложения запрос идёт по обычному HTTP. Порт видел у себя HTTP и именно с этой схемой собирал адрес возврата для OIDC. Провайдер такой адрес не принимал.

В оригинале эту задачу решает промежуточный слой Django, который читает заголовки прокси. В порте пришлось чинить код: с настройкой LD_USE_X_FORWARDED_HOST сервер берёт схему и имя хоста из заголовков X-Forwarded-Proto и X-Forwarded-Host⁶. Без неё он эти заголовки игнорирует, иначе адрес возврата мог бы подставить любой клиент; на оба случая есть тесты. Исправление вышло в v1.47.1, через два часа после первого релиза.

Go оказался медленнее

Ради чего всё затевалось, нужно было проверить. Я попросил нагрузочное сравнение: один и тот же набор из 10 000 закладок, оба сервера в контейнерах с одинаковыми ограничениями, запускаются по очереди⁷.

Результат на SQLite меня удивил.

Запрос, 8 клиентов	Python, запросов/с	Go, запросов/с	Go к Python
Список	177	235	1,33
Поиск	66	55	0,84
Поиск с тегом	59	41	0,70
Страница интерфейса	90	71	0,79
Создание закладки	347	307	0,89

Порт проигрывал оригиналу почти везде, где работали несколько клиентов сразу. А в том же прогоне нашлась вещь похуже скорости: при восьми параллельных клиентах 664 из 1000 запросов на создание закладки вернули HTTP 500. SQLite не пускал вторую пишущую транзакцию, пока шла первая, а порт не ждал. Это закрыл тот же релиз v1.47.1: транзакции теперь открываются в режиме IMMEDIATE.

Дальше началась обычная работа с базой. Разбор запросов показал, что язык тут ни при чём:

Страницу из ста закладок порт собирал сотней отдельных запросов, по одному на закладку с её тегами. Python забирал теги для всей страницы разом.
При создании закладки проверка на дубликат не попадала в индекс и просматривала все закладки владельца.
Поиск по тегу повторял соединение таблиц для каждой закладки-кандидата.
На каждое слово в поиске функция сравнения без учёта регистра вызывалась четыре раза.

Каждая правка мерилась отдельной парой прогонов «до и после»⁸:

Что изменилось	Было, запросов/с	Стало, запросов/с
Список, 32 клиента	244	349
Поиск, 32 клиента	57	107
Страница интерфейса, 32 клиента	69	231
Создание закладки, 8 клиентов	315	1462

Пары относятся к разным экспериментам, перемножать их в одно общее ускорение нельзя. И победа не полная: на поиске с тегом при 32 клиентах хвост задержек у Go в последнем сравнении остался длиннее, чем у Python. Справедливости ради, оригинал тоже выигрывает от настройки базы: после ANALYZE создание закладок на Python ускорилось с 348 до 412 запросов в секунду.

Мне важнее было другое измерение: сколько ресурсов сервер тратит при одинаковой нагрузке. Оба получали по 50 запросов в секунду⁹.

	Python	Go
Процессор, ядер (четыре сценария API)	0,43–1,63	0,18–0,64
Память под нагрузкой, МиБ	120–158	14–24
Память в простое, МиБ	68	9

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

Неделя на собственном сервере

Тесты на совпадение с оригиналом проверяют то, что догадались проверить. Остальное находится, когда начинаешь пользоваться.

Фильтр, который сбрасывался. Я открыл закладки с тегом #inbox, отметил первую страницу и отправил в архив. В строке поиска по-прежнему стояло #inbox, а список под ней показывал все закладки подряд. Порт не передавал текущий запрос в адрес действия, оригинал передаёт. При проверке соседних форм нашлось то же самое в поиске и в его настройках: они теряли активные фильтры, которых не было среди видимых полей¹⁰.

Длинный заголовок. Закладка со страницы, у которой заголовок длиннее 512 символов, не сохранялась: сервер отвечал ошибкой 400. Заодно выяснилось, что некоторые пути записи это ограничение обходили и упирались уже в базу. Теперь заголовок нормализуется и обрезается до 512 символов Юникода в одном месте, через которое проходят API, формы, админка, импорт и фоновое обновление метаданных¹¹.

Молчащий сервер. Разбираясь с заголовками, я заметил, что порт вообще не пишет в консоль, кто и зачем к нему приходил. Для сервера, на который ходят сканеры, это неудобно. Журнал запросов появился в том же релизе; токены лент из адресов в нём вырезаются.

Общий адрес у многих владельцев. Эту проблему показал разбор запросов, сам я с ней столкнуться не мог: если одну и ту же ссылку сохранили тысячи пользователей, поиск дубликата просматривал их всех. Составной индекс по адресу и владельцу поднял скорость создания в таком сценарии с 533 до 6884 запросов в секунду¹². На моей установке с одним пользователем разницы нет, но оставлять это не хотелось.

За пять дней вышло восемь релизов, от v1.47.0 до v1.47.7.

Что в итоге

Сейчас у меня работает порт, и разницы с оригиналом я не замечаю: тот же интерфейс, те же расширения для браузера, тот же адрес, ShareDing ходит в тот же API.

Что стоит знать, прежде чем пробовать:

Порт привязан к linkding v1.47.0. Новые версии оригинала сами в него не попадут.
Это независимый проект. Оригинал по-прежнему ведёт его автор, Sascha Ißbrücker (sissbruecker ), и вопросы по порту ему задавать не нужно.
Все измерения сделаны на ноутбуке короткими прогонами. Они показывают, где порт быстрее или медленнее на одних и тех же данных, и ничего не обещают о предельной нагрузке.
Проверен он одной установкой — моей.

Последний пункт я могу исправить только с вашей помощью. Код лежит в репозитории juev/linkding , готовые сборки и образы — в релизах, порядок переноса описан в руководстве по миграции⁵. Исходная база при переносе остаётся нетронутой, так что попробовать можно без риска для закладок. Если что-то работает не так, как в оригинале, или чего-то не хватает, заведите issue.

ShareDing для Android: ссылки в linkding, даже когда сервер недоступен . ↩︎
uwsgi.ini в linkding v1.47.0: processes = 2, threads = 2. ↩︎
linkding v1.47.0 migration contract . ↩︎
Релизы juev/linkding . ↩︎
Migrate from Python linkding v1.47.0 . ↩︎ ↩︎
Коммит 120980f : схема из заголовка прокси для OIDC и режим транзакций SQLite. Настройка описана в руководстве по установке . ↩︎
Local load comparison: Python linkding and the Go port — условия, полные таблицы для SQLite и PostgreSQL, способ повторить. ↩︎
Performance optimization results . ↩︎
CPU and memory at equal request rates . Память — анонимная память контейнера, медиана трёх прогонов. ↩︎
Pull request #3 , вошёл в v1.47.6. ↩︎
Коммит 2d80805 , вошёл в v1.47.7. ↩︎
Pull request #1 , вошёл в v1.47.5. ↩︎

Читайте оригинал на странице: linkding на Go: сутки на порт и неделя на то, что всплыло после (Denis Evsyukov)