Блогинг в Web3: тест платформ Mirror и Paragraph

Поэтому классическая таблица «какой сервис лучше» здесь технически некорректна: один из участников сравнения перестал быть самостоятельной платформой.

Корректный вопрос другой: какие архитектурные решения Mirror пережили поглощение, что Paragraph забрал себе, а какие элементы Web3-нативной модели оказались слишком дорогими по friction для массового автора. Это не история о победе одного интерфейса над другим. Это разбор того, как рынок децентрализованных платформ для авторов отказался от обязательного кошелька, но сохранил блокчейн как слой владения, монетизации и хранения.

Слияние двух эпох: как Paragraph поглотил Mirror

Mirror запустился в конце 2020 года как Ethereum-нативная платформа для авторов. Его архитектурная гипотеза была прямолинейной: автор не просто публикует текст на чужом сервере, а связывает публикацию с собственным кошельком, выпускает материал в виде NFT, собирает финансирование через краудфандинг и формирует сообщество вокруг ончейн-активностей.

Это была модель для крипто-нативной аудитории. Пользователь должен был понимать, что такое Ethereum-адрес, подпись транзакции, gas fee и подтверждение операции в сети. Для обычного читателя порог входа выглядел избыточным. Для Web3-среды он, напротив, считался частью продукта: кошелек выступал одновременно аккаунтом, платежным инструментом и контейнером цифрового владения.

Paragraph, запущенный в октябре 2021 года, пошел по иной траектории. Платформа сохранила Web3-монетизацию, но интерфейсно приблизилась к знакомой модели рассылок и блогов. Регистрация и подписка могли работать через email. Автор получал более привычный канал дистрибуции, а блокчейн оставался за кулисами там, где он действительно добавлял функциональность: в NFT-подписках, token-gating, чаевых и мультичейн-операциях.

В мае 2024 года Paragraph приобрел Mirror и одновременно привлек $5 млн инвестиций в раунде под руководством Coinbase Ventures и Union Square Ventures. После сделки конкуренция прекратилась не сразу на уровне пользовательского восприятия, но архитектурно направление стало очевидным: Web3-блогинг будет развиваться внутри более доступной оболочки Paragraph.

В сентябре 2025 года компания объявила о постепенном закрытии Mirror. Посты и подписчики авторов должны были автоматически перенестись на Paragraph, а для старых адресов настраивались редиректы. Точные сроки полного отключения старых серверов и доменов Mirror публично не определены, поэтому объявление о миграции не следует интерпретировать как мгновенное исчезновение всей инфраструктуры.

Mirror не проиграл Paragraph в обычном рыночном тесте. Его продуктовая модель была встроена в более широкий сервис, после чего самостоятельный бренд оказался избыточен.

С инженерной точки зрения это важное различие. При закрытии независимого сервиса возникает вопрос о сохранности данных и переносе аккаунтов. В случае Mirror часть контента уже хранилась через Arweave, а перенос на Paragraph должен был сохранить публикации на уровне платформенного интерфейса. Однако децентрализованное хранение не равно полной переносимости продукта: NFT-активы, подписчики, доменные настройки, права доступа и социальный граф имеют разные модели состояния.

Публикация в Arweave может остаться доступной, но это не гарантирует сохранение:

• исходной структуры блога;
• поисковой индексации;
• комментариев и реакций;
• логики token-gating;
• привязки читателя к конкретной подписке;
• редиректов и пользовательского маршрута;
• совместимости старого NFT с новой системой доступа.

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

Различия в философии: Web3-нативность против доступности Web2

Если убрать маркетинговые формулировки, Mirror и Paragraph различались не набором кнопок, а уровнем обязательной криптографии в пользовательском пути.

У Mirror кошелек был точкой входа. Автор не мог публиковать в привычной Web2-модели с логином и паролем: требовалась Ethereum-идентичность. Это давало несколько преимуществ. Аккаунт не зависел от базы данных платформы в привычном смысле. Подпись транзакции подтверждала контроль над адресом. NFT-публикация могла существовать вне интерфейса Mirror, если ее данные и ссылка были корректно закреплены ончейн и в децентрализованном хранилище.

Но за это приходилось платить friction. Кошелек нужно было создать, подключить, пополнить нативным активом, подписать сообщение или транзакцию, а затем разобраться с безопасностью seed-фразы и фишинговыми доменами. Для автора, который хочет отправить читателям текст, каждый дополнительный шаг уменьшает воронку. Для читателя ситуация еще хуже: чтение статьи не должно требовать понимания EVM, chain ID и разрешений на подпись.

