EnglishРусский Map

Obsidian: будущее плагинов

title
Obsidian: будущее плагинов
type
summary
summary
Obsidian запускает каталог Community и панель разработчика, заменяет GitHub PR автоматической проверкой релизов и разбирает очередь из 2300+ заявок
tags
obsidian, plugin-ecosystem, software-distribution, supply-chain-security
created
2026-05-13
updated
2026-05-13
lang
ru
source_updated
2026-05-13
translated
2026-09-01
translator
lllm/antigravity/gemini-3.7-flash-medium

Анонс за май 2026 года от команды Obsidian представляет Obsidian Community - новый каталог плагинов и тем с панелью разработчика и системой автоматической проверки. Главное изменение: автоматическую проверку теперь проходит каждый релиз, а не только первая заявка. Вынужденная мера из-за объёма: более 4000 плагинов, свыше 120 млн суммарных скачиваний и наплыв заявок, ускоренный кодинг-агентами, из-за которого очередь на ручную проверку стало невозможно разобрать.

Что запущено

  • Obsidian Community - каталог с поиском, фильтрацией и сортировкой, отдельными страницами проектов со скриншотами, карточками безопасности (scorecards), плашками платных и официальных плагинов. Профили авторов со ссылками на спонсорство и соцсети.
  • Панель разработчика - вход через новый аккаунт Obsidian + GitHub. Отправка плагинов, управление текущими проектами, отслеживание статуса релизов. Все существующие плагины/темы и заявки из очереди PR на GitHub автоматически перенесены в новую систему.
  • Конвейер автоматической проверки - каждая версия сканируется на проблемы безопасности, регрессии качества кода, известные уязвимости и вредоносное ПО. Предупреждения и ошибки отображаются разработчикам в панели управления.
  • Scorecards - публичные статусы по каждому проекту. В планах: декларирование разрешений (capabilities), аттестация артефактов, результаты ручной проверки и использование возможностей приложения.

Две оговорки:

  • Ручная проверка остаётся, но переориентирована на популярные, рекомендованные и отмеченные сообществом плагины, а не на каждую первую заявку. Система масштабируется за счёт автоматизации базового уровня (floor), а люди закрывают верхнюю планку (ceiling).
  • Существующие плагины, которые больше не проходят новую проверку, получают временное исключение - они пока остаются в каталоге. Со временем старым плагинам придётся соответствовать новым стандартам, иначе они будут исключены.

Очередь из 2300+ заявок была разобрана за считанные дни до запуска. Эта цифра вкупе с формулировкой "кодинг-агенты ускоряют создание плагинов" - прикладная причина, почему старый конвейер с GitHub-PR сломался.

Процесс подачи заявок

Новый процесс (аккаунт Obsidian + GitHub OAuth):

  1. Войти на community.obsidian.md
  2. Подключить GitHub, выбрать репозиторий
  3. Заполнить шаги в панели (категории, скриншоты, ценовая плашка)
  4. Отправить - автоматическая проверка запускается сразу, результат обычно готов через несколько минут
  5. Успех -> плагин доступен для поиска в приложении в течение 24 часов

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

  • Запустить официальный eslint-плагин локально
  • Предварительно просканировать любую ветку / тег / коммит из панели разработчика

Декларирование возможностей (roadmap)

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

Это паттерн декларирования разрешений при установке, к которому движется вся сфера безопасности цепочек поставок (supply chain security) - см. sandboxing-ai-agents для той же четырёхуровневой схемы применительно к ИИ-агентам для кодинга и whitelist-capability-config для варианта со встроенными скриптами. Структурная проблема идентична: то, что способно делать всё что угодно, небезопасно ставить повсеместно. Поэтому экосистему либо изолируют в песочнице (уровни файловой системы / сети / системных вызовов), либо вводят декларирование полномочий (пользователь явно соглашается на конкретные права). Выбор Obsidian - информирование: плагины всё ещё работают с полным доступом к процессу, но пользователи видят, к чему плагин заявляет доступ.

Teams и приватные плагины

Существующие инструменты безопасного развёртывания для команд расширяются следующими возможностями:

  • Упрощённое управление тем, какие плагины сообщества разрешены участникам команды
  • Дистрибуция приватных плагинов для участников команды (здесь закрытый исходный код поддерживается; в публичный каталог новые плагины принимаются только с открытым исходным кодом)
  • Бейдж Official для команд, чьи плагины соответствуют критериям официальной интеграции

Закрытый исходный код

Новый каталог не принимает новые плагины с закрытым исходным кодом. Существующие закрытые плагины остаются доступны "до дальнейшего уведомления"; команда думает, как адаптировать автоматическую проверку для них. Это осознанное сужение периметра доверия: после запуска всё новое в каталоге имеет исходный код, доступный сканеру.

Чего система не делает

В публикации чётко очерчены границы проекта:

  • Obsidian Community - не магазин: встроенных платежей нет. Разработчики принимают оплату на сторонних ресурсах; каталог только ставит метки (free / optional payments / paid).
  • В качестве хостинга исходного кода пока поддерживается только GitHub. Другие forge-платформы находятся в списке на будущее, а не в релизе. (См. forge / Nesbitt's forge о том, как устроена поддержка разных forge в экосистеме Go.)
  • Доступ для сомейнтейнеров и организаций пока ограничен схемой с единственным владельцем на GitHub; поддержка совместной работы нескольких человек запланирована.

Контекст и связи

Это шаг по укреплению экосистемы плагинов из того же ряда, что и:

  • supply-chain-security / tanstack-npm-supply-chain-postmortem / fsnotify-maintainer-dispute - та же проблема со стороны npm и смежных экосистем. Сканирование каждого релиза плюс подпись и аттестация - те же защитные механизмы, которые Astral внедряет со стороны издателя (open-source-security-astral).
  • features-to-steal-from-npmx - список Несбитта "что должен показывать фронтенд современного реестра". Каталог Obsidian добавляет ряд этих примитивов (сортируемые списки, статус каждого проекта, страницы авторов, плашки платных версий).
  • clippy-stricter-config - та же логика, что и в заметке Шварца об ужесточении линтинга: стандартные инструменты должны становиться строже по мере роста объёма сгенерированного кода.
  • obsidian-ai-complete-guide - блог Хуашу работает поверх экосистемы плагинов Obsidian; этот релиз повышает базовую надёжность для всего этого класса решений.

Конкретно для базы знаний основной тезис заключается в том, что плагины, созданные кодинг-агентами, - это проблема лавинообразного объёма, под которую и проектировался новый конвейер. То же самое наблюдение ceo-ai-psychosis / ai-great-leap-forward / average-is-all-you-need / i-dont-want-your-prs отслеживают с разных ракурсов: когда стоимость создания единицы работы обнуляется, система контроля качества вынуждена переходить от модели "проверять каждую заявку" к модели "сканировать каждый релиз и выборочно рецензировать то, что действительно важно".