Как соцсеть Nostr сможет масштабироваться

Я написал статью об основах того, что такое Nostr, что такое «события» и как они работают. Теперь давайте рассмотрим некоторые проблемы, которые серверам ретрансляции придется решать в будущем.

Весь протокол Nostr зависит от людей, использующих сервер ретрансляции. Нет никакой «сети Nostr», есть только ретрансляторы и клиенты, которые подключаются к ретрансляторам. У людей должны быть стимулы запускать ретрансляторы, и в долгосрочной перспективе это станет огромной частью того, насколько могут масштабироваться ретрансляторы. Ретрансляторов Nostr в том же масштабе, что и серверов Twitter, не будет никогда, если только они не смогут прибыльно эксплуатироваться или, по крайней мере, не будут приносить достаточно денег, чтобы оплачивать расходы на их работу.

Реклама

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

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

Микроплатежи

Микроплатежи – еще одно очевидное решение, особенно с учетом текущих попыток более тесно интегрировать Lightning в приложения Nostr. Эта модель будет предлагать большую гибкость с точки зрения взымания платы. Ретрансляторы могут взимать плату только за публикацию событий, они могут взимать плату за загрузку событий для чтения, они могут комбинировать и то, и другое и корректировать цену каждого в зависимости от того, сколько их ресурсов было потреблено. Однако лично я скептически отношусь к тому, что эта модель может масштабироваться до размера чего-то вроде Twitter. Микроплатежи за контент показывают себя жизнеспособными во многих нишевых разработках, основанных на Lightning, но есть две фундаментальные проблемы, связанные с их масштабированием до глобального масштаба.

Во-первых, в настоящее время для этого произошло недостаточно принятия Биткоина. Даже если бы всем волшебным образом стало удобно платить за каждое незначительное взаимодействие с сервисом через Nostr, людей, владеющих биткоинами, недостаточно, чтобы поддерживать его в таком массовом масштабе, как Twitter. Ретрансляторы могут взимать плату за подписку через фиат, но эти каналы оплаты не будут поддерживать оплату долей цента за каждое опубликованное или загруженное событие. Во-вторых, люди уже привыкли к тому, что такие услуги бесплатны. Это именно то, что люди ожидают. Я не думаю, что одни только микроплатежи действительно помогут поддерживать ретрансляторы в огромных масштабах.

Может быть способ позволить микроплатежам прижиться, не навязывая их буквально каждому классу пользователей, использующих ваш ретранслятор. Было много дискуссий о создании всевозможных приложений поверх Nostr, помимо клона Twitter: GitHub, Wikipedia, даже децентрализованных приложений, таких как Uber. Последнее здесь ключевое. Что-то вроде Twitter или Google – это всего лишь сервис, который люди всю свою жизнь считали само собой разумеющимся бесплатным. Люди привыкли платить комиссию за размещение объявления о работе или оператору торговой площадки, когда заказывают что-то в Интернете. Они просто ожидают этого с самого начала. Это возможный способ для ретрансляторов создать надежную основу дохода от своих пользователей, не создавая большой напряженности и не нарушая ожиданий среднего потенциального пользователя.

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

Может ли Nostr масштабировать ретрансляторы?

Однако, даже если склеить все это вместе, могут ли эти разные модели доходов поддерживать ретрансляцию в масштабе Twitter? А как насчет других вариантов использования, таких как социальные сети? Возможно, отдельный ретранслятор, работающий в таком масштабе для определенных вариантов использования Nostr, будет просто экономически нецелесообразен. Базовая структура протокола была создана очень простым способом, чтобы его нельзя было легко подвергнуть цензуре или изменить содержимое его событий неочевидным образом. Однако эта структура сопряжена с накладными расходами.

Это принципиально не навредит Nostr, если окажется истиной. В конце концов, клиенты могут подключаться к любым ретрансляторам, которые им нужны. Клиенты не привязаны к какому-либо отдельному ретранслятору, они могут охватывать события с десятков ретрансляторов одновременно. События, хранящиеся на одном ретрансляторе, могут даже указывать на события, хранящиеся на совершенно других реле. Протокол может по-прежнему работать для любого варианта использования на практике, даже если отдельные серверы ретрансляции имеют жесткие ограничения, которые они не могут масштабировать с точки зрения количества пользователей или количества событий, которые они хранят и обслуживают.

Однако… эта динамика сама по себе вызывает проблемы в том, как индексировать и отслеживать все эти данные, разбросанные по разным серверам. Будет ли у вас полная информация о серии событий, ссылающихся друг на друга? Или чего-то не будет хватать?

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

Это гостевой пост Шиноби, преподавателя-самоучки в Биткоин-сфере и ориентированного на технологии ведущего Биткоин-подкастов. Высказанные мнения являются его собственными и не обязательно отражают точку зрения BTC Inc. или Bitcoin Magazine.