Paragraph выбрал другой компромисс. Он не отказался от Web3, а спрятал его за Web2-подобным onboarding. Email-регистрация и подписка снижают порог входа. Читатель может взаимодействовать с контентом без обязательного криптокошелька. При этом автор получает возможность подключать NFT-подписки, чаевые и доступ по токенам, когда эти механизмы действительно нужны.

Сравнение выглядит так:

У Mirror была более чистая Web3-логика. Автор владеет ключом — автор контролирует идентичность. Публикация превращается в ончейн-объект — ее можно продавать или использовать как часть коллекции. Но чистота архитектуры не отменяет UX-оверhead.

У Paragraph логика менее догматична. Email не является криптографически суверенной идентичностью, а централизованный onboarding добавляет зависимость от оператора. Зато пользовательский путь становится совместимым с реальной аудиторией, которая хочет читать, подписываться и платить, но не хочет сначала проходить процедуру настройки кошелька.

Это не вопрос того, какая модель «более Web3». Это вопрос границы, за которой децентрализация перестает быть функциональностью и превращается в обязательную церемонию.

Где проходит реальная граница децентрализации

В Mirror кошелек решал несколько задач одновременно:

1. Аутентификация. Подпись доказывала контроль над адресом.

2. Идентичность. Адрес служил публичным профилем автора.

3. Платежи. Он использовался для отправки и получения активов.

4. Владение. Выпущенный NFT мог находиться у автора или покупателя независимо от интерфейса.

5. Доступ. Владение токеном могло использоваться как условие для чтения или участия.

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

Paragraph разделяет путь чтения и путь владения. Это рациональнее для массового продукта. Читателю не нужен кошелек, пока он не хочет использовать функцию, которая действительно требует ончейн-операции. Для автора это означает более широкую воронку подписчиков и меньший объем поддержки по вопросам вроде потерянной seed-фразы.

Цена — более сложная гибридная архитектура. Возникают связки между email-аккаунтом, кошельком, подпиской, сетью и системой доступа. Чем больше слоев, тем больше мест для рассинхронизации. Web2-логин упрощает вход, но не устраняет необходимость корректно моделировать права на контент.

Трансформация монетизации: от NFT-статей к подпискам и token-gating

Mirror стал заметен не потому, что предложил еще один редактор Markdown. Его ключевая ставка была на превращение публикации в финансовый и коллекционный объект.

Автор мог использовать краудфандинг для финансирования проекта, а отдельные статьи — продавать в виде NFT. Комиссия платформы с продажи NFT-статей составляла 2,5%. В этой модели текст одновременно выступал медиаматериалом и активом. Покупатель приобретал не только право прочитать публикацию, но и проверяемый объект владения, связанный с конкретным выпуском.

Такая схема привлекательна для крипто-нативных сообществ, где NFT уже является привычным примитивом. Но она плохо масштабируется на обычный контент. Не всякая статья должна становиться активом. Не каждый читатель хочет покупать право владения текстом. Не всякая аудитория готова платить комиссию сети за действие, которое в Web2 выполняется одним кликом.

Paragraph сместил акцент с единичной продажи публикации на длительные отношения с аудиторией:

• NFT-подписки;
• чаевые;
• доступ к материалам по владению определенным токеном;
• платные сообщества и закрытые разделы;
• мультичейн-платежи и взаимодействие с несколькими сетями.

Это более гибкая модель. NFT-статья — дискретный объект: ее выпустили, купили, передали. Подписка — потоковая модель доступа. Она лучше соответствует регулярной рассылке и серийному контенту, но требует более сложного контроля состояния. Платформа должна понимать, действует ли подписка, в какой сети находится токен, был ли он передан, сожжен или заблокирован, а также что делать при смене кошелька.

NFT-контент против token-gating

У этих механизмов разные продуктовые свойства.

NFT-публикация фиксирует отдельный материал как объект. Это может быть коллекционный выпуск, запись краудфандинговой кампании или цифровой артефакт сообщества. Ее сильная сторона — простая логика владения: есть токен, есть владелец. Слабая — ограниченная повторяемость и слабая связь с будущими публикациями.

Token-gating проверяет право доступа по наличию токена. Это уже не продажа текста как объекта, а использование блокчейна в качестве ACL — access control layer. Механизм подходит для закрытых статей, архивов, каналов, курсов и сообществ. Но здесь проверка владения становится частью runtime-логики. Если RPC-узел недоступен, индексатор отстает, а токен находится в неожиданной сети, пользователь может получить отказ даже при формальном наличии актива.

Схематично различие можно представить так:

