文/ Raj arshimaitra，比特幣開發者，Rust-Nostr作者；譯/金色財經xiaozou
1、Nostr基本介紹
Nostr是一個非常輕量級的開放協議，它“有望”（據其項目文檔描述）成為去中心化的社交媒體平台。
該協議的基礎是一個WebSocket服務器（稱為nostr中繼器），它處理和存儲一個名為Event的簡單數據結構。如下圖所示：
event（事件）總能獲簽（使用Schnorr簽名），它們包含有語義意義的結構化數據。在BIP340中定義的Schnorr類型XOnlyPubkey（目前與Bitcoin Taproot一起使用）作為“身份”（identities）應用於整個協議。
nostr客戶端是一個可以與nostr中繼器通信的應用程序，可以使用Subscription Filter（訂閱過濾器）訂閱任何事件集。過濾器可提供客戶端感興趣的所有nostr事件集。
客戶端不需要註冊或創建帳戶。客戶端用它們的pubkey進行身份認證。每當客戶端與中繼器連接時，它都會提交其訂閱過濾器，只要它們處於連接狀態，中繼器會將“感興趣的事件”傳輸給客戶端。
中繼器可以緩存客戶端訂閱，但卻不必須這樣做。客戶端應該在“客戶這端”處理所有事務，而中繼器則可以像塊遲鈍的石頭。
客戶端之間互不通信。但是中繼器可以。這允許中繼器為客戶端獲取它所缺少的數據。客戶端可以訂閱與之相聯的中繼器之外的事件。
乍一看，Nostr協議似乎沒有什麼用（為什麼不直接簽署並dump原始JSON，讓客戶端來解決呢？），但深入研究就會發現，“dumb-server, smart client”（傻瓜式服務器，聰明的客戶端）模型有某些巨大的工程優勢，特別是在去中心化的協議設計中。
本文概述了這些傻瓜式服務器、聰明的客戶端，以及比特幣網絡、端到端加密是如何結合在一起解決“去中心化社交網絡”（DSN）問題的。
2、問題概述
如果過去的兩年你不是與世隔絕的話，想必你已對目前市場上出現的“Twitter替代品”的緊急激烈的呼聲有所耳聞。社交媒體平台不會與用戶動機背道而馳。
這種需求催生了像Gab和Mastodon這樣的社交媒體替代平台。前Twitter CEOJack曾發表的聲明已經暗示，這將是下一個需要解決的重大問題。免責聲明：我並不是說這是一個容易解決的問題，我也不認為Nostr能解決所有問題。但它至少“有望”解決問題。
創建去中心化媒體平台的核心問題不在於技術，而在於社交。
創建一個社交媒體（或聊天應用程序）可能是你作為一個新的軟件開發人員需要解決的最典型的挑戰。系統核心結構相當簡單。
· 一個存儲數據的數據庫。
· 與客戶端通信的網絡接口。
· 進行過濾篩選以盡快獲取查詢數據。
當然，實際情況要比這複雜得多。但此設計的關鍵點對於所有社交媒體設計來說都是一樣的。
那麼為什麼我們不能直接開發，把它完成呢？
問題是，它必須是一個“去中心化”的系統，只有通過“網絡效應”以及開發者生態就一組協議形成工程共識才能成功。否則，我們製造出的問題，恰會與我們想要解決的問題一樣。
這就產生了混亂。如果你今天創建出了完美的社交媒體，你要如何說服其他開發者在此基礎上進行開發建設？如果開發者不開發出功能，用戶為什麼會用呢？如果用戶不來使用，媒體平台還有什麼意義呢？
Gab和Mastodon的例子清楚地表明，只有代碼開源是遠遠不夠的。開發過程和標准設計也必須是公開的。否則，一個人就會變成一個小團隊（基本都是自願參與一個活躍的項目），最終會成為這個平台“仁慈的獨裁者”。
因為他們必須受這類平台的現實設計製約，在大規模提供產品的同時，他們最終創建了一個小團隊，專門設計平台的運行方式。這使得客戶端開發人員很難在該平台開發休閒有趣的應用程序。在某些時候，他們還可能會決定設計一些小協議，但最終，他們會碰到相同的障礙。沒有人願意主動在你為特定利基市場設計的平台上進行開發。
此外，存儲數據的成本很高。對於“服務器所有者”來說，這需要資源、維護和時間。目前託管Mastodon instance的所有人都是自願的，用戶單純依賴他們的友好，不會關閉instance。 “知識共享”（creative commons）的老問題出現了。
那麼我們能做得更好嗎？
3、另一種方式：Dumb Nostr
如果我們不開發完美的社交媒體，而只是開發最基本的樂高積木，讓開發者就基本標准單元公開達成共識，會怎樣？
這就是Nostr所做的。
這麼做要通過以下方式：
規定社交數據格式的最小單元（一個event），讓開發人員在此基礎上自然達成共識。這就是協議的核心。這是每個人參與網絡都需要同意的最基本的支撐。
Nostr將這些協議規則定義為NIP，進行了一組指令性NIP陳述，規定了與Nostr協議通信需要實現的規則。
在這些指令性NIP之上，任何人都可以定義可選NIP。中繼器可以自由選擇它們支持的NIP集。
event數據可以通過未來NIP定義更多的標記項，在標記字段中擴展。
而Events可以看作是一個通用的數據存儲。對於可以放入其中的內容沒有任何限制。
儘管看起來很奇怪，但如此簡單的協議比許多“精心設計”的現有社交媒體替代方案獲得了更多開發者的關注。
這個項目已經引起了大量開發人員的興趣，社區幾乎瞬間開發出了一個豐富的包括庫、應用程序和中繼器在內的生態系統，並且每天都在發展壯大。
Nostr的Telegram群組大約有400個開發成員，而且每天都在增加。
為什麼？ “因為它非常簡單”。
這種簡單性使任何感興趣的人都可以輕鬆編寫JSON streamer，立即讓協議與任何現有中繼器通信。
人們幾乎經常會在基本NIP的基礎上添加一些新細節。
協議的簡單性允許開發人員快速就開放標準達成共識，並將所有的複雜性放到客戶端。整個應用程序體驗將由客戶端負責，中繼器仍將是傻瓜式數據服務器。這允許開發人員在客戶端應用程序上快速開發和迭代，同時與任何可用中繼器兼容。
這也增強了客戶端的兼容性。有可能有兩個不同的應用程序，但仍然能夠看到彼此的帖子。該平台的核心可以是去中心化的，客戶端通過一個簡單的存儲協議彼此兼容。這就是“dumb server, smart client”模型的巧妙之處。快速達成基本標準，快速迭代客戶端應用。
複雜性可以在客戶端層定制，而互操作性可以在中繼層實現。
4、還需做什麼？
一旦我們實現了核心樂高的建設，餘下要做的還有DOS保護、中繼激勵和一些實現用戶間nostr訂閱數據通信的方法。
將比特幣整合進Nostr
多虧了比特幣，中繼激勵和DOS保護才可以同步完成。
如果基礎設施建立在脆弱的“自願主義”基礎上，那麼就不可能開發出一個強大的社交網絡。正如我們知道的那句話，“如果產品是免費的，那麼你自己就是產品”。這些未來的媒體平台應該與比特幣進行原生整合。
有個實現比特幣與Nostr整合的一站式解決方案，就是使用BDK。一個高性能的比特幣錢包庫，可足夠靈活地處理多種比特幣接口和數據庫。添加了新的NIP來定義支付請求和支付響應Event類型。
對於發布的每個event，支付可以是一次性的鏈上交易，也可以是客戶端和中繼器之間的LN（閃電網絡）支付流。 （將需要BDK + LDK，目前正在積極開發中）。中繼器可以在sats/byte中設置feerate（費率），如果想要義務“自願”，可以選擇將費率設置為0。
這為高度維護的公共中繼器提供了一個很好的服務變現方式，同時保護它們免受DOS攻擊。
端到端加密訂閱共享
請注意，Nostr中繼器只是簡單JSON數據的轉儲，通過訂閱過濾器獲取。這使得nostr成為客戶端之間的通用數據共享平台。集成了比特幣，現在我們要討論的是比特幣scripts、descriptors、DLC合約和其他通過nostr中繼網絡共享的比特幣DeFi信息。但這些可能是敏感信息，不應該在公共平台上以明文形式共享。
為此，需要一種加密的nostr訂閱共享機制。可以是另一個服務器，只用於促進參與者之間的加密訂閱數據共享。
可以通過以下方式實現：
· 使用來自目標接收者pubkey的DH共享秘密進行“訂閱+中繼地址”加密。
· 將加密數據連同接收者的pubkey一起發佈到此服務器。
· 接收客戶端收到消息，下載並解密數據，獲取訂閱以從nostr獲取實際數據。
· 實際數據也是由相同的共享秘密加密的密文，因此接收方知道如何解密。
這些服務器可以是非常輕量級的，因為它們不需要存儲所有歷史訂閱數據。它們可以定期清除舊數據，甚至可以在知道接收方下載了數據後實時清除數據。這將使服務器成本非常低，而且不需要擔心激勵問題。
它們不需要遵循任何通用協議，可以通過任一設計自由實現。它們只需要有一種與客戶端連接的方式，並知道當發生與客戶端相關的事件時何時通知他們。
這些服務器也像nostr中繼器一樣是抗審查的。如果某個服務器停機，任何人都可以再造一個。因為它們不需要保存歷史記錄，所以從一個服務器切換到另一個服務器並不會對整個信息流造成影響。
這些服務器也不能利用數據，因為它們所看到的只是一組加密隨機數據，所以它們不需要很高的安全性。
最終結果
所以現在把所有這些（Nostr，比特幣和加密訂閱共享）相結合，我們得到了一個非常強大和默認設置的私人社交網絡，可以使用一些非常通用和全局性的協議在參與者之間共享數據。
這使得隱秘的社交網絡有可能選擇性地向特定的可信實體公開他們的發帖內容。
這些帖子可以是DLC合約、描述多方間多簽機制的descriptor、僅向訂閱會員公佈的DLC預言機，等等。
在這個框架中，“身份”的基本單元是pubkey。 pubkey類似於現實世界裡的暱稱。任何人都可以有隨意數量的暱稱。如果一個暱稱被洩露，可以迅速創建出另一個，就像我們每次付款都要創建一個新的比特幣地址一樣。
使用pubkey作為暱稱，然後可以選擇性地向自己的私人可信網絡開放。你可以將一個pubkey與你的全局暱稱關聯（每個人都知道的Twitter操作），然後持有任意數量的並行暱稱，僅在特定人群間通信，或者使用特定的應用程序。
與所有這些pubkey相關的數據間保持完全不相關性，可以跨多個nostr中繼器分佈。
最終模型總結如下：
· 一個高度互操作的、極其簡單的中繼協議——nostr。
· 一個靈活的框架，可通過中繼器可選的升級選項添加新的中繼功能。
· 用於傳遞nostr訂閱的加密訂閱共享機制。
· 比特幣原生集成，方便“貨幣互聯網”和DOS保護同時進行。
· 一個去中心化的發行層，客戶端可以發佈公共和私有內容。
· 有較好的客戶端複雜性來詮釋這些內容，並具有應用比特幣功能的可生成原生金融合約的UI。
與web3.0不同的是，這一切並不會涉及到另一個“區塊鏈”。
5、前路分析
儘管聽起來不錯，但我們還沒走到那一步。實現這些想法需要大量的工程設計。前進的道路上還有未知問題需要解決。這些中繼器和客戶端的設計決策需要仔細規劃。僅有一個簡單的協議是不夠的。
中繼器應該高效、可靠，經過公開嚴格的同行評審，並保證基本安全。工作必須公開開展，並且組件應該設計得盡可能靈活，以滿足不同的客戶端開發人者需求。
如果這個過程需要擴展到專業化的服務，人們可以在自己的服務器上部署這些服務，並會基於此開發出像樣的產品，那麼我們需要的就不僅僅是業餘代碼和示例應用程序了。
我們需要的不是另一個很酷的nostr應用程序，而是一個經過深思熟慮的設計卓越的基礎設施庫，可以讓隱秘的超級程序員使用它來開發下一個很酷的集成比特幣的nostr應用程序。
6、引入rust-nostr
rust-nostr是一個處於想法階段的項目，旨在解決上述問題。我們的想法是提供一個完整的nostr基礎設施一站式套件，它是模塊化的，易於擴展的，具有強大的安全保障，有良好的文檔，非常容易讓開發人員根據自己的需要進行定制，非常容易下載、部署服務器，易於管理。
整個結構仍處於TBD階段，但rust-nostr的大概模樣如下：
· 一個生成nostrd的binary crate。 Nost中繼器的輕量級、高效的rust實現。 nostrd將附帶一組支持的NIP。默認情況下可包含基本的NIP。額外的NIP可以在構建時通過feature flag指定。
· 一個可以用作服務器端nostrd管理器的nostrd-cli。它還可以讓nostr協議與任何其他中繼器通信，並可作為一個cli nostr客戶端被使用。可以通過基本身份驗證或cookie身份驗證向中繼器提供維護入口。
· 一個豐富的nost-API庫，包含在項目中，可作為開發人員開發nostr客戶端的簡便開發工具。然後，這些API可以通過ffi向其他語言公開，並為開發人員提供一站式工具來建設他們的優秀Nostr客戶端。
portal是一個加密的nostr訂閱共享服務器。 portal規範不是項目的組成部分，因為它是一個已解決的問題。這在密碼學文獻中已經得到了很好的解釋，並且有很多開源的候選實現方案。 Signal App本身就是portal的一個例子，儘管在這個用例中很難使用。印度的一支本地團隊一直專注於這個問題，針對p2p比特幣交易的特定用例（稱為CypherPost），這已是一個非常合適的portal實現。最終，rust候選實現方案的精簡版本將被添加到項目庫中。但是人們可以自由地開發並使用他們自己的portal，且仍然與網絡的其他部分兼容。
所有這些（portal除外）都將通過BDK和LDK進行原生比特幣和閃電網絡集成。
為了確保基礎設施的所有部分都能始終保持同步，他們將在項目的CI pipeline進行嚴格的集成測試。
一旦所有這些都安排妥當，就可以使用rust-nostr套件開發各種更複雜的客戶端，在各客戶端之間開展比特幣DeFi業務。
7、結語
到目前為止，這只是一個初步想法，我甚至不知道未來有可能面對什麼樣的挑戰，但我預計挑戰不會少。常言道：“細節決定成敗”。這似乎是一個雄心勃勃的項目，但並非如此。
通過限制項目範圍以提供非常具體的開發工具，這幾乎可以通過若干積極的rust開發人員來實現。 Rust也是最適合用於此類開發的語言，因為它允許我們在編譯器級別嚴格定義協議規則，從而減少錯誤空間，同時生成非常簡潔且易於審計的代碼。
不搭建“產品”，只解決樂高積木的問題，我認為通過這一方式，我們的想法是完全可以實現的。
這個項目可以為比特幣創業家開發各種應用鋪平道路。應用空間的疆域只受想像力的限制。
