Биткоинеры переходят в Nostr, но чем он отличается от Twitter?

Биткоинеры переходят в Nostr, но чем он отличается от Twitter?

Nostr – это альтернатива Twitter, которая лучше защищает пользователей от цензуры и разработана таким образом, что может заинтересовать биткоинеров.

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

Протокол Nostr и первая реализация сервера ретрансляции были фактически созданы еще в конце 2020 года разработчиком fiatjaf. До повышенного внимания это был просто нишевый протокол, который был разработан как легкое решение проблем Twitter и Mastodon. В обеих системах ваша личность/имя пользователя просто контролируется тем, кто управляет сервером. Mastodon, являющийся федеративной системой с множеством разных серверов, коммуницирующих друг с другом, принципиально это не меняет. Чей бы сервер вы ни использовали для размещения учетной записи, он полностью контролирует, можете ли вы его использовать или нет. Даже если у вас есть собственный сервер, другие операторы серверов могут внести в черный или белый список серверы, которым будет разрешено общаться с ними. Это привело к разделению «Федиверс» различными серверами Mastodon и делает идею запуска собственного сервера бессмысленной. В конечном итоге вы можете подвергнуться цензуре со стороны других операторов серверов, что не позволит их пользователям увидеть ваш контент в ленте.

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

Следующее – «события» (англ. events). Это основной тип объекта/данных, используемый клиентами и серверами ретрансляции, к которым подключаются клиенты для отправки и получения сообщений. Общая идея протокола заключается в том, что клиенты отправляют события на серверы ретрансляции, которые затем, в свою очередь, сохраняют и индексируют их, а другие клиенты могут связываться с серверами ретрансляции для запроса событий, которые они получили и сохранили. В исходном NIP 01 определены три различных типа событий:

  • 0: Отправляет метаданные о пользователе, такие как имя пользователя, изображение, биография и т. д.
  • 1: Отправляет текстовые сообщения и основной контент
  • 2: Рекомендует серверы ретрансляции для людей, следящих за создателем события для подключения.

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

Система видов событий была значительно расширена по сравнению с исходным NIP. Существует тип события для зашифрованных прямых сообщений, устанавливающий общий ключ путем объединения закрытого ключа отправителя с открытым ключом получателя, в результате чего получается тот же ключ, который вы получили бы, объединив открытый ключ отправителя с закрытым ключом получателя (так работают BIP 47 и Silent Payments). Существуют также типы заменяемых событий и эфемерных событий. Заменяемое событие (очевидно) разработано таким образом, чтобы первоначальный создатель события мог подписать новое взамен старого. Серверы ретрансляции, следуя спецификации, автоматически удалят старое событие из своего хранилища и начнут предоставлять более новые версии клиентам. Эфемерные события спроектированы таким образом, что они будут транслироваться всем, кто подпишется на их создателя, при отправке в ретранслятор, но серверы ретрансляции не должны их хранить. Таким образом сообщения будут видны только людям, которые находятся в сети во время их трансляции. Существует даже тип события, чтобы показать реакцию (например, лайки или смайлики) на события других людей.

Говоря о последнем, события также могут содержать теги. В настоящее время существуют типы тегов для событий (для ссылки на конкретное событие Nostr), открытых ключей (для тега или ссылки на других пользователей) и тем (для имитации функциональности, таких как темы и-мейлов). Все они могут включать указатели на определенные серверы ретрансляции, с которых могут быть получены данные, чтобы пользователи могли фактически взаимодействовать между серверами. То есть пользователь, размещающий свой контент на одном сервере ретрансляции, может взаимодействовать и ссылаться на контент, созданный другим пользователем, публикующим его на другом сервере ретрансляции так, что любой пользователь может когерентно получать всю цепочку взаимодействий в правильном порядке и без больших сложностей в определении где найти соответствующие данные.

Внутри исходного NIP дается спецификация того, как клиенты должны взаимодействовать с серверами ретрансляции через структуру сообщений/данных подписки, которая включает фильтры для событий интересующих клиента. Эти фильтры могут указывать открытые ключи пользователей, точные события, типы событий и даже определенные временные рамки для них на основе предыдущих критериев. Вы даже можете отправлять префиксы открытых ключей или идентификаторов событий, например «1xjisj…» и получать любое событие или события из открытого ключа, которые начинаются с этой короткой строки (это может быть полезно для сокрытия от сервера ретрансляции того, что вы действительно хотите просмотреть).

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

Серверы ретрансляции также могут работать так, как они хотят. Они могут работать бесплатно, могут взимать микроплатежи за публикацию или загрузку сообщений, и даже существует NIP для требования подтверждения работы в стиле hashcash для отправки сообщения. Они могут быть единым сервером ретрансляции для хостинга и предоставления другим пользователям только ваших постов, или они могут быть сервером, работающим в больших масштабах, как Twitter или Reddit (клиенты могут отображать и организовывать информацию так, как они хотят, что позволяет эмулировать практически любую социальную сеть, существующую сегодня). Все это может беспрепятственно взаимодействовать, не блокируя пользователя. Вы можете запретить размещать контент на вашем сервере ретрансляции, но в конечном итоге вы не можете запретить просматривать контент, который вы размещаете на своем сервере ретрансляции, или запретить другим пользователям находить контент на других серверах.

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

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

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

Lightning – общепринятый язык Биткоин-экономики Lightning – общепринятый язык Биткоин-экономики Lightning становится связующим звеном, скрепляющим различные системы, построенные на Биткоине. Рой Шейнфельд 16 июня 2024
Более половины ведущих хедж-фондов США владеют биткоин-ETF Более половины ведущих хедж-фондов США владеют биткоин-ETF Анализ различных типов фондов и учреждений, владеющих биткоин-ETF. Сэм Бейкер 16 июня 2024
В надежных руках: Биткоин строит лучшее будущее В надежных руках: Биткоин строит лучшее будущее Создание систем на основе Биткоина требует тщательного проектирования и работы. Эти аспекты не должны отходить на второй план по отношению к маркетингу и продажам. Виллем Шро 15 июня 2024