Nostr的未來發展構想

Nostr 基礎介紹#

Nostr 是一個非常輕量級的開放協議，“有機會”（根據項目文檔）作為一個去中心化的社交媒體平台。協議規範在 NIP（Nostr 改進提案）中定義，可在此處找到。

該協議的基礎是一個 WebSocket 伺服器（稱為 nostr-relay），它處理和存儲一個非常簡單的數據結構，稱為Event。它看起來像下面這樣：

{
"id": <32-bytes sha256 of the the serialized event data>
"pubkey": <32-bytes hex-encoded public key of the event creator>,
"created_at": <unix timestamp in seconds>,
"kind": <integer>,
"tags": [
["e", <32-bytes hex of the id of another event>, <recommended relay URL>],
["p", <32-bytes hex of the key>, <recommended relay URL>],
... // other kinds of tags may be included later
]
"content": <arbitrary string>,
"sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>,
}

事件總是被簽名（使用 Schnorr sigs）並且它們包含可以具有語義含義的結構化數據。BIP340 中定義的 Schnorr 類型 XOnlyPubkeys （目前與比特幣 Taproot 一起使用）在整個協議中用作 “身份”。

nostr-client 是一個可以與 nostr-relay 對話並可以使用 Subscription Filter. Events 過濾器代表客戶感興趣的所有 nostr 集合。

客戶無需註冊或創建帳戶。客戶用他們的公鑰來標識。每次客戶端連接到中繼時，它都會提交其訂閱過濾器，只要客戶端連接，中繼就會將 “感興趣的事件” 流式傳輸到客戶端。

中繼可以緩存客戶端訂閱，但不是必須的。客戶應該在 “客戶端” 處理所有事情，而中繼可能像石頭一樣笨。

客戶不互相交談。但是繼電器可以。這允許中繼為它沒有的客戶端獲取數據。客戶可以訂閱他們連接的中繼之外的事件。

乍一看，這給人一種 Nostr 作為協議毫無用處的印象（為什麼不只是簽名並轉儲原始 JSON，讓客戶自己弄清楚呢？），但從更深層次的角度來看，“哑伺服器，智能客戶端” 模型可以發現具有一些巨大的工程優勢，特別是在去中心化協議設計中。

本文檔概述了這些愚蠢的伺服器、智能客戶端和比特幣網絡、e2e 加密如何結合起來解決 “去中心化社交網絡”、DSN（我剛剛想到的流行詞）問題。

問題陳述#

如果您在過去的 2 年裡沒有生活在岩石之下，那麼您已經知道當前的出現以及市場對擁有 “Twitter 替代品” 的強烈呼聲。不違背用戶動機的社交媒體平台。

這種需求催生了Gab和Mastodon等替代社交媒體平台。Ex Twitter 負責人的最近聲明已經暗示這將是下一個需要解決的大問題。所以免責聲明：我並不是說這是一個容易解決的問題，我也不認為 Nostr 可以解決所有問題。但它至少 “有機會”。

創建去中心化媒體平台的核心問題不是技術，而是社交。

創建社交媒體（或聊天應用程序）可能是您作為新軟件開發人員要解決的最教科書式的挑戰。系統的核心結構相當簡單。

一個存儲東西的數據庫，
與客戶端對話的網絡接口
一些過濾以儘快獲取查詢數據。

當然，這在現實生活中要複雜得多。但這種設計的關鍵對於所有社交媒體設計來說都是一樣的。那么，為什麼我們不能構建它並完成它呢？

問題是，它必須是一個 “去中心化” 系統，只有通過 “網絡效應” 和開發者生態系統對一組協議的新興工程共識才能成功。否則，我們會製造出我們打算解決的同樣問題。

這就是事情變得混亂的地方。如果您今天構建了完美的社交媒體，您如何才能說服其他開發者在此基礎上進行構建？如果開發人員不構建功能，用戶為什麼會來？如果用戶不來，該媒體平台的意義何在？

Gab 和 Mastodon 的例子清楚地表明，僅將代碼開源是不夠的。標準的構建過程和設計也必須公開。否則，一個人最終會成為一小群人，大部分人自願從事激進項目，並最終成為該平台的 “仁慈的獨裁者”。

