貢獻者：DAOctor @DAOrayaki
審核者：Shaun @DAOrayaki
第五權利下的新型社交媒體設計已經探索多年，卻並沒有被大規模採用的跡象。在過去的一年裡，隨著加密技術的不斷發展，以及對馬斯克收購推特的擔憂，去中心化社交網絡迎來新的機會。
這些社交網絡試圖解決的問題：可能包括加強審查制度，使內容審核更加靈活，削弱大型社交媒體公司塑造和跟踪人們在網上談論的內容的權力等。
隨著新平台的出現和增長，對替代社交網絡的選擇往往帶有政治考慮因素。
如Getr、Parler、Gab 和Truth Social 這樣站點，都通過將自己宣傳為Twitter 的言論自由替代品來迎合右派。
我們今天要討論的是，最近廣受關注且具有一定創新性的新型社交媒體協議Nostr-Damus。其中包括Nostr的技術原理、待解決的關鍵管理問題及如何激勵中繼持續運轉。
背景：Nostr
Nostr 於2020 年啟動，是一種去中心化協議，允許用戶擁有自己的身份並使用公鑰-私鑰加密的數字簽名來驗證帖子。然後，這些帖子會傳播到互連服務器網絡。該協議並未使用區塊鏈，因為在早期實驗中發現區塊鏈對於社交網絡來說太慢。但在結構上存在相似之處，Nostr 憑藉其自由主義和開源精神在加密人群中找到了早期的利基市場。
Mastodon VS Nostr
Nostr 協議和第一個中繼服務器由開發人員fiatjaf 在2020 年底創建。在引起廣泛關注之前，Nostr 只是一個安靜的小眾協議，致力於成為Twitter 和Mastodon 問題的輕量級解決方案。
Mastodon，一個成立於2016 年的開源網絡，允許任何人設置服務器。該設計通常被描述為“聯合”，並且可能屬於也可能不屬於“Web3”的模糊界限，具體取決於如何定義。 Mastodon允許用戶加入具有自定義內容審核規則的策劃社區。目前註冊用戶達到200w+，成為了自由派、記者和學者的避風港。
Twitter 和Mastodon 系統中，身份/用戶名是由運行服務器的人控制。
Nostr的核心區別在於：每個用戶都使用公鑰/私鑰對來處理該功能，而不是使用服務器運營商所擁有的用戶名，使得Nostr抗審查。這是構建整個Nostr 協議的核心構建塊之一。
“事件”：這是客戶端和客戶端為了發送和檢索消息而連接的中繼服務器使用的基本對象/數據類型。該協議的總體思路是，客戶端將事件發送到中繼服務器，中繼服務器隨後存儲和索引它們，其他客戶端可以與中繼服務器通信以請求它們已接收和存儲的事件。在最初的NIP 01 中，定義了三種不同的事件類型：
0：發送有關用戶的元數據，例如用戶名、圖片、簡介等。
1：發送短信和基本內容
2：推薦中繼服務器供關注事件創建者的人連接
所有事件都以特定定義的方式構建。包括創建者的公鑰、創建時間戳、類型（或規範中的種類）、內容有效負載和事件創建者的簽名。另外，還可以有引用其他事件或用戶的標籤，並且有一個ID 值，該值是除創建者簽名之外的所有內容的哈希值（類似於比特幣交易的TXID）。
這讓用戶可以通過驗證簽名（以及擁有該密鑰的人，如果它沒有被破壞的話）來保證信息確實是由其中的公鑰所有者創建的，並保證信息在他們簽署後沒有被修改。
就像不能在比特幣交易簽署後改變它而不使其失效一樣，用戶也不能在Nostr事件的創建者簽署後改變它而不使其成為明顯的欺詐。
事件類型系統從最初的NIP 得到了相當大的擴展。有一種事件類型用於加密的直接信息，通過結合發送方的私鑰和接收方的公鑰來建立一個共享密鑰，其結果與你通過結合發送方的公鑰和接收方的私鑰得到的密鑰相同（這就是BIP 47和沈默支付的工作方式）。也有可替換事件和短暫事件的類型。在可替換事件的情況下（很明顯），它們被設計成事件的原始創建者可以簽署一個新的事件來替換舊的事件。遵循該規範的中繼服務器將自動從其存儲中刪除舊事件，並在收到後開始向客戶提供較新的版本。短暫事件的設計是這樣的：當發送到中繼站時，它們將被廣播給任何訂閱其創建者的人，但中繼服務器不應該存儲它們。這就創造了一種可能性，即在其廣播期間，只有在線的人才能看到消息。甚至還有一種事件類型，用來表示對其他人的事件的反應（如喜歡或表情符號）。
說到最後一個問題，事件也可以包含標籤。目前有事件（引用一個確切的Nostr事件）、公鑰（標記或引用其他用戶）和主題（模仿功能，如電子郵件主題）的標籤類型。所有這些都可以包括指向特定中繼服務器的指針，從這些服務器上可以獲取數據，這樣用戶就可以在不同的服務器上進行實際的互動，也就是說，一個用戶在一個中繼服務器上發布他們的內容，可以與另一個用戶在不同的中繼服務器上發布的內容進行互動和引用，這樣就可以讓任何用戶以適當的順序連貫地獲取整個交互線程，而不需要在找出相關數據的地方進行大量的複雜操作。
在原始NIP 中，給出了客戶端如何通過訂閱消息/數據結構與中繼服務器交互的規範，該結構包括客戶端有興趣接收哪些事件的過濾器。這些過濾器可以根據先前的標準指定用戶的公鑰、確切的事件、事件類型，甚至是他們想要的特定時間範圍。用戶甚至可以提交公鑰或事件ID 的前綴，例如“1xjisj ...”。並從以該短字符串開頭的公鑰接收任何一個或多個事件（這對於從中繼服務器隱藏實際想要查看的內容非常有用）。
總的來說，協議是一個非常簡單的通用方案，用於在用戶之間傳遞消息，涵蓋了重要的事情，例如保證消息的完整性以及使用公鑰身份發送消息的人，同時還促進了後端基礎設施中繼服務器可以是高度集中的或允許用戶運行他們自己的個人中繼服務器，同時彼此無縫交互並且在用戶被禁止使用一個中繼服務器的情況下不會造成大規模混亂。他們可以轉移到另一個服務器或運行自己的服務器，並且他們從之前的服務器上脫離平台並不會失去他們的數字身份或追隨者，因為他們仍然保持對私鑰的控制，並且用戶可以在其他地方找到他們時對其進行身份驗證。
中繼服務器也可以隨心所欲地運行：免費運營、收取小額費用來發布或下載消息，甚至還有一個NIP 要求hashcash 樣式的工作證明來提交消息。它們可以是一個單一的中繼服務器，用於託管帖子並將其僅提供給其他用戶，或者一個大規模運行的服務器，例如Twitter 或Reddit（客戶端可以根據需要顯示和組織信息，這允許模擬任何社交媒體） 。所有這些都可以無縫互操作，並且不會將用戶拒之門外。
Nostr 待解決的關鍵管理問題
用戶公鑰/私鑰是Nostr 作為協議工作方式不可或缺的一部分。這起到了實際用戶與其他人如何識別他們之間緊密綁定的作用，以防止任何中繼服務器解除這兩件事的綁定，即將某人的標識符提供給另一個用戶。也解決了用平台最大的問題之一：缺乏對用戶自身身份的控制。
不過這也引入了新的問題：密鑰可能會丟失，密鑰可能會受到損害，如果發生此類事件，用戶將無法尋求幫助。
這將不可避免地需要一種方案，讓用戶以一種可驗證和可發現的方式從一個密鑰對轉換到另一個密鑰對，並可讓他們通過協議與其他用戶互動。整個協議是基於證明一個事件來自一個特定的用戶（身份密鑰），所以一旦某人的密鑰被破壞，所有這些保證都會被拋到九霄雲外。
Nostr 需要一個實際的密碼方案，將一個密鑰的輪換與另一個密鑰聯繫起來。開發人員fiatjaf 提出了一項可能解決此問題的基本方案的提案。基本思想是採用從單個主種子派生的一長串地址，並創建一組“調整後的”密鑰，類似於Taproot 樹如何提交給比特幣密鑰。 Taproot 獲取Taproot 樹的Merkle 樹根並將其“添加”到公鑰以創建新的公鑰。這可以通過將該Merkle 樹根添加到私鑰來複製，以獲得與新公鑰匹配的私鑰。 Fiatjaf 的想法是將承諾從末尾向後鏈接到開始，這樣每個經過調整的密鑰實際上都會包含下一個經過調整的密鑰用於創建它的證明。
所以，想像一下從密鑰Z 開始，鏈中的最後一個。你可以用一些東西來調整它，然後返回並使用調整後的密鑰Z (Z' + Y = Y') 創建密鑰Y 的調整版本。從這裡您可以獲取Y'，然後用它來調整X (Y' + X = X')。你會一直這樣做回到密鑰A，得到A'，然後從那裡開始使用該密鑰。當它被破壞時，用戶可以廣播一個包含未調整密鑰A 和調整密鑰B' 的事件。這將包含顯示B' 用於生成A' 所需的所有數據，並且用戶可以立即停止關注A' 並轉而關注B'。他們會明確地知道B' 是該用戶的下一個密鑰，並改為遵循該密鑰。
不過，這個提議仍然存在一些問題。首先，必須提前生成將要使用的所有密鑰，並且無法輪換到一組全新的密鑰。這可以通過在這個方案中提交一個可以公證這種輪換的主密鑰來解決，或者簡單地從一開始就生成一組非常大的密鑰。任何一條路徑都是可行的，但最終需要保持根密鑰或密鑰材料的安全，並且只向Nostr 客戶端公開單個快捷鍵（Hotkeys）。
然而，該方案不會保護用戶或提供在根密鑰材料丟失或本身受到損害的情況下進行身份恢復的機制。
為了在這裡對潛在的解決方案進行一些討論，換一種思考，將一個密鑰調整為一個主冷密鑰，該主冷密鑰還必須用於簽署從一個密鑰到另一個密鑰的事件輪換。您有密鑰A'，它是通過添加A 和M（主密鑰）派生的，輪換事件將是A、M 和B'（通過添加B 和M 生成）以及M 的簽名。 M 可以是多重簽名閾值密鑰——三分之二、五分之三等。這可能會增加冗餘以防丟失，並為密鑰輪換提供安全機制。這也打開了使用服務來幫助恢復或將其中一些密鑰傳播給可信賴的朋友的大門。它提供了與比特幣本身的多重簽名相同的靈活性。
NIP26 也是一個可能對處理這個問題非常有用的提案。這指定了事件的協議擴展，允許來自一個密鑰的簽名授權另一個密鑰代表它發布事件。然後，“令牌”或委託的簽名證明將包含在第二個公鑰代表第一個公鑰發布的所有事件中。它甚至可以是有時間限制的，因此委託令牌會自動過期並且必須更新。
密鑰管理和安全問題是一個非常大的問題，具有非常大的設計空間，充滿權衡和痛點。但，Nostr如果不能為用戶保護和維護這些身份的完整性，則完全基於用作身份的公鑰/私鑰對的協議，將不能被大規模的採用。
Nostr 面臨的擴展
整個Nostr協議依賴於某個地方的人運行一個中繼服務器。沒有"Nostr網絡"，只有中繼和連接到中繼的客戶端。需要激勵人們運行中繼器，從長遠來看，這最終將是中繼器能擴展到什麼程度的一個重要部分。除非Nostr中繼可以盈利，或者至少可以帶來足夠的資金來支付自己的運營成本，否則永遠不會有與Twitter服務器同樣規模的中繼。
廣告
考慮到Nostr 作為協議的工作方式，完全阻止廣告將非常微不足道，使其成為不可行的解決方案。中繼服務器可以嘗試使用廣告作為一種收入模式，這顯然是幾乎所有在線免費服務的主要收入模式，但問題在於用戶基本上必須選擇加入。中繼可以很容易地將廣告注入到它們發送給客戶端的事件中，但如果廣告事件不是由它們有意訂閱的公鑰創建的，客戶端也可以很容易地將它們從用戶界面中過濾掉。
小額支付
小額支付是另一個明顯的解決方案，特別是考慮到目前正在嘗試將閃電網絡更緊密地集成到Nostr 應用程序中。這種模式在如何收費方面提供了很大的靈活性。中繼可以只對在那裡發布事件收費，也可以對下載事件閱讀收費，還可以將兩者結合起來，並根據兩者消耗的資源多少來調整每一種的價格。不過，這種模式能否擴大到像Twitter那樣的規模表示懷疑。
內容小額支付在許多基於閃電網絡的利基產品中顯示出自己的可行性，但真正擴展到全球規模存在兩個基本問題。
首先，目前還沒有足夠的比特幣採用。即使每個人都神奇地接受為Nostr 上的每一次小服務交互付費，也沒有足夠多的人持有比特幣來支持像Twitter 這樣大規模的比特幣。中繼可以通過法幣收取訂閱費用，但這些支付方式不會支持為每個發布或下載的事件支付一小部分費用。其次，人們實際上已經習慣了這種免費服務。這正是人們所期望的。我並不認為靠小額支付就能真正支持大規模的中繼。
有一種方法可以使小額支付"更有粘性"或更有可持續性，而不需要把它們強加給使用中繼的每一類用戶。關於在Nostr之上建立各種應用的討論已經很多了，除了Twitter的克隆。 GitHub、維基百科，甚至是Uber。
最後一個是關鍵：經濟期望。人們非常習慣於在某處發布招聘廣告時支付費用，或在網上訂購東西時向市場運營商支付一定的費用，但不會為認為應該免費的商品提供服務—谷歌、推特。這可以為中繼站提供一種方法，從他們的用戶那裡創造一個可靠的收入支柱，而不產生大量的摩擦或打破一般潛在用戶的期望。
如果小額支付也將成為一個因素，那麼中繼運營商將不得不運行一個閃電節點，以便首先從用戶那裡接收資金。如果與中繼實施的任何小額支付模型適當協同，這可能會增加收入。中繼服務器的收入越大，它在閃電網絡上需要的流動性就越大，以促進這一點。如果運營商正確地規劃他們如何在網絡中部署或分配流動性，那麼除了通過中繼接受或傳輸數據收取的任何費用外，僅運行路由節點的行為本身就可能成為一個不小的收入來源。
結論
Web3 社交項目，除了以上提到的Nostr和Mastodon之外，還包括Farcaster 和Lens 等項目，它們並不會快速取代現有的社交媒體平台。據統計，Twitter 有數億活躍用戶，Facebook 有數十億，但Mastodon 只有250 萬用戶， Nostr 僅大約22w 個唯一用戶身份。許多Web3的社交項目都面臨著可用性障礙，這些障礙會減慢大規模採用速度。
媒體與政治必不可分。隨著Web3 社交項目的激增和公共對話在不同應用程序和協議之間的分裂，可能會產生政治結果。即使，墨西拿長期以來提倡去中心化社交媒體，但仍擔心去中心化會進一步加劇近年來以相互敵對和誤解為標誌的公共話語。
APP 