У Mirror монетизация была ближе к криптофинансированию и коллекционированию. Paragraph сделал ее похожей на SaaS-модель с Web3-примитивами. Это менее эффектно на демо, зато лучше соответствует регулярной работе автора.

Блокчейн полезен в монетизации контента там, где нужен переносимый объект или проверяемое право. Если он просто заменяет кнопку оплаты, это дорогой и шумный backend.

Есть и еще одна проблема: цифровое владение не равно авторскому праву. Покупатель NFT-статьи получает токен, но не автоматически получает исключительные права на текст. Если платформа не фиксирует лицензионные условия, объект владения остается спекулятивной оболочкой вокруг публикации. В Web3-продуктах эту разницу регулярно маскируют словом ownership, хотя на уровне юридической и технической семантики речь идет о разных сущностях.

Для создателей контента это означает необходимость разделять как минимум четыре слоя:

1. право автора на исходный текст;

2. право платформы показывать и распространять публикацию;

3. право покупателя владеть токеном;

4. право держателя токена читать закрытый материал.

Смарт-контракт может хорошо решить четвертый пункт. Он не становится от этого универсальным регистратором всех остальных прав.

Технологический фундамент: роль Arweave в сохранении контента

Обе платформы использовали Arweave для публичного и постоянного хранения контента. Это принципиально важнее, чем наличие Web3-логотипа в интерфейсе. Если текст хранится только в базе данных оператора, пользователь получает обычный централизованный блог с криптокошельком на входе. Если данные вынесены в децентрализованное хранилище, у публикации появляется шанс пережить платформу.

Но формулировку «вечное хранение» следует читать технически, а не рекламно. Arweave фиксирует данные в отдельной сети и делает их доступными через соответствующие шлюзы и инструменты. Это не означает, что исходный сайт, домен, редактор, RSS-лента и вся прикладная логика будут существовать всегда.

Архитектура блога на таком стеке обычно распадается на несколько уровней:

• контентный слой — текст, изображения, метаданные;
• идентификационный слой — кошелек, email или связка нескольких идентификаторов;
• индексация — поиск публикаций и построение ленты;
• прикладной слой — профили, подписки, комментарии, уведомления;
• слой доступа — проверка NFT и токенов;
• слой маршрутизации — домен, редиректы, ссылки и отображение страниц.

Arweave помогает прежде всего первому слою. Иногда он также используется для метаданных, но не заменяет всю остальную систему. При закрытии Mirror публикация может сохраниться в децентрализованном хранилище, а ее прежний URL перестать работать. Редирект на Paragraph — уже централизованная операция, зависящая от команды платформы и состояния ее серверов.

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

• соответствие публикации исходному автору;
• идентификаторы выпущенных NFT;
• ссылки на краудфандинговые кампании;
• данные о подписчиках;
• настройки платного доступа;
• URL и SEO-метаданные;
• доступность медиафайлов;
• история взаимодействий;
• возможность повторно экспортировать данные.

Автоматический перенос блогов и подписчиков в Paragraph снижает операционный риск, но не устраняет его. «Автоматический» означает, что процесс определен платформой. Автор не получает магического доказательства, что все связи перенесены без потерь. В закрытых системах миграция всегда является процедурой импорта, а не криптографическим законом.

Arweave не решает проблему платформенной зависимости

Популярная ошибка в оценке децентрализованных приложений — считать, что использование Arweave автоматически делает сервис децентрализованным. Это неверно.

Если один оператор контролирует:

• frontend;
• DNS;
• API;
• индексатор;
• проверку подписок;
• настройки редиректов;
• отображение профиля;
• антиспам-фильтры;
• биллинг,

то пользователь все еще зависит от этого оператора, даже если текст публикации лежит в Arweave.

В Web3-продуктах полезно разделять сохранность данных и суверенитет приложения. Первое у Mirror и Paragraph было усилено через Arweave. Второе осталось частично централизованным. Это нормальный инженерный компромисс, но его нельзя выдавать за полную автономность.

Для автора, который выбирает Web3-площадку для контента, практический вывод достаточно жесткий: нужно заранее понимать, какие элементы можно экспортировать без разрешения платформы. Если из системы можно вынести только JSON с текстом, а подписчики, ACL и маршрутизация остаются внутри закрытого API, то переносимость ограничена.

Наследие Mirror и переход команды к Farcaster

После поглощения команда Mirror переключилась на разработку Kiosk — Web3-социального приложения на базе протокола Farcaster. На этот проект было привлечено $10 млн финансирования. Сам переход показателен: команда ушла не в еще одну блоговую платформу, а в социальный слой, где публикация является частью распределенного графа идентичности и взаимодействий.