因為他們必須滿足此類平台的現實設計限制，同時大規模提供他們的產品，所以他們最終創建了一個專門設計平台方法的小團隊。這使得客戶端開發人員很難使用該平台的休閒有趣的應用程序。在某個時候，他們不妨決定設計他們的小協議，但最終，他們會遇到同樣的障礙。沒有人願意自願在您為特定利基市場設計的平台上進行構建。

存儲數據的成本也很高。“伺服器所有者” 需要資源、維護和時間。當前托管 Mastodon 實例的所有人都是自願這樣做的，用戶只是依賴他們的友善而不是關閉實例。“知識共享” 這個由來已久的問題出現了。

那麼我們可以做得更好嗎？

另一種方法，愚蠢的 Nostr 方法#

如果我們不構建完美的社交媒體，而只是構建創建此類事物所需的最基本的樂高積木，並讓開發人員就拼圖的這個基本標準單元公開達成共識，那會怎樣呢？

這就是 Nostr 所做的。

為此，它採取以下方法。

指定社交數據格式的最小單位 (an Event)，並讓開發人員之間自然而然地達成協議，以此為基礎。這定義了協議的核心。每個人都需要就成為該網絡的一部分達成一致的最低限度的主幹。

Nostr 將這些協議規則定義為 NIP。並提到了一組 mandatoryNIP。需要實施的規則來討論 Nostr 協議。

在這些 NIP 之上 mandatory，optional 任何人都可以定義 NIP。中繼可以自由選擇他們支持的 NIP 集。

通過未來的 NIP 定義更多的標籤項，Event 可以在現場擴展數據。tag

可以將 AnEvents 視為通用數據存儲。可以放入其中的內容沒有限制。

儘管看起來很奇怪，但與許多 “精心設計” 的現有替代社交媒體相比，這樣一個簡單的協議得到了更多的開發者關注。

該項目已經引起了開發人員的極大興趣，社區幾乎很快就開發了一個包含庫、應用程序和中繼的豐富生態系統。而且這個名單每天都在增加。

Telegram 聊天室擁有大約 400 名成員，並且每天都在增長。

為什麼？“因為它太簡單了”。

這種簡單性允許任何有興趣的人輕鬆編寫 JSON 流媒體並開始將協議與任何現有的中繼進行對話。

可以在此處找到當前正在運行的 Nostr 繼電器的實時列表。

已經存在兩個正在進行中的類似 twitter 的應用程序branle和NOSTR-twitter。

人們還幾乎定期地在基本 NIP 之上添加新的額外細節。

該協議的簡單性使開發人員能夠快速收斂於開放標準，並將所有複雜性都放在客戶端。整個應用程序體驗將由客戶端處理，中繼將保持哑數據伺服器。這允許開發人員在客戶端應用程序上快速移動和迭代，同時與任何可用的中繼兼容。

這也增加了客戶端兼容性。可以有兩個不同的應用程序，但仍然能夠看到彼此的帖子。該平台的核心是去中心化的，客戶端通過簡單的存儲協議相互兼容。這就是 “哑伺服器，智能客戶端” 模型的巧妙之處。快速就基本標準達成一致，更快地迭代出色的客戶端應用程序。

可以在客戶端層定制複雜性，而在中繼層實現互操作性。

缺失的部分#

一旦我們了解了核心樂高積木的外觀。剩下的部分是 DOS 保護、中繼激勵和一些在用戶之間傳遞 nostr 訂閱數據的方法。

將比特幣放入 Nostr#

得益於比特幣，中繼激勵和 DOS 保護可以一次性解決。

如果其基礎設施依賴於脆弱的 “自願主義” 基礎，則無法建立強大的社交網絡。正如我們所知，“如果產品是免費的，那麼您就是產品”。應該將這些未來的媒體平台原生集成到比特幣中。

做到這一點的一站式解決方案是使用BDK。一個高性能的比特幣錢包庫，足夠靈活以處理多種比特幣接口和數據庫。添加了一些新的 NIP 來定義 payment request 和 payment response 事件類型。

