Новый год социальных сетей: принципы Nostr и ключевые проблемы управления
Новые проекты социальных сетей под руководством «Пятого правого» изучались в течение многих лет, но без каких-либо признаков массового внедрения. В прошлом году, в связи с непрерывным развитием технологии шифрования и опасениями по поводу приобретения Маском Twitter, децентрализованная социальная сеть открыла новые возможности.
Проблемы, которые эти социальные сети пытаются решить: могут включать в себя усиление цензуры, повышение гибкости модерации контента и сокращение возможностей крупных компаний социальных сетей по формированию и отслеживанию того, о чем люди говорят в Интернете, среди прочего.
По мере появления и роста новых платформ выбор альтернативных социальных сетей часто обусловлен политическими соображениями. Такие сайты, как Getr, Parler, Gab и Truth Social, угождают правым, рекламируя себя как альтернативу Twitter свободе слова.
Сегодня мы собираемся обсудить Ностр-Дамус, новый протокол социальных сетей, который в последнее время привлек много внимания и является в некоторой степени инновационным. К ним относятся технические принципы Nostr, ключевые вопросы управления, которые необходимо решить, и способы стимулирования продолжения работы ретранслятора.
Обзор Ностр
Основанный в 2020 году, Ностр — это децентрализованный протокол, который позволяет пользователям владеть своей личностью и проверять сообщения с помощью цифровых подписей с использованием шифрования с открытым и закрытым ключом. Эти сообщения затем распространяются по взаимосвязанной сети серверов. Протокол не использует блокчейн, который в ранних экспериментах оказался слишком медленным для социальных сетей. Но есть структурные сходства, и Nostr рано нашел нишу в крипто-толпе со своим либертарианским духом и открытым исходным кодом.
Мастодонт против Ностра
Протокол Nostr и первый ретрансляционный сервер были созданы разработчиком fiatjaf в конце 2020 года. Прежде чем привлечь всеобщее внимание, Nostr был тихим нишевым протоколом, призванным стать облегченным решением проблем Twitter и Mastodon.
Mastodon, сеть с открытым исходным кодом, основанная в 2016 году, позволяет любому настроить сервер. Дизайн часто называют «федеративным», и он может подпадать или не подпадать под размытую грань «Web3», в зависимости от того, как она определяется. Mastodon позволяет пользователям присоединяться к курируемым сообществам с настраиваемыми правилами модерации контента. В настоящее время число зарегистрированных пользователей достигло 200+, и он стал убежищем для либералов, журналистов и ученых.
In Twitter и Мастодонт системах идентификаторы/имена пользователей контролируются тем, кто управляет сервером.
Основное отличие Nostr заключается в том, что каждый пользователь использует пару открытого и закрытого ключей для выполнения этой функции, а не имя пользователя, принадлежащее оператору сервера, что делает Nostr устойчивым к цензуре. Это один из основных строительных блоков для построения всего протокола Nostr.
События: это базовый тип объекта/данных, используемый клиентами и серверами ретрансляции, к которым они подключаются для отправки и получения сообщений. Общая идея протокола заключается в том, что клиенты отправляют события на сервер ретрансляции, который затем сохраняет и индексирует их, а другие клиенты могут связываться с сервером ретрансляции для запроса событий, которые они получили и сохранили. В оригинале NIP 01были определены три различных типа событий:
- Отправляйте метаданные о пользователе, такие как имя пользователя, изображение, биографию и т. д.
- Отправка SMS и основного контента
- Рекомендовать сервер ретрансляции людям, которые следят за создателем мероприятия, для подключения.
Все мероприятия структурированы определенным образом. Включает открытый ключ создателя, метку времени создания, тип (или тип в спецификации), полезные данные контента и подпись создателя события. В качестве альтернативы могут существовать теги, которые ссылаются на другие события или пользователей и имеют значение идентификатора, которое представляет собой хэш всего, кроме подписи создателя (аналогично TXID транзакции Биткойн).
Это позволяет пользователям проверять подпись (и кому принадлежит ключ, если он не был скомпрометирован), чтобы гарантировать, что сообщение действительно было создано владельцем открытого ключа в нем и что сообщение не было изменено с момента его подписания. это.
Точно так же, как транзакция Биткойн не может быть изменена после того, как она была подписана, не сделав ее недействительной, пользователь не может изменить ее после того, как создатель Ностр event подписал его, не сделав это очевидным мошенничеством.
Система типов событий была значительно расширена по сравнению с оригинальной. NIP. Существует тип события для сообщений с прямым шифрованием, которые создают общий секрет путем объединения закрытого ключа отправителя с открытым ключом получателя, результат которого такой же, как и результат объединения открытого ключа отправителя с закрытым ключом получателя. одинаковы (именно так работают BIP 47 и бесшумные платежи).
Существуют также заменяемые типы событий и эфемерные события. В случае заменяемых событий (очевидно), они устроены так, что первоначальный создатель события может подписать новое событие взамен старого. Серверы ретрансляции, соответствующие этой спецификации, будут автоматически удалять старые события из своего хранилища и начинать предоставлять клиентам новые версии после их получения.
Эфемерные события устроены таким образом, что при отправке на ретранслятор они будут транслироваться всем, кто подпишется на их создателя, но сервер ретрансляции не должен их хранить. Это создает вероятность того, что сообщение во время его трансляции увидят только те, кто находится в сети. Существует даже тип событий для представления реакции на события других людей (например, лайки или смайлы).
Говоря о последнем вопросе, события также могут содержать теги. В настоящее время существуют типы тегов для События (имеется в виду точное событие Nostr), Публичный ключ (чтобы отметить или сослаться на другого пользователя) и Тема (для имитации функциональности, например темы электронного письма).
Все они могут включать указатели на определенные серверы ретрансляции, с которых извлекаются данные, чтобы пользователи могли фактически взаимодействовать на разных серверах, т. е. пользователь публикует свой контент на контенте сервера ретрансляции, с которым другой пользователь может взаимодействовать и ссылаться на него на другом сервере. сервер ретрансляции, чтобы любой пользователь мог последовательно получить весь поток взаимодействия в правильном порядке без необходимости выяснять, где находятся соответствующие данные, при помощи большого количества сложных операций.
В оригинале NIPбыла дана спецификация того, как клиент взаимодействует с сервером ретрансляции, подписываясь на структуру сообщений/данных, которая включает в себя фильтры для тех событий, в получении которых клиент заинтересован. Эти фильтры могут указывать открытый ключ пользователя, точное событие, тип события или даже конкретный временной интервал, который они хотят использовать на основе предыдущих критериев.
Пользователи могут даже отправлять открытые ключи или префиксы идентификаторов событий, например «1xjisj…», и получать одно или несколько событий из открытого ключа, начинающегося с этой короткой строки (это полезно для сокрытия от серверов ретрансляции того, что вы действительно хотите увидеть). .
В целом, протокол представляет собой очень простую общую схему передачи сообщений между пользователями, охватывающую такие важные вещи, как гарантия целостности сообщений и использование идентификаторов открытых ключей для отправки сообщений, а также упрощение конечной инфраструктуры. Серверы ретрансляции могут быть высокоцентрализованными или позволять пользователям запускать свои собственные персональные серверы ретрансляции, при этом беспрепятственно взаимодействуя друг с другом и не вызывая массового хаоса в случае, если пользователям будет запрещено использовать один сервер ретрансляции.
Они могут перейти на другой сервер или запустить свой собственный, и они не потеряют свою цифровую личность или подписчиков, отделив платформу от своего предыдущего сервера, поскольку они по-прежнему сохраняют контроль над своими закрытыми ключами, а пользователи могут использовать их в другом месте для аутентификации. их, когда они их найдут.
Серверы ретрансляции также могут выполнять все, что хотят: работать бесплатно, взимать небольшую плату за публикацию или загрузку сообщений и даже иметь NIP, который требует подтверждения работы в виде хэш-наличных для отправки сообщений.
Это может быть единый ретрансляционный сервер, на котором размещаются публикации и который делает их доступными только для других пользователей, или сервер, работающий в масштабе, например Twitter или Reddit (клиенты могут отображать и организовывать информацию по своему желанию, что позволяет имитировать любые социальные сети). Все они беспрепятственно взаимодействуют, не блокируя пользователей.
Ключевые вопросы управления, которые будет решать Nostr
Открытые/закрытые ключи пользователя являются неотъемлемой частью работы Nostr как протокола. Это действует как тесная связь между реальным пользователем и тем, как его идентифицируют другие, не позволяя любому серверу ретрансляции разъединить эти две вещи, то есть передать чей-то идентификатор другому пользователю. Это также решает одну из самых больших проблем платформы: отсутствие контроля над собственной личностью пользователя.
Но это порождает и новые проблемы: ключ может быть утерян, ключ может быть скомпрометирован, и если такое событие произойдет, пользователь не сможет обратиться за помощью.
Это неизбежно потребует схемы, позволяющей пользователям переключаться с одной пары ключей на другую поддающимся проверке и обнаружению способом, а также для их взаимодействия с другими пользователями через протокол. Весь протокол основан на доказательстве того, что событие пришло от конкретного пользователя (ключ идентификации), поэтому, как только чей-то ключ будет скомпрометирован, все эти гарантии будут утеряны.
Nostr требует реальной криптографической схемы, которая связывает ротацию одного ключа с другим. Разработчик fiatjaf предложил базовое решение, которое могло бы решить эту проблему. Основная идея состоит в том, чтобы взять длинный список адресов, полученный из одного главного начального числа, и создать набор «скорректированных» ключей, подобно тому, как деревья Taproot связываются с ключами Биткойна.
Taproot берет корень Меркла дерева Taproot и «добавляет» его к открытому ключу, чтобы создать новый открытый ключ. Это можно повторить, добавив корень Меркла к закрытому ключу, чтобы получить закрытый ключ, соответствующий новому открытому ключу. Идея Фиатьяфа состоит в том, чтобы связать обязательства в обратную цепочку от начала до конца, чтобы каждый скорректированный ключ фактически содержал доказательство того, что следующий скорректированный ключ был использован для его создания.
Итак, представьте, что вы начинаете с клавиши Z, последней в цепочке. Вы можете его что-нибудь подправить, а затем вернуться и создать скорректированную версию ключа Y, используя скорректированную клавишу Z (Z' + Y = Y'). Отсюда вы можете взять Y' и использовать его для регулировки X (Y' + X = X'). Вы должны сделать это до самого ключа A, получить A' и использовать этот ключ оттуда. Когда он сломан, пользователь может транслировать событие, содержащее неотрегулированный ключ A и скорректированный ключ B'.
Он будет содержать все данные, необходимые для того, чтобы показать, что B' использовался для создания A', и пользователь может немедленно прекратить подписку на A' и вместо этого подписаться на B'. Они будут однозначно знать, что B' является следующим ключом для этого пользователя, и вместо этого будут следовать этому ключу.
Однако с этим предложением все еще есть некоторые проблемы. Во-первых, все ключи, которые будут использоваться, должны быть сгенерированы заранее, и нет возможности перейти на совершенно новый набор ключей. Эту проблему можно решить, зафиксировав в этой схеме главный ключ, который может нотариально заверить это вращение, или просто сгенерировав очень большой набор ключей с самого начала.
Любой путь возможен, но в конечном итоге требует обеспечения безопасности корневого ключа или ключевого материала и предоставления клиентам Nostr только отдельных горячих клавиш (горячих клавиш).
Однако эта схема не защищает пользователей и не обеспечивает механизмов восстановления личности в случае потери или компрометации материалов корневого ключа.
Для некоторого обсуждения потенциальных решений здесь можно рассмотреть еще один способ — настроить ключ на главный холодный ключ, который также должен использоваться для подписи событий от одного ключа к другому вращению. У вас есть ключ A', который получается путем сложения A и M (главный ключ); событием ротации будут A, M и B' (генерируемые путем сложения B и M) и подпись M. M может быть мультиподписным пороговым ключом – две трети, три пятых и т. д.
Это может добавить избыточность от потери и обеспечить безопасный механизм ротации ключей. Это также открывает возможность использовать службы для помощи в восстановлении или распространения некоторых из этих ключей доверенным друзьям. Он предлагает ту же гибкость, что и мультиподпись в самом Биткойне.
НИП26 Это также предложение, которое может быть очень полезным при решении этой проблемы. Это определяет расширение протокола для событий, которое позволяет подписи одного ключа авторизовать другой ключ для публикации событий от его имени. «Токен» или делегированное доказательство подписи будет затем включено во все события, публикуемые вторым открытым ключом от имени первого. Оно может быть даже ограничено по времени, поэтому срок действия токенов делегирования автоматически истекает, и их необходимо обновлять.
Вопрос управления ключами и безопасности представляет собой очень большую проблему при очень большом пространстве проектирования, полном компромиссов и болевых точек. Однако, если Nostr не сможет защитить и поддерживать целостность этих идентификаторов пользователей, протокол, полностью основанный на парах открытого и закрытого ключей, используемых в качестве идентификаторов, не будет принят в больших масштабах.
Расширение перед Ностром
Весь протокол Nostr основан на том, что кто-то где-то управляет сервером ретрансляции. Никакой сети Nostr нет, есть только реле и клиенты, подключенные к реле. Людей необходимо стимулировать к использованию ретрансляторов, и это в конечном итоге будет во многом определять, насколько далеко ретрансляторы смогут масштабироваться в долгосрочной перспективе. Если ретранслятор Nostr не сможет быть прибыльным или, по крайней мере, приносить достаточно денег для покрытия собственных эксплуатационных расходов, никогда не будет ретранслятора такого же размера, как сервер Twitter.
Реклама
Учитывая то, как Nostr работает как протокол, полная блокировка рекламы была бы тривиальной задачей, что делает это решение невозможным. Серверы ретрансляции могут попытаться использовать рекламу в качестве модели дохода, которая, очевидно, является основной моделью дохода почти для всех бесплатных онлайн-сервисов, но проблема в том, что пользователи, по сути, должны согласиться. Ретрансляторы могут легко вставлять рекламу в события, которые они отправляют клиентам. , но клиенты также могут легко фильтровать рекламные события из своего пользовательского интерфейса, если они не были созданы с помощью открытого ключа, на который они намеревались подписаться.
микроплатежей
Микроплатежи являются еще одним очевидным решением, особенно с учетом продолжающихся попыток интегрировать молниеносный Cеть более тесно в приложении Nostr. Эта модель предлагает большую гибкость в способах оплаты. Ретрансляторы могут взимать плату только за публикацию там событий, за загрузку чтения событий или за комбинацию того и другого, корректируя цену каждого в зависимости от того, сколько ресурсов они потребляют. Однако сомнительно, что эту модель можно масштабировать до масштабов Twitter.
Контентные микроплатежи показали свою жизнеспособность во многих нишевых продуктах, основанных на молниеносный Cеть, но есть две фундаментальные проблемы с реальным масштабированием в глобальном масштабе.
Во-первых, биткойн еще недостаточно принят. Даже если бы все волшебным образом согласились платить за каждое небольшое взаимодействие с сервисом на Nostr, не было бы достаточно людей, владеющих биткойнами, чтобы поддерживать что-то столь масштабное, как Twitter. Ретрансляторы могут взимать плату за подписку в бумажной валюте, но эти способы оплаты не поддерживают уплату небольшой комиссии за каждое опубликованное или загруженное событие.
Во-вторых, люди уже привыкли к такого рода бесплатным услугам. Это именно то, чего и следовало ожидать. Я не думаю, что микроплатежи действительно могут поддерживать крупномасштабную ретрансляцию.
Существует способ сделать микроплатежи «более устойчивыми» и устойчивыми, не навязывая их каждому классу пользователей, использующих реле. Было много разговоров о создании различных приложений на базе Nostr, за исключением клона Twitter. GitHub, Wikipedia и даже Uber.
Последнее является ключевым: экономические ожидания. Люди очень привыкли платить комиссию, когда где-то рекламируется вакансия, или платить комиссию оператору торговой площадки, когда они заказывают что-то онлайн, но не обслуживают вещи, которые, по их мнению, должны быть бесплатными – Google, Twitter. Это может дать ретрансляторам возможность создать прочный источник дохода от своих пользователей, не создавая при этом особых трений и не нарушая ожиданий среднего потенциального пользователя.
Если микроплатежи также станут важным фактором, операторам ретрансляции придется запустить узел Lightning, чтобы сначала получать средства от пользователей. Это потенциально может увеличить доход, если будет правильно сочетаться с любой моделью микроплатежей, реализованной ретранслятором.
Чем больше дохода зарабатывает ретрансляционный сервер, тем больше ликвидности ему требуется в сети Lightning, чтобы обеспечить это. Если операторы правильно планируют, как они развертывают или распределяют ликвидность в сети, сам факт эксплуатации узла маршрутизации может стать значительным источником дохода сам по себе, помимо любых комиссий, взимаемых за прием или передачу данных через ретрансляторы.
Заключение
Социальные проекты Web3, помимо вышеперечисленных Ностр и Мастодонт, также включают в себя такие проекты, как порталу и объектив, которые не смогут быстро заменить существующие платформы социальных сетей. По статистике, Twitter имеет сотни миллионов активных пользователей. что его цель имеет миллиарды, но Мастодонт имеет только 2.5 миллионов пользователейи Ностр имеет только около 220,000 XNUMX уникальных идентификаторов пользователей. Многие социальные проекты Web3 сталкиваются с препятствиями, связанными с удобством использования, которые замедляют массовое внедрение.
СМИ и политика неразделимы. Поскольку социальные проекты Web3 распространяются, а публичные дискуссии фрагментируются по различным приложениям и протоколам, могут возникнуть политические последствия. Даже Мессина, который долгое время выступал за децентрализацию социальных сетей, опасается, что децентрализация еще больше усилит общественный дискурс, который в последние годы был отмечен взаимной враждебностью и непониманием.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Информация на этом веб-сайте предоставляется в качестве общего рыночного комментария и не является инвестиционным советом. Мы рекомендуем вам провести собственное исследование, прежде чем инвестировать.
Присоединяйтесь к нам, чтобы следить за новостями: https://linktr.ee/coincu
Гарольд
Коинку Новости
Автор
ЗНАНИЯ
Новый год социальных сетей: принципы Nostr и ключевые проблемы управления
Новые проекты социальных сетей под руководством «Пятого правого» изучались в течение многих лет, но без каких-либо признаков массового внедрения. В прошлом году, в связи с непрерывным развитием технологии шифрования и опасениями по поводу приобретения Маском Twitter, децентрализованная социальная сеть открыла новые возможности.
Проблемы, которые эти социальные сети пытаются решить: могут включать в себя усиление цензуры, повышение гибкости модерации контента и сокращение возможностей крупных компаний социальных сетей по формированию и отслеживанию того, о чем люди говорят в Интернете, среди прочего.
По мере появления и роста новых платформ выбор альтернативных социальных сетей часто обусловлен политическими соображениями. Такие сайты, как Getr, Parler, Gab и Truth Social, угождают правым, рекламируя себя как альтернативу Twitter свободе слова.
Сегодня мы собираемся обсудить Ностр-Дамус, новый протокол социальных сетей, который в последнее время привлек много внимания и является в некоторой степени инновационным. К ним относятся технические принципы Nostr, ключевые вопросы управления, которые необходимо решить, и способы стимулирования продолжения работы ретранслятора.
Обзор Ностр
Основанный в 2020 году, Ностр — это децентрализованный протокол, который позволяет пользователям владеть своей личностью и проверять сообщения с помощью цифровых подписей с использованием шифрования с открытым и закрытым ключом. Эти сообщения затем распространяются по взаимосвязанной сети серверов. Протокол не использует блокчейн, который в ранних экспериментах оказался слишком медленным для социальных сетей. Но есть структурные сходства, и Nostr рано нашел нишу в крипто-толпе со своим либертарианским духом и открытым исходным кодом.
Мастодонт против Ностра
Протокол Nostr и первый ретрансляционный сервер были созданы разработчиком fiatjaf в конце 2020 года. Прежде чем привлечь всеобщее внимание, Nostr был тихим нишевым протоколом, призванным стать облегченным решением проблем Twitter и Mastodon.
Mastodon, сеть с открытым исходным кодом, основанная в 2016 году, позволяет любому настроить сервер. Дизайн часто называют «федеративным», и он может подпадать или не подпадать под размытую грань «Web3», в зависимости от того, как она определяется. Mastodon позволяет пользователям присоединяться к курируемым сообществам с настраиваемыми правилами модерации контента. В настоящее время число зарегистрированных пользователей достигло 200+, и он стал убежищем для либералов, журналистов и ученых.
In Twitter и Мастодонт системах идентификаторы/имена пользователей контролируются тем, кто управляет сервером.
Основное отличие Nostr заключается в том, что каждый пользователь использует пару открытого и закрытого ключей для выполнения этой функции, а не имя пользователя, принадлежащее оператору сервера, что делает Nostr устойчивым к цензуре. Это один из основных строительных блоков для построения всего протокола Nostr.
События: это базовый тип объекта/данных, используемый клиентами и серверами ретрансляции, к которым они подключаются для отправки и получения сообщений. Общая идея протокола заключается в том, что клиенты отправляют события на сервер ретрансляции, который затем сохраняет и индексирует их, а другие клиенты могут связываться с сервером ретрансляции для запроса событий, которые они получили и сохранили. В оригинале NIP 01были определены три различных типа событий:
- Отправляйте метаданные о пользователе, такие как имя пользователя, изображение, биографию и т. д.
- Отправка SMS и основного контента
- Рекомендовать сервер ретрансляции людям, которые следят за создателем мероприятия, для подключения.
Все мероприятия структурированы определенным образом. Включает открытый ключ создателя, метку времени создания, тип (или тип в спецификации), полезные данные контента и подпись создателя события. В качестве альтернативы могут существовать теги, которые ссылаются на другие события или пользователей и имеют значение идентификатора, которое представляет собой хэш всего, кроме подписи создателя (аналогично TXID транзакции Биткойн).
Это позволяет пользователям проверять подпись (и кому принадлежит ключ, если он не был скомпрометирован), чтобы гарантировать, что сообщение действительно было создано владельцем открытого ключа в нем и что сообщение не было изменено с момента его подписания. это.
Точно так же, как транзакция Биткойн не может быть изменена после того, как она была подписана, не сделав ее недействительной, пользователь не может изменить ее после того, как создатель Ностр event подписал его, не сделав это очевидным мошенничеством.
Система типов событий была значительно расширена по сравнению с оригинальной. NIP. Существует тип события для сообщений с прямым шифрованием, которые создают общий секрет путем объединения закрытого ключа отправителя с открытым ключом получателя, результат которого такой же, как и результат объединения открытого ключа отправителя с закрытым ключом получателя. одинаковы (именно так работают BIP 47 и бесшумные платежи).
Существуют также заменяемые типы событий и эфемерные события. В случае заменяемых событий (очевидно), они устроены так, что первоначальный создатель события может подписать новое событие взамен старого. Серверы ретрансляции, соответствующие этой спецификации, будут автоматически удалять старые события из своего хранилища и начинать предоставлять клиентам новые версии после их получения.
Эфемерные события устроены таким образом, что при отправке на ретранслятор они будут транслироваться всем, кто подпишется на их создателя, но сервер ретрансляции не должен их хранить. Это создает вероятность того, что сообщение во время его трансляции увидят только те, кто находится в сети. Существует даже тип событий для представления реакции на события других людей (например, лайки или смайлы).
Говоря о последнем вопросе, события также могут содержать теги. В настоящее время существуют типы тегов для События (имеется в виду точное событие Nostr), Публичный ключ (чтобы отметить или сослаться на другого пользователя) и Тема (для имитации функциональности, например темы электронного письма).
Все они могут включать указатели на определенные серверы ретрансляции, с которых извлекаются данные, чтобы пользователи могли фактически взаимодействовать на разных серверах, т. е. пользователь публикует свой контент на контенте сервера ретрансляции, с которым другой пользователь может взаимодействовать и ссылаться на него на другом сервере. сервер ретрансляции, чтобы любой пользователь мог последовательно получить весь поток взаимодействия в правильном порядке без необходимости выяснять, где находятся соответствующие данные, при помощи большого количества сложных операций.
В оригинале NIPбыла дана спецификация того, как клиент взаимодействует с сервером ретрансляции, подписываясь на структуру сообщений/данных, которая включает в себя фильтры для тех событий, в получении которых клиент заинтересован. Эти фильтры могут указывать открытый ключ пользователя, точное событие, тип события или даже конкретный временной интервал, который они хотят использовать на основе предыдущих критериев.
Пользователи могут даже отправлять открытые ключи или префиксы идентификаторов событий, например «1xjisj…», и получать одно или несколько событий из открытого ключа, начинающегося с этой короткой строки (это полезно для сокрытия от серверов ретрансляции того, что вы действительно хотите увидеть). .
В целом, протокол представляет собой очень простую общую схему передачи сообщений между пользователями, охватывающую такие важные вещи, как гарантия целостности сообщений и использование идентификаторов открытых ключей для отправки сообщений, а также упрощение конечной инфраструктуры. Серверы ретрансляции могут быть высокоцентрализованными или позволять пользователям запускать свои собственные персональные серверы ретрансляции, при этом беспрепятственно взаимодействуя друг с другом и не вызывая массового хаоса в случае, если пользователям будет запрещено использовать один сервер ретрансляции.
Они могут перейти на другой сервер или запустить свой собственный, и они не потеряют свою цифровую личность или подписчиков, отделив платформу от своего предыдущего сервера, поскольку они по-прежнему сохраняют контроль над своими закрытыми ключами, а пользователи могут использовать их в другом месте для аутентификации. их, когда они их найдут.
Серверы ретрансляции также могут выполнять все, что хотят: работать бесплатно, взимать небольшую плату за публикацию или загрузку сообщений и даже иметь NIP, который требует подтверждения работы в виде хэш-наличных для отправки сообщений.
Это может быть единый ретрансляционный сервер, на котором размещаются публикации и который делает их доступными только для других пользователей, или сервер, работающий в масштабе, например Twitter или Reddit (клиенты могут отображать и организовывать информацию по своему желанию, что позволяет имитировать любые социальные сети). Все они беспрепятственно взаимодействуют, не блокируя пользователей.
Ключевые вопросы управления, которые будет решать Nostr
Открытые/закрытые ключи пользователя являются неотъемлемой частью работы Nostr как протокола. Это действует как тесная связь между реальным пользователем и тем, как его идентифицируют другие, не позволяя любому серверу ретрансляции разъединить эти две вещи, то есть передать чей-то идентификатор другому пользователю. Это также решает одну из самых больших проблем платформы: отсутствие контроля над собственной личностью пользователя.
Но это порождает и новые проблемы: ключ может быть утерян, ключ может быть скомпрометирован, и если такое событие произойдет, пользователь не сможет обратиться за помощью.
Это неизбежно потребует схемы, позволяющей пользователям переключаться с одной пары ключей на другую поддающимся проверке и обнаружению способом, а также для их взаимодействия с другими пользователями через протокол. Весь протокол основан на доказательстве того, что событие пришло от конкретного пользователя (ключ идентификации), поэтому, как только чей-то ключ будет скомпрометирован, все эти гарантии будут утеряны.
Nostr требует реальной криптографической схемы, которая связывает ротацию одного ключа с другим. Разработчик fiatjaf предложил базовое решение, которое могло бы решить эту проблему. Основная идея состоит в том, чтобы взять длинный список адресов, полученный из одного главного начального числа, и создать набор «скорректированных» ключей, подобно тому, как деревья Taproot связываются с ключами Биткойна.
Taproot берет корень Меркла дерева Taproot и «добавляет» его к открытому ключу, чтобы создать новый открытый ключ. Это можно повторить, добавив корень Меркла к закрытому ключу, чтобы получить закрытый ключ, соответствующий новому открытому ключу. Идея Фиатьяфа состоит в том, чтобы связать обязательства в обратную цепочку от начала до конца, чтобы каждый скорректированный ключ фактически содержал доказательство того, что следующий скорректированный ключ был использован для его создания.
Итак, представьте, что вы начинаете с клавиши Z, последней в цепочке. Вы можете его что-нибудь подправить, а затем вернуться и создать скорректированную версию ключа Y, используя скорректированную клавишу Z (Z' + Y = Y'). Отсюда вы можете взять Y' и использовать его для регулировки X (Y' + X = X'). Вы должны сделать это до самого ключа A, получить A' и использовать этот ключ оттуда. Когда он сломан, пользователь может транслировать событие, содержащее неотрегулированный ключ A и скорректированный ключ B'.
Он будет содержать все данные, необходимые для того, чтобы показать, что B' использовался для создания A', и пользователь может немедленно прекратить подписку на A' и вместо этого подписаться на B'. Они будут однозначно знать, что B' является следующим ключом для этого пользователя, и вместо этого будут следовать этому ключу.
Однако с этим предложением все еще есть некоторые проблемы. Во-первых, все ключи, которые будут использоваться, должны быть сгенерированы заранее, и нет возможности перейти на совершенно новый набор ключей. Эту проблему можно решить, зафиксировав в этой схеме главный ключ, который может нотариально заверить это вращение, или просто сгенерировав очень большой набор ключей с самого начала.
Любой путь возможен, но в конечном итоге требует обеспечения безопасности корневого ключа или ключевого материала и предоставления клиентам Nostr только отдельных горячих клавиш (горячих клавиш).
Однако эта схема не защищает пользователей и не обеспечивает механизмов восстановления личности в случае потери или компрометации материалов корневого ключа.
Для некоторого обсуждения потенциальных решений здесь можно рассмотреть еще один способ — настроить ключ на главный холодный ключ, который также должен использоваться для подписи событий от одного ключа к другому вращению. У вас есть ключ A', который получается путем сложения A и M (главный ключ); событием ротации будут A, M и B' (генерируемые путем сложения B и M) и подпись M. M может быть мультиподписным пороговым ключом – две трети, три пятых и т. д.
Это может добавить избыточность от потери и обеспечить безопасный механизм ротации ключей. Это также открывает возможность использовать службы для помощи в восстановлении или распространения некоторых из этих ключей доверенным друзьям. Он предлагает ту же гибкость, что и мультиподпись в самом Биткойне.
НИП26 Это также предложение, которое может быть очень полезным при решении этой проблемы. Это определяет расширение протокола для событий, которое позволяет подписи одного ключа авторизовать другой ключ для публикации событий от его имени. «Токен» или делегированное доказательство подписи будет затем включено во все события, публикуемые вторым открытым ключом от имени первого. Оно может быть даже ограничено по времени, поэтому срок действия токенов делегирования автоматически истекает, и их необходимо обновлять.
Вопрос управления ключами и безопасности представляет собой очень большую проблему при очень большом пространстве проектирования, полном компромиссов и болевых точек. Однако, если Nostr не сможет защитить и поддерживать целостность этих идентификаторов пользователей, протокол, полностью основанный на парах открытого и закрытого ключей, используемых в качестве идентификаторов, не будет принят в больших масштабах.
Расширение перед Ностром
Весь протокол Nostr основан на том, что кто-то где-то управляет сервером ретрансляции. Никакой сети Nostr нет, есть только реле и клиенты, подключенные к реле. Людей необходимо стимулировать к использованию ретрансляторов, и это в конечном итоге будет во многом определять, насколько далеко ретрансляторы смогут масштабироваться в долгосрочной перспективе. Если ретранслятор Nostr не сможет быть прибыльным или, по крайней мере, приносить достаточно денег для покрытия собственных эксплуатационных расходов, никогда не будет ретранслятора такого же размера, как сервер Twitter.
Реклама
Учитывая то, как Nostr работает как протокол, полная блокировка рекламы была бы тривиальной задачей, что делает это решение невозможным. Серверы ретрансляции могут попытаться использовать рекламу в качестве модели дохода, которая, очевидно, является основной моделью дохода почти для всех бесплатных онлайн-сервисов, но проблема в том, что пользователи, по сути, должны согласиться. Ретрансляторы могут легко вставлять рекламу в события, которые они отправляют клиентам. , но клиенты также могут легко фильтровать рекламные события из своего пользовательского интерфейса, если они не были созданы с помощью открытого ключа, на который они намеревались подписаться.
микроплатежей
Микроплатежи являются еще одним очевидным решением, особенно с учетом продолжающихся попыток интегрировать молниеносный Cеть более тесно в приложении Nostr. Эта модель предлагает большую гибкость в способах оплаты. Ретрансляторы могут взимать плату только за публикацию там событий, за загрузку чтения событий или за комбинацию того и другого, корректируя цену каждого в зависимости от того, сколько ресурсов они потребляют. Однако сомнительно, что эту модель можно масштабировать до масштабов Twitter.
Контентные микроплатежи показали свою жизнеспособность во многих нишевых продуктах, основанных на молниеносный Cеть, но есть две фундаментальные проблемы с реальным масштабированием в глобальном масштабе.
Во-первых, биткойн еще недостаточно принят. Даже если бы все волшебным образом согласились платить за каждое небольшое взаимодействие с сервисом на Nostr, не было бы достаточно людей, владеющих биткойнами, чтобы поддерживать что-то столь масштабное, как Twitter. Ретрансляторы могут взимать плату за подписку в бумажной валюте, но эти способы оплаты не поддерживают уплату небольшой комиссии за каждое опубликованное или загруженное событие.
Во-вторых, люди уже привыкли к такого рода бесплатным услугам. Это именно то, чего и следовало ожидать. Я не думаю, что микроплатежи действительно могут поддерживать крупномасштабную ретрансляцию.
Существует способ сделать микроплатежи «более устойчивыми» и устойчивыми, не навязывая их каждому классу пользователей, использующих реле. Было много разговоров о создании различных приложений на базе Nostr, за исключением клона Twitter. GitHub, Wikipedia и даже Uber.
Последнее является ключевым: экономические ожидания. Люди очень привыкли платить комиссию, когда где-то рекламируется вакансия, или платить комиссию оператору торговой площадки, когда они заказывают что-то онлайн, но не обслуживают вещи, которые, по их мнению, должны быть бесплатными – Google, Twitter. Это может дать ретрансляторам возможность создать прочный источник дохода от своих пользователей, не создавая при этом особых трений и не нарушая ожиданий среднего потенциального пользователя.
Если микроплатежи также станут важным фактором, операторам ретрансляции придется запустить узел Lightning, чтобы сначала получать средства от пользователей. Это потенциально может увеличить доход, если будет правильно сочетаться с любой моделью микроплатежей, реализованной ретранслятором.
Чем больше дохода зарабатывает ретрансляционный сервер, тем больше ликвидности ему требуется в сети Lightning, чтобы обеспечить это. Если операторы правильно планируют, как они развертывают или распределяют ликвидность в сети, сам факт эксплуатации узла маршрутизации может стать значительным источником дохода сам по себе, помимо любых комиссий, взимаемых за прием или передачу данных через ретрансляторы.
Заключение
Социальные проекты Web3, помимо вышеперечисленных Ностр и Мастодонт, также включают в себя такие проекты, как порталу и объектив, которые не смогут быстро заменить существующие платформы социальных сетей. По статистике, Twitter имеет сотни миллионов активных пользователей. что его цель имеет миллиарды, но Мастодонт имеет только 2.5 миллионов пользователейи Ностр имеет только около 220,000 XNUMX уникальных идентификаторов пользователей. Многие социальные проекты Web3 сталкиваются с препятствиями, связанными с удобством использования, которые замедляют массовое внедрение.
СМИ и политика неразделимы. Поскольку социальные проекты Web3 распространяются, а публичные дискуссии фрагментируются по различным приложениям и протоколам, могут возникнуть политические последствия. Даже Мессина, который долгое время выступал за децентрализацию социальных сетей, опасается, что децентрализация еще больше усилит общественный дискурс, который в последние годы был отмечен взаимной враждебностью и непониманием.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Информация на этом веб-сайте предоставляется в качестве общего рыночного комментария и не является инвестиционным советом. Мы рекомендуем вам провести собственное исследование, прежде чем инвестировать.
Присоединяйтесь к нам, чтобы следить за новостями: https://linktr.ee/coincu
Гарольд
Коинку Новости
Другие сообщения
Похожие сообщения
Новости
Дело о долговом ящике теперь становится все более сложным из-за сокрытия SEC
Новости
Кредиторы FTX могут получить до 142% суммы требования благодаря новому плану реорганизации
Новости
ETF Ethereum в оттенках серого теперь является главным приоритетом компании
Другие отзывы
Обзор Fluence: вычислительная платформа DePIN нового поколения в Интернете
Новости
Инвестиции Pantera Capital в TON направлены на расширение возможностей P2P-платежей
Новости
Дело о долговом ящике теперь становится все более сложным из-за сокрытия SEC
Новости
90% объемов транзакций стейблкоина не имеют участия реальных пользователей
Новости
LayerZero Airdrop вызывает волнение после завершения первого этапа снимка
Новости
Ошибка адреса привела к потере WBTC в размере 68 миллионов долларов, жертва стала жертвой фишинга
ЗНАНИЯ
Прогнозы по выборам в США: последствия и важность нового президента США
ЗНАНИЯ