Mirror решал задачу публикации и монетизации. Farcaster-ориентированная архитектура решает другую проблему — переносимость социальных взаимодействий между клиентами и сервисами. Это более широкий уровень стека. Автору нужен не только редактор, но и дистрибуция, подписки, реакции, репутация, групповые механики и возможность не начинать аудиторию с нуля при смене интерфейса.

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

• алгоритм ленты;
• фильтрацию спама;
• доступ к аналитике;
• визуализацию профиля;
• монетизационные модули;
• уведомления;
• хранение медиа;
• onboarding пользователей.

Перенос команды от Mirror к Kiosk показывает, что рынок Web3-контента движется от единичной публикации к composable social graph. Но это не доказательство того, что вся социальная инфраструктура автоматически становится децентрализованной. Протокол, клиент и хранилище — разные компоненты. Их нельзя смешивать в один рекламный тезис.

Что осталось от Mirror в Paragraph

Поглощение не уничтожило идеи Mirror. Оно изменило их расположение в стеке.

От Mirror в экосистеме Paragraph сохранились или получили продолжение следующие принципы:

• контент может иметь ончейн-представление;
• авторская монетизация не обязана проходить через традиционный рекламный кабинет;
• NFT может быть пропуском, подпиской или коллекционным объектом;
• публикации должны иметь независимый от интерфейса слой хранения;
• кошелек остается инструментом владения, даже если больше не является обязательным логином;
• мультичейн-архитектура расширяет потенциальную аудиторию и снижает зависимость от одной сети.

При этом исчезла наиболее жесткая часть Mirror: требование, чтобы каждый участник взаимодействовал с Ethereum на уровне базового пользовательского сценария. Для инфраструктурного продукта это разумное решение. Принудительная крипто-нативность хорошо работает в закрытом сообществе, но плохо работает как универсальный onboarding.

Что выбрать автору сейчас

Вопрос «Mirror XYZ или Paragraph» после закрытия Mirror имеет только один практический ответ: для нового блога самостоятельного выбора между ними нет. Mirror следует рассматривать как исторический и архитектурный ориентир, а Paragraph — как действующую платформу, унаследовавшую часть его аудитории и Web3-механик.

Для автора, который начинает работу с Paragraph, ключевой выбор находится не между двумя брендами, а между разными режимами публикации:

Если нужен обычный блог или рассылка

Paragraph рациональнее благодаря email-регистрации и снижению кошелечного friction. Контент можно распространять среди аудитории, которая не использует криптокошельки и не хочет разбираться в транзакциях.

Если нужен закрытый клуб

Token-gating и NFT-подписки могут заменить централизованный список доступа. Но перед запуском нужно определить, что произойдет при переносе токена, смене сети, потере кошелька или остановке RPC-инфраструктуры.

Если нужен краудфандинг

Опыт Mirror показывает, что ончейн-сбор денег требует не только смарт-контракта. Необходимо заранее описать права участников, условия возврата, статус будущих публикаций и зависимость проекта от конкретного интерфейса.

Если важна коллекционная модель

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

Если критична переносимость

Нужно отделять экспортируемый контент от экспортируемой аудитории. Текст и изображения могут быть сохранены в Arweave, но email-подписчики, аналитика, правила доступа и социальные связи не становятся автоматически переносимыми только из-за децентрализованного хранилища.

Итоговый технический вердикт

Mirror был более последовательным Web3-продуктом. Его архитектура напрямую связывала автора, кошелек, публикацию и монетизацию. Для Ethereum-нативной аудитории это давало прозрачную модель владения. Для остальных пользователей — высокий onboarding-оверhead, риск ошибок в управлении ключами и слабую совместимость с привычным потреблением контента.

Paragraph оказался более жизнеспособной оболочкой для того же набора примитивов. Email снижает friction. Мультичейн расширяет архитектурный периметр. NFT-подписки и token-gating лучше подходят для продолжающегося взаимодействия с аудиторией, чем продажа каждой статьи как отдельного актива. Но компромисс никуда не исчез: часть системы остается централизованной, а сложность перемещается из интерфейса в backend, индексаторы и логику контроля доступа.

Mirror как самостоятельная платформа закрывается, поэтому сравнивать его с Paragraph в настоящем времени бессмысленно. Его ценность теперь — в выявленных архитектурных решениях и ограничениях. Он показал, что авторское владение, ончейн-монетизация и постоянное хранение можно встроить в блоговую инфраструктуру. Paragraph показал, что эти механизмы придется адаптировать под пользователей, которым не нужен кошелек на каждом шаге.

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