對於他們發布的每個事件，付款可以是一次性鏈上交易，也可以是客戶和中繼之間的一系列 LN 付款。（將需要正在積極開發中的 BDK + LDK）。中繼可以以 sats/byte 為單位設置他們的費率，如果他們想 “自願”，他們可以選擇將其設置為 0。

這為高維護公共中繼提供了一種通過其服務獲利的好方法，同時保護它們免受 DOS 攻擊。

端到端加密訂閱共享#

請記住，Nostr 中繼只是簡單 JSON 數據的轉儲。通過 subscription 過濾器獲取。這使得 nostr 成為客戶端之間的通用數據共享平台。有了比特幣，現在我們談論的是通過 nostr 中繼網絡共享的比特幣腳本、描述符、DLC 合約和其他比特幣 DeFi 信息。但這些可能是敏感信息，不應以明文形式在公共平台上共享。

為此，需要一個加密的 nostr 訂閱共享機制。這可以是另一個伺服器，僅促進參與者之間的加密訂閱數據共享。

這可以通過以下方式實現：

使用從預期接收者的公鑰派生的 DH 共享秘密來加密 [subscription+]。relay-addres
將加密數據連同收件人的公鑰一起發布到此伺服器。
收件人客戶端收到通知，下載並解密數據，獲取訂閱以從 nostr 獲取實際數據。
實際數據也是由相同的共享秘密加密的密文，因此接收者也知道如何解密它。

這些伺服器可以非常輕量級，因為它們不需要存儲所有歷史訂閱數據。他們可以定期清除舊數據，甚至可以在知道收件人下載後實時清除。這將使他們的成本非常低，而且不需要解決激勵問題。

這些伺服器不需要遵循任何通用協議。可以通過任何設計自由實施。他們只需要有一種方法來連接到客戶，並知道何時在與他們相關的事情發生時通知他們。

它們也像 nostr relay 一樣抗審查。如果一個出現故障或停止工作，任何人都可以啟動另一個。因為他們不必保留歷史記錄，所以從一台伺服器切換到另一台伺服器不會影響整體信息流。

這些伺服器也無法利用數據，因為它們看到的只是隨機的加密 blob，因此它們不需要高度安全。

最終畫面#

所以現在結合所有這些，Nostr、比特幣和加密訂閱共享，我們現在擁有一個非常強大和默認的私人社交網絡，可以使用一些非常通用的全球協議在參與者之間共享數據。

這允許人們的隱藏社交網絡有選擇地向特定的受信任實體開放他們的帖子的可能性。

這些帖子可以是 DLC 合同、描述多方之間多重簽名的描述符、僅向訂閱成員發布的 DLC 預言機等等。

在這個框架中，“身份” 的基本單位是公鑰。公鑰類似於現實世界中的別名。任何人都可以有任意數量的別名。如果一個別名被泄露，他們可以快速創建另一個，就像我們為每筆付款創建一個新的比特幣地址一樣。

使用公鑰作為別名，就可以有選擇地向您自己的私人可信網絡開放。您可以將一個公鑰與您的全局別名（眾所周知的 Twitter 用戶名）相關聯，然後使用任意數量的平行別名僅在特定人群之間進行通信，或使用特定應用程序。

與所有這些公鑰相關的數據將保持完全無關，並且可以分布在多個 nostr 中繼中。

最終總結出來的模型是：

高度互操作且極其簡單的中繼協議，nostr。
一個靈活的框架，用於使用 optional 中繼可以選擇加入的升級來添加新的中繼功能。
一種加密的訂閱共享機制，用於傳遞 nostr 訂閱。
比特幣原生集成，同時促進 “貨幣互聯網” 和 DOS 保護。
一個去中心化的發布層，供客戶發布公共和私人內容。
解釋這些內容的客戶端複雜性，並具有使用比特幣功能的本地金融合約生成 UI。

與 web3.0 的所有內容不同，這不涉及另一個 “區塊鏈”（我知道這很糟糕）。

前進的道路#

