原文標題：《The Billion User Social Graph》
原文作者：Jon Stokes
原文編譯：Dan，W 3.Hitchhiker
隨著埃隆 – 馬斯克最近接管了 Twitter，關於從大型社交網路遷移到獨立或開放的替代方案的討論已經越來越多，但是所有那些剛開始幻想在加入繁榮的 Twitter 前居民社羣的人，很快就會遇到自 J 6 之後的跨平臺社交媒體大清洗以來，右派一直在努力解決的問題：網路鎖定是真實的。
文章目錄
你可以對協調問題、偏好級聯、訊號和其他遊戲理論式的概念進行理論和策略分析–我不否認這些都是理解問題的有用方法–但要理解 Twitter 和 Facebook 對我們數億人的強大影響，你真正需要知道的是網路時代初期的一個簡單啟發式方法。
梅特卡夫定律指出，電信網路的價值與系統的連線使用者數的平方成正比（n 2 ）。梅特卡夫定律最初是由 George Gilder 在 1993 年以這種形式提出的，並歸功於 Robert Metcalfe 在乙太網方面的工作。大約在 1980 年，梅特卡夫定律最初不是以使用者為單位，而是以「相容的通訊裝置」（如傳真機、電話）為單位。只是後來隨著網際網路的全球化，這一定律才延續到了使用者和網路，因為它的初衷是描述乙太網連線。
要讓人們放棄一個大的、密集的網路圖，而選擇一個小的、稀疏的網路圖，幾乎是不可能的，唯一的原因是前者有價值，而後者沒有。
不過奇怪的是，web3 解決了這個問題。或者至少如果我們使用一些簡單的智慧合約，將區塊鏈從一個巨大的使用者表變成一個巨大的社交圖譜，它可以解決這個問題。
理論依據和以往的工作
區塊鏈可以而且確實作為一個巨大的、共享的使用者表發揮作用，它是開放的、公開的，不受任何一個實體控制。正如我在《十億使用者表》中寫的那樣：
公共區塊鏈相當於整個網際網路的一個單一的、大規模的使用者表，下一波分散式應用將建立在它之上。
取而代之的是一個由 API 連線的分散的使用者資料倉網路，一個透過開放協議和分散的儲存節點網路訪問的單一分散的使用者資料儲存。因此，身份託管區塊鏈代表了資料儲存實施層的去中心化，以及資料儲存訪問層的再中心化。
想象一下，LinkedIn、Reddit 和 Github 都將他們的使用者表（以及他們的許多專有資料，如認可、積分和活動歷史）移植到 BitClout。馬上就會發生以下情況：每個 Github 使用者也是 Reddit 使用者、LinkedIn 使用者和 BitClout 使用者。同樣，每個 Reddit 使用者也是 Github 使用者、LinkedIn 使用者和 BitClout 使用者。我可以繼續說下去，但你會明白這一點。
每個建立在同一虛擬使用者表上的公司都能立即獲得該表上其他每家創業公司的網路效應。每當一個鏈上公司加入一個新的使用者，那麼你的服務也有一個新的使用者。( 從某種程度上說。他們可能還沒有積極使用你的服務，但他們實際上在你的服務的潛在使用者）。
先前的那篇文章用 Bitclout（該專案中的鏈現在被稱為 DeSo）作為可以支援這種用例的區塊鏈的典型例子。但是，儘管我對 DeSo 的整個事情感到興奮，但它的結果並不那麼好。
這裡不適合做 Bitclout / DeSo 的事後總結，但標出該區塊鏈的一個方面是有意義的，因為它對現在的討論很重要。Bitclout 努力將整個社交網路放在鏈上，每個帖子都被寫在鏈上，作為一個物件，可以累積收入（透過 Bitclout 鑽石）。這很聰明，但任何試圖承載實際內容的區塊鏈都會看到其資料需求隨著使用者和連線的數量而非線性增長。
Bitclout 團隊非常熟悉這種無限制的資料增長問題，並花費了大量的實際工程努力來解決這個問題。但事後看來，我實際上認為他們試圖同時做太多的事情。他們應該只專注於社交圖的可移植性問題。
用我之前文章中的資料庫術語來描述，Bitclout 試圖把以下所有的表都放在鏈上（另外還有一些是 Bitclout 特有的）：
- users
- user_follows_user
- posts
- user_likes_post
最後兩張表總是出現資料爆炸，在使用者迅速增長的情況下都會變得不容易操作。
因此，我認為更好的方法是採用現有的區塊鏈，它基本上已經是那個第一張表（即使用者），並在其中新增一個 user_follows_user 連線表。( 我們還可以為其他型別的關係擴充套件連線，如 user_mutes_user，但目前我們還是保持簡單的。)
這個使用者對使用者的連線表也會隨著使用者數量的增加而非線性增長，但增長速度會比較慢，更重要的是，為了表示它所需要的額外資料量（=它所消耗的額外塊空間量）將遠遠低於帖子表。
我這樣建議是因為使用者和粉絲關係構成了每個大型社交網路平臺鎖定的主要來源。如果你的整個 Twitter 或 Facebook 的社交圖譜都是開放的，並且可以隨時提供給其他想要託管帖子和其他更多資料密集型的社交網路體驗的社交平臺，那麼這些平臺的鎖定性基本上為零。
鏈上社交圖譜可能是怎樣的
想象一下，我的整個推特圖是在鏈上體現的–包括實際的賬戶和追隨者關係。為了檢視該圖中的 Twitter 帖子（以及相關的喜歡、轉發、引用 – 轉發等），我需要用我的錢包連線到 Twitter.com。但是，假設我想跳轉到 tribel.com，或 gab.com，或其他一些有自己特殊傾向和節制政策的社交平臺–如果他們能從區塊鏈上讀取我的社交圖譜，那麼我可以在那裡連線我的錢包，看到同樣的連線，並看到他們在這個其他網站上的任何帖子。
這聽起來可能沒那麼有吸引力，但考慮到這樣一個事實：如果我在 Tribel 上關注一個新的人，那麼我現在也在 Twitter 和 Gab 上關注這個人–以及在其他所有使用相同鏈上圖的使用者和關係的社交平臺上。取消關注和遮蔽的工作方式也一樣–在一個地方做一次，你的圖譜的變化就會立即反映在所有地方。
現在，那些在閱讀時想利用這一點的已經意識到，在一個如上所述的世界中，將不可避免地發生什麼：有人會製作一個全能客戶端，讓你透過一個介面從任何或所有這些網路中閱讀和釋出資訊。那麼，擁有獨立的服務就沒有意義了，他們都會倒閉……或者他們會嗎？
未來事物的預演：電話號碼 聯絡人 訊息應用程序
我所描述的世界已經以一種原型狀態存在，以競爭性資訊協議的形式存在，這些協議都與你的電話號碼相聯絡，並從你的聯絡人資料庫中填充自己。電話號碼系統是億萬使用者表的原型，而分散式的聯絡人應用程序都可以讀寫標準的 Vcard 格式，構成了建立在該表之上的關係圖。
有許多資訊傳遞協議都是藉助於這種電話號碼 聯絡人的組合，其結果有點像我在這裡描述的社交網路。例如，當你第一次登入 Telegram 時，它會掃描你的聯絡人，然後你立即在這個新的應用程序中擁有你現有的網路。
其結果是，你可以選擇透過 Signal、Telegram、WhatsApp、iMessage 或傳統簡訊與相同的電話號碼交換資訊–這一切都在於你和你的網路中的其他人想使用哪種資訊協議。
還有一個永恆的迴圈，就是訊息應用的去中心化和再中心化，這從 ICQ 時代就開始了，在 WhatsApp / Signal / Telegram / Facebook / 等的時代仍然在發生。你可以找到任何數量的多合一訊息客戶端，在一個視窗中支援許多這些平臺。
這些資訊應用都沒有受到損害，因為它們都從同一個開放的電話號碼系統和可互操作的聯絡人應用和服務生態系統中獲取身份–它們都共存並帶來不同的東西，而且我們中的許多人在它們之間切換，與我們聯絡人中具有不同需求和偏好的不同子圖交談。如果我們把社交圖譜移到鏈上，我希望這種動態會持續下去。
關於可組合性和社交關係
不同的平臺有不同型別的社交連線，使用者可以相互之間的連線。Facebook 有朋友、關注和遮蔽。Twitter 有關注、靜音和遮蔽。這些對於這些平臺來說是很好的，但我們可以改進它們，使它們更適合區塊鏈，使它們更具有可組合性。
可組合性是一個電腦科學術語，大概意思是，你可以混合和匹配這些小的、離散的、明確定義的工具，以獲得不同的效果和功能。
考慮到 Facebook 的「朋友」–這是它自己的連線型別，但它也意味著「關注」，因為當你把某人加為好友時，你會自動關注他們。在 Twitter 上，「封殺」意味著「靜音」，因為當你遮蔽某人時，你基本上是在讓他們靜音，同時也阻止他們看到你的帖子。
對於我自己的兩個社交圖譜的建議，下面，我想建議跟隨，更乾淨和可組合的社交圖譜關係集：
- 關注： 你可以閱讀你所關注的人的帖子。
- 靜音： 你不能閱讀你已經靜音的人的帖子。
- 遮蔽：你遮蔽的人不能閱讀你的帖子。
在這個方案下，一個封殺是一個「靜音」加一個「遮蔽」，所以它是對同一個目標地址的兩個操作，一起組成的（例如，如果我想封殺 annoyinghater.eth，我就把這個地址靜音，再把它的遮蔽）。
如果我想看到某人的帖子，但又不想讓他們看到我自己的帖子，我可以關注他們，再加上遮蔽。或者，如果我想保留透過導航到他們的內容或定期取消他們的靜音來閱讀，我可以關注加靜音。
我試圖以這種方式理清關係，因為它使我們更容易推理接下來的章節中的合約和關係。
我的兩項提案的一些背景
在本文的其餘部分，我提出了兩個將社交圖譜分層到十億使用者表中的建議。
- 第一種，On-Chain Graph（OCG），更加開放和簡單，但在費用方面也更加昂貴，所以有些人會喜歡它，有些人不會。
- 第二種，鏈式圖（CLG），更復雜但更便宜，而且提供更多的控制和隱私，所以我預計大多數人會更喜歡它。不過，平臺可以同時支援這兩種方式。
- 要真正理解這兩個提案，你需要對以下概念有一些基本的熟悉：
- 不可拆分的代幣（NFT）和不可拆分不可轉讓的代幣（NTFT，也叫靈魂繫結的代幣）。
- 以太坊域名服務
- 智慧合約
瞭解一點 Solidity（以太坊的智慧合約程式語言）也會有所幫助。如果你對上述一項或全部內容模糊不清，我試圖以一種你應該仍然能夠掌握基本知識的方式來寫這篇文章。
對於這兩個提案，我假設我們使用 ENS 作為身份的根，並向其新增新的地址記錄，其中包含一些相當標準的 ERC 721 NFT 合約的地址，這些合約分別代表我上面概述的三種型別的社交關係（跟隨、靜音、遮蔽）。這三個合約的作用從一個提案到另一個提案都非常不同，但把它們的地址放入三個特殊的 ENS 地址記錄的基本想法保持不變。
我還想為社交使用者資料 URI 提出一個額外的 ENS 記錄，這樣你就可以更新你的社交資料而不需要消耗 gas。一個擬議的 profileURI 記錄將連結到一個藏在某些第三方平臺上的 JSON 物件，看起來像這樣：
curl https://jonstokes.com/jons-profile.json
-H “Accept: application/json”
{
“name”: “jonstokes.(eth|com)”,
“bio”: “Writer. Coder. Doomer Techno-Optimist. Cryptography Brother.”,
“website”: “https://jonstokes.com/”,
“location”: “Austin, TX”
}
檔案 JSON 中的一些內容與現有的 ENS 欄位是多餘的，但這沒關係；這樣做的目的是為了給社交平臺提供一些可以顯示的東西，並讓使用者能夠對他們的社交檔案進行修改，而無需花費 gas 來更新 ENS 記錄。
建議 1 ：鏈上圖
On-Chain Graph 的想法使用 NTFT 來表示上述的三種關係。對於以下三個社交合約，持有 ENS NFT 的同一個錢包也應該擁有這些合約，它們的三個對應的 ENS 地址記錄應該指向這些合約：
- OCG 追隨者： 當你從我的 OCG 追隨者合約中存入一個 NTFT 到你的錢包，那麼你就跟隨了我。我們中的任何一個人都可以銷燬這個 NFT，使你取消對我的關注。
- OCG 遮蔽： 當我從我的 OCG Ghosted 合約中空投一個 NTFT 到你的錢包中時，我就對你產生了遮蔽。只有我可以銷燬這個 NTFT 來解除對你的困擾。
- OCG 靜音： 當我從我的 OCG 靜音合約中空投一個 NTFT 到你的錢包時，我已經把你靜音了。只有我可以銷燬這個 NTFT 來解除你的靜音。
這三種情況的語義基本上都是：「相對於我，即合約所有者，你是 X」，其中「X」是追隨者、遮蔽、靜音的一種。
這裡有一個追隨者合約樣本：
// SPDX-License-Identifier: MIT
pragma solidity ^ 0.8.4;
import “@openzeppelin/contracts/token/ERC 721/ERC 721.sol”;
import “@openzeppelin/contracts/token/ERC 721/extensions/ERC 721 Enumerable.sol”;
import “@openzeppelin/contracts/security/Pausable.sol”;
import “@openzeppelin/contracts/access/Ownable.sol”;
import “@openzeppelin/contracts/token/ERC 721/extensions/ERC 721 Burnable.sol”;
import “@openzeppelin/contracts/utils/Counters.sol”;
contract OCGFollower is ERC 721, ERC 721 Enumerable, Pausable, Ownable, ERC 721 Burnable {
using Counters for Counters.Counter;
Counters.Counter private _tokenIdCounter;
constructor() ERC 721(“OCGFollower”, “OCGF”) {}
function _baseURI() internal pure override returns (string memory) {
return “https://jonstokes.com/ocg/follower”;
}
function relationship() public {
return “ocg follower”;
}
function pause() public onlyOwner {
_pause();
}
function unpause() public onlyOwner {
_unpause();
}
function safeMint(address to) public {
//Prevent anyone but the owner from minting
//a token to an address they don’t own.
require(isOwner(_msgSender()) || (_msgSender() == to), “Unable to mint to this address”);
uint 256 tokenId = _tokenIdCounter.current();
_tokenIdCounter.increment();
_safeMint(to, tokenId);
}
function _beforeTokenTransfer(address from, address to, uint 256) pure override internal {
//Disable token transfers.
require(from == address( 0) || to == address( 0), “Cannot be transferred.”);
}
// The following functions are overrides required by Solidity.
function supportsInterface(bytes 4 interfaceId)
public
view
override(ERC 721, ERC 721 Enumerable)
returns (bool)
{
return super.supportsInterface(interfaceId);
}
}
如果你熟悉 Solidity，你可以看到這個非常簡單（而且未經測試！）的合約試圖做什麼。
首先是擴充套件：
- ERC 721 Enumerable 擴充套件被包括在內，因此代幣持有者可以被社交網路客戶端列出來，而不必掃描整個鏈。
- 我使用 Pausable 是因為你應該能夠暫停造幣，以便基本上鎖定你的賬戶一段時間，即停止接受新的粉絲。
- Ownable 是必不可少的，因為有些事情只有合約所有者應該做。我認為沒有必要使用更強大的角色功能。
- ERC 721 Burnable 在這裡，因為你需要能夠銷燬代幣，以便刪除關注關係。這裡麵包含的標準 burn() 函式有我們需要的許可權，即只有所有者或令牌所有者可以銷燬代幣。
- 我包含了 Counters，這樣 tokenID 就會自動遞增，這很方便。
現在對 OpenZeppelin 嚮導的輸出進行修改：
- safeMint() 被修改後，只有合約的所有者可以將代幣鑄幣到其他人的地址。對於所有非所有者，你只能向你呼叫合約的地址鑄幣。
- _beforeTokenTransfer() 被重寫，這樣它就基本上禁止了轉讓代幣的能力，創造了一個簡單的靈魂繫結的代幣。
- relationship() 函式是一個方便的方法，確保有一個簡單的方法來查詢合約並確認 NFT 代表什麼樣的關係。我並不贊成包括這個，但它似乎很有用。
這一切真的很簡單，對於 OCG 的遮蔽和 OCG 的靜音變體，你要做以下小改動：
- 改變合約名稱和符號
- 改變 relationship() 和可能的 baseURI() 的返回值，以反映你所代表的關係（即，「muted」或「ghosted」）。
- 把 safeMint() 和 burn() 都變成 onlyOwner 函式，這樣只有合約所有者可以呼叫這兩個函式。
顯然，這將取決於平臺是否以正確的方式履行這些合約（即關注、遮蔽、靜音）。不過，這沒有聽起來那麼有威脅性和不穩定，因為如果一個特定的社交平臺不履行你所關心的合約，就不要使用它。
增加付費關注
你可以在 safeMint 中加入 payable，然後使用 setMintRate 來設定人們必須為以下內容向你支付的價格。因此，類似於這樣的內容：
uint 256 public mintRate = 0.01 ether;
function setMintRate(uint 256 mintRate_) public onlyOwner {
mintRate = mintRate_;
}
function safeMint(address to) public payable {
// Require pay-to-follow
require(msg.value >= mintRate, “Not enough ether to mint”);
//Prevent anyone but the owner from minting
//a token to an address they don’t own.
require(isOwner(_msgSender()) || (_msgSender() == to), “Unable to mint to this address”);
uint 256 tokenId = _tokenIdCounter.current();
_tokenIdCounter.increment();
_safeMint(to, tokenId);
}
我相信我還能想到許多其他的調整和功能來新增到這個建議中，但最好從簡單和容易理解的東西開始。
建議 2 ：鏈式連線圖
上面描述的 OCG 合約足夠簡單，但該方案有一些特質，可能會使很多人產生分歧：
- 所有的東西都是公開的，在鏈上的，包括遮蔽和靜音。你不能這樣做鎖定賬戶，但解決這個問題的辦法可能是使用一個替代賬戶。
- 每一個行動都要花費 gas，這意味著你必須對你關注的人、遮蔽和靜音做出真正的選擇。但如果 gas 費用足夠高，那麼這可能會使網路無法使用。
- 對於一個網路或一個特定的賬戶來說，付費關注可能是也可能不是一個理想的功能，但你會有這樣的選擇。
鑑於不是每個人都會喜歡這個建議的這些特質，我想提出一套替代的社交合約，給使用者和平臺更細化的控制，特別是誰能看到什麼樣的資訊，而且使用成本更低。
鏈式連結圖（CLG）的基本思想： 我們不透過 NFT 直接在鏈上表示社交關係（關注、遮蔽、靜音），而是在鏈下儲存這些關係，並使用鏈上代幣來發現和訪問這些關係。
- 發現： 該合約提供了一個 listURI() 函式，該函式返回一個 JSON 列表的連結，該列表中的 ENS 名稱是你打算宣告某種社交關係的（即，我關注他們，我讓他們靜音，或者我遮蔽他們）。
- 訪問： 如果 listURI() 返回的連結是令牌控制的，那麼合約的令牌就會授予持有者對後設資料中發現的連結的讀取許可權。
那麼該社交關係就不是直接在鏈上的，而是透過一組合約和 URL 與鏈相連。
與 OCG 一樣，三種社交關係中的每一種都由智慧合約來管理，但 CLG 的語義不同：
- 關注：包含一個連結到你正在關注的 ENS 名字的 JSON 列表，由它發出的令牌授予對該關注列表的讀取許可權。
- 靜音：包含一個連結到你正在靜音的 ENS 名字的 JSON 列表，由它發出的令牌授予對該靜音列表的讀取許可權。
- 遮蔽：包含一個連結到一個你正在遮蔽的 ENS 名字的 JSON 列表，由它發出的令牌授予對該遮蔽列表的讀取訪問權。
因此，CLG 令牌的語義是：「這是對我 X 賬戶列表的讀取許可權」，其中「X」是「關注」、「靜音」或「遮蔽」。
你可以把我在這一節中提出的建議看作是我為資訊應用描述的電話號碼 地址簿組合的一個近似物。你的電話號碼是（準）公開的，當你把一個新的訊息應用程序連線到它時，你可以授予或拒絕該應用程序對你的聯絡人的讀取許可權。
在我的 CLG 社交令牌計劃中，你的 ENS 名字就像你的電話號碼一樣是公開的，你發行和撤銷令牌，以便授予和拒絕閱讀與你有某種關係的人的名單。如果你願意，你可以把這些令牌授予隨機使用者，但主要是你要把它們授予社交平臺，以便這些平臺知道誰的帖子要顯示給你，誰的帖子要隱藏（或誰不應該看到你的帖子）。
( 對構成你的社交圖的列表的寫入許可權可能由你正常的 ENS NFT 控制–如果你的錢包裡有你的 ENS 名字，你就可以對列表進行寫入 / 更新 / 刪除的修改。一個可能的替代方案是有第四個社交合約，授予 NTFT 持有者列表寫入許可權，這樣你就可以將列表管理外包給一些第三方）
在鏈下託管這些列表，同時從鏈上指向它們，有幾個好處：
- 你可以透過在託管列表的端點上使用認證來鎖定你的關係，不讓公眾檢視。或者你可以讓它對公眾開放，這樣任何人都可以閱讀它。
- 更新一個鏈下列表不需要花費 gas。
- 這個方案使得與社交供應商互通的社交圖譜託管服務市場得以建立。
- 任何人或服務都可以輕易發現你的列表。
代幣訪問控制和讀取訪問
實現 CLG 合約的關鍵創新是代幣訪問控制。代幣訪問控制背後的概念是，除非你用含有特定訪問代幣的錢包連線到主機，否則你不能訪問主機上的特定資料。
例如，你可以對 IPFS 上的內容進行代幣訪問控制，這樣只有用錢包中的特定 NFT 連線到端點的讀者才能檢視特定的文件。
CLG 使用令牌門為我們的社交合約增加了一些間接性，因此，社交 NFT 不是代表一種特定型別的關係–關注、靜音或遮蔽–而是代表對你的社交圖譜的一部分的讀取許可權。
很明顯，為了使代幣門檻發揮作用，平臺必須尊重它。據推測，如果平臺不尊重代幣訪問控制，你會把你的關係列表轉移到其他平臺，並改變你的合約，必要時重新發布任何 NFT。
另外，要清楚的是，有些人的名單在某些時候會洩露。我們生活在一個個人資料洩露的世界，所以如果資料被託管在某個地方，那麼有些資料就會被洩露。我將在後面的章節中討論一些可能的緩解措施。
合約範本：CLG Follows
下面的合約將是一個標準的 ERC 721 NTFT 合約，與上述 OCG 的合約非常接近：
// SPDX-License-Identifier: MIT
pragma solidity ^ 0.8.4;
import “@openzeppelin/contracts/token/ERC 721/ERC 721.sol”;
import “@openzeppelin/contracts/security/Pausable.sol”;
import “@openzeppelin/contracts/access/Ownable.sol”;
import “@openzeppelin/contracts/token/ERC 721/extensions/ERC 721 Burnable.sol”;
import “@openzeppelin/contracts/utils/Counters.sol”;
contract CLGFollows is ERC 721, Pausable, Ownable, ERC 721 Burnable {
using Counters for Counters.Counter;
Counters.Counter private _tokenIdCounter;
constructor() ERC 721(“CLGFollows”, “CLGF”) {}
function _baseURI() internal pure override returns (string memory) {
return “https://jonstokes.com/clgfollows/”;
}
function listURI() public {
return “https://jonstokes.com/clgfollows/list”;
}
function relationship() public {
return “clg follows”;
}
function pause() public onlyOwner {
_pause();
}
function unpause() public onlyOwner {
_unpause();
}
function safeMint(address to) public onlyOwner {
uint 256 tokenId = _tokenIdCounter.current();
_tokenIdCounter.increment();
_safeMint(to, tokenId);
}
function _beforeTokenTransfer(address from, address to, uint 256) pure override internal {
//Disable token transfers.
require(from == address( 0) || to == address( 0), “Cannot be transferred.”);
}
}
所有的擴充套件都與 OCG 相同，只是我沒有包括 ERC 721 Enumerable，因為不清楚是否有人想讓他們的 CLG Follows 代幣被列舉出來（另外它提高了鑄幣的 gas 成本）
至於函式方面，我對 OpenZeppelin 嚮導的輸出做了以下修改：
- relationship()： 與 OLG 一樣，它返回社交合約的型別。同樣，對於 Solidity 合約來說，這可能沒有必要，我也沒有見過這樣做，但儘管如此，我覺得我想讓合約自我報告它的型別。所以我不知道–如果這冒犯了你，請忽略。
- listURI() 返回一個指向 JSON 物件的連結，該物件是你正在關注（或靜音或遮蔽，取決於合約型別）的 ENS 名稱列表。我們希望這個 URI 能被標記為隱私，但這並不是必須的。
大多數情況下，你會使用 CLG Follows NTFT，把它釋出到社交平臺擁有的地址。這樣，該平臺可以讀取你的關注列表，並向你展示正確的帖子。
但你也可以把這些 NTFTs 發給追隨者，以便你的追隨者可以發現其他追隨者。你可以透過空投給追隨者，或者透過解禁造幣，讓任何人造幣來實現。
所有其他合約的工作方式與上述完全相同，但有不同的名稱和符號，並從 relationship() 和 listURI() 返回不同的值。
可能的變數
如果你擔心你的列表從不同的服務中洩漏，那麼把 listURI() 變成更像 tokenURI(uint 256 tokenId) 的東西是非常直接的，即簽名是 listURI(uint 256 tokenId)，它把 tokenID 連線到一個基本 URI 的末尾，這樣每個 token 持有者就可以得到自己的列表 URL。這個功能與列表主機上的一些邏輯相結合，可以讓你把列表隔離開來，使不同的令牌持有者得到主圖的不同子圖。這樣一來，如果一個平臺被擁有，那麼只有我的圖的那一部分被洩露了。
和 OCG 一樣，你可以把 safemint 變成一個可支付的函式，並向訪問你的列表的人收費。請看 OCG 部分的程式碼，以瞭解這個例子的情況。
你可能希望能夠更新 tokenURI() 和 / 或 listURI() 返回的 URLs，在這種情況下，你需要將這些 URLs 儲存在變數中，在建構函式中初始化它們，併為更新它們提供 onlyOwner setter 函式。這將增加你的鑄幣成本，但如果你只打算把它們給服務而不是個人，這可能並不重要。
服務
這裡概述的兩個建議都提供了一些集中式託管服務的地方，即使它只是一個權宜之計，在生態系統過渡到像 IPFS 這樣的分散式系統之前。
最明顯的服務型別是託管由 URI 功能之一返回的任何東西–配置文件資料、NTFT 後設資料和代幣控制的 JSON 列表（在 CLG 的情況下）。
另一個有用的服務是一種專門的 Infura 版本，透過 API 暴露鏈上的社交資料。或者，Infura 可以為社交資料提供一個專門的 API。
最後，可以有第三方服務來驗證賬戶，以滿足使用者和組織的需求。
總結
我不知道我是否期望我的鏈上社交圖譜建議會以我在這裡描述的形式被採納。我提出這些想法，更多的是為了引發對話，討論我們如何從目前完全鎖定平臺的狀態有效地過渡到更便攜的狀態，即你擁有你的圖譜，並可以輕鬆地將它隨身攜帶。
上述內容有一部分看起來有點像 web5 的提議，但關鍵的區別在於，我的兩個想法被設計得更簡單，並利用了智慧合約和現有的鏈上身份提供者（ENS，但也包括其他鏈上的類似提供者）。
如果你從這篇文章中沒有其他收穫，我希望我至少已經說明，在一個分散式賬本技術和智慧合約的世界裡，我們任何人都沒有必要在 2022 年被鎖定在一個社交網路裡。解決這個鎖定問題的工具是廣泛存在的，我們只需要拿起它們並使用它們。