聽起來不錯，但我們還沒有做到。而要實現這些夢想，還需要大量的工程設計。前面有未知的問題需要處理。這些中繼和客戶端的設計決策需要仔細規劃。僅僅有一個簡單的協議是不夠的。

這些中繼應該高效、穩健、在公開場合經過嚴格的同行評審，並在基本安全級別得到保證。這項工作必須公開進行，元素的設計應盡可能靈活，以滿足不同客戶開發人員的需求。

如果這個東西需要擴展到人們可以在他們的伺服器上部署的專業服務，並以此為基礎構建重要的產品，我們需要的不僅僅是愛好代碼和示例應用程序。

需要的不是另一個很酷的 nostr 應用程序，而是一個經過深思熟慮和設計的基礎設施庫，影子超級編碼員可以使用它來構建下一個帶有 “內部比特幣” 的很酷的 nostr 應用程序。

介紹 rust-nostr#

rust-nostr 是一個處於構思階段的項目，旨在解決上述問題。這個想法是提供一個完整的一站式 nostr 基礎設施套件，它是模塊化的，易於擴展，具有強大的安全保證，有據可查，開發人員很容易根據自己的需要進行定制，非常容易下載，部署和在他們的伺服器中管理。

整個結構仍然是待定的，但下面是 rust-nostr 的大致輪廓。

二進制箱生產 nostrd. Nostr-Relay 的輕量級高效 Rust 實現。nostrd 將附帶一組受支持的 NIP。默認情況下可以包含基本 NIP。可以在構建時通過功能標誌指定額外的 NIP。
nostr-cli 可用作 nostrd 伺服器端管理器的。它還可以與任何其他中繼對話 nostr 協議，並且可以用作 cli nostr 客戶端。維護訪問可以通過基本或 cookie 身份驗證提供給中繼。
豐富的 nostr-API 圖書館。包含在項目中，可以用作開發人員構建其 nostr 客戶端的簡單開發工具。然後可以通過 ffi 將這些 API 公開給其他語言，並將為開發人員提供一站式工具來構建他們很酷的 Nostr 客戶端。
portal 是加密的 nostr 訂閱共享伺服器。規範 portal 不是項目的一部分，因為它已經是一個已解決的問題。這在密碼學文獻中得到了很好的理解，並且開源中存在許多候選實現。Signal App 本身就是門戶的一个例子，儘管對於這個用例來說很難使用。印度的一個本地團隊一直專注於這個問題，以促進名為 CypherPost 的 p2p 比特幣交易的特定用例，這已經是一個非常合適的 portal 實現。最終，一個精簡版的 rust 候選實現將被添加到項目存儲庫中。但人們可以自由開發和使用自己的門戶，並且仍然與網絡的其他部分兼容。

所有這些（除了 portal）都將通過 BDK 和 LDK 在其中集成原生比特幣 + Lightning。

為了確保基礎設施的所有部分始終相互同步，他們將在項目的 CI 管道中進行嚴格的集成測試。

一旦所有這些都布置好了，就可以使用 rust-nostr 套裝來提出各種更複雜的客戶端，這些客戶端在彼此之間進行比特幣 Defi。

結語#

到目前為止這只是一个原始的想法，我甚至不知道可能的未知挑戰是什麼。我期待很多。正如他們所說的 “細節決定成敗”。這似乎是一個雄心勃勃的項目，但事實並非如此。

通過限制項目的範圍以提供非常具體的構建工具，這幾乎可以通過一些積極的 Rust 開發人員來實現。Rust 也是最適合構建它的語言，因為它允許我們在編譯器級別嚴格定義協議規則，從而減少出錯的空間，同時還生成非常簡潔且易於審核的代碼。

通過不嘗試製造 “產品” 而只解決樂高積木，我認為這是可以實現的。

然後，該項目可以為比特幣企業家提出各種應用鋪平道路。應用空間的限制只限於想像力。

因此，如果您碰巧關心這個問題並想伸出援手，或者如果您有任何一般性的建議或意見，請在 Twitter 上通過 @rajarshimaitra 聯繫我。DM 已開通。