這是用戶在 2024-10-10 4:02 為 https://whtwnd.com/boobam.bsky.social/entries/Bluesky%E3%81%8CActivityPub%E3%82%92%E6%8E%A1%E7%94%A8... 保存的雙語快照頁面,由 沉浸式翻譯 提供雙語支持。了解如何保存?


Bluesky 沒有採用 ActivityPub 的三個理由

@boobam.bsky.social


問:Bluesky 為什麼沒有採用 ActivityPub?


答:簡單來說,時代不允許這麼做。


Twitter 的劣化與分散型 SNS


在伊隆·馬斯克(Elon Musk)收購 Twitter(現稱 X)後,排除第三方應用程式和出現大量僵屍帳號等各種改變被實施。這種大型平台的品質下降被稱為「劣化」。


劣化是指原本有益的服務隨著時間的推移,優先追求利益,變得對用戶不便且難以使用的現象。用戶因為在該平台上建立的關係網(社交圖譜)被挾持,即使平台變差也無法轉移到其他平台。


平台就是這樣走向滅亡的。首先,成為對用戶有益的存在。接著,為了成為對商業客戶有益的存在,開始壓榨用戶。最後,壓榨商業客戶,將所有價值轉向自己。如此一來,平台就會走向死亡。


科里·多克托羅(Cory Doctorow),〈Tiktok 的惡化〉


近年來,隨著 Twitter 劣化的加劇,「分散型 SNS」作為替代方案受到關注。分散型 SNS 是指由多個運營者非中央集權化、分散化運營的社交媒體。這些 SNS 使用共同的協議。


最著名的共同協議是「ActivityPub」。實現 ActivityPub 的 SNS 包括「Mastodon」、「Misskey」、「Threads」等。

フェディバースのイメージ図
圖像:聯邦宇宙(Fediverse)的概念圖


這些 SNS 互相連接的空間被稱為「聯邦宇宙 5」,不同 SNS 的用戶之間可以互動。例如,mstdn.jp 的用戶可以關注 misskey.io 的用戶,或發送回覆。因此,用戶可以從聯邦宇宙中選擇符合自己喜好的運營並加入。


Bluesky 與 AT Protocol


最近「Bluesky」這個 SNS 成為話題。

Blueskyロゴ


Bluesky 是一個類似 Twitter 的微型博客型 SNS。


到 2024 年 9 月,註冊用戶數突破 1000 萬,10 月的月活躍用戶數達到聯邦宇宙整體的 4 倍。日本用戶也很多,今年 8 月的國別統計顯示,日本的用戶數最多。


這個 SNS 最初作為 Twitter 的內部項目開始。最初的目的是開發 Twitter 未來使用的分散型 SNS 協議。然而,由於 2022 年後期與 Twitter 公司的合約解除,Bluesky 開始作為獨立的 SNS 走上新的道路。


雖然 Bluesky 是分散型 SNS,但其採用的協議不是「ActivityPub」,而是「AT Protocol」。因此,與聯邦宇宙不兼容,無法與 Mastodon 或 Misskey 直接聯合。


為什麼 Bluesky 沒有採用 ActivityPub?


為什麼 Bluesky 需要犧牲與聯邦宇宙(Fediverse)的兼容性來創建一個新的協議?


首先讓我們確認官方的說明。


為什麼不使用 ActivityPub?


帳戶可攜性是我們選擇構建另一個協議的主要原因。我們認為可攜性非常重要,因為它可以保護用戶免受突然的禁令、伺服器關閉和政策不一致的影響。可攜性的解決方案需要簽名數據庫和去中心化識別(DID),但這兩者都無法輕易地後期整合到 ActivityPub 中。ActivityPub 的遷移工具相對有限,原伺服器需要提供重定向,且無法遷移用戶的先前數據。


另一個重要原因是可擴展性。ActivityPub 在小型到中型節點的廣泛網絡間傳遞消息時,會導致個別節點流量激增,難以提供活動的全球視圖。AT 協議使用聚合應用程式來合併用戶主機的活動,減少整體流量,從而大幅減輕個別主機的負擔。

https://atproto.com/ja/guides/faq


・・
・・・?


雖然這些內容有些複雜,但總結起來有以下幾個原因。


  • ActivityPub 沒有「全球視圖」

  • ActivityPub 沒有「帳戶可攜性」

  • ActivityPub 沒有「可擴展性」


但是,為什麼這些會成為問題呢?


這三個要素的缺失,會在聯邦宇宙(Fediverse)中產生哪些挑戰呢?


本文將深入探討當前聯邦宇宙中發生的問題,並考察 Bluesky 未採用 ActivityPub 的背景。


ActivityPub / 聯邦宇宙概述

ActivityPub


ActivityPub 是由 W3C 標準化的去中心化社交網絡協議。Mastodon 和 Misskey 等平台使用此協議在伺服器之間進行互動。


ActivityPub 的聯合機制類似於電子郵件的運作。每個行為者(用戶)都有一個「收件箱」,用來接收來自世界各地的訊息。用戶將訊息發送到對方的收件箱,從而實現不同伺服器(實例)之間的聯合。


具體來說,讓我們來看看用戶 A 新發佈貼文時的流程。

ActivityPubの投稿の流れ


使用者 A 被屬於其他伺服器的 B、C、D 所關注。當 A 發佈貼文時,該貼文會被發送(POST)到 B、C、D 的收件匣(Inbox)。B、C、D 可以檢查(GET)他們的收件匣來查看 A 的貼文。


如此一來,在 ActivityPub 中,發起動作的使用者會將活動配送到對方的收件匣。這就像是指定大量密件副本(BCC)的電子郵件一樣。


此外,由於有「共享收件匣」(Shared Inbox)這個機制,即使被屬於同一伺服器的多個使用者關注,配送到該伺服器的次數也只需一次。


到目前為止,我們已經解釋了 ActivityPub 的概述,但僅僅理解這個規範並不足以與聯邦宇宙(Fediverse)進行聯繫。這是因為 W3C 所制定的 ActivityPub 規範僅涵蓋基本部分,詳細內容則依賴於 Mastodon 等現有的實作。


因此,目前的聯邦宇宙中並不存在所有人都遵循的單一標準規範,存在著各種獨特的操作和擴展功能。


在分散式社交網絡中,一旦發佈的內容無法刪除?


在 Mastodon 中,當使用者 A 發佈貼文時,該貼文的副本會被保存到接收貼文的 B、C、D 所屬的伺服器中。這是因為使用者在顯示首頁時間軸(HTL)時需要這些貼文。


因此,聯邦的伺服器會重複持有相同的貼文。例如,如果使用者 A 被 1000 個伺服器關注,A 的貼文會被複製並保存到這 1000 個伺服器中。當貼文被其他伺服器轉發(Boost)時,該伺服器也會保存一份副本。


當刪除投稿時,會發送「Delete」活動,並請求各伺服器刪除。然而,如果這個刪除請求被忽略,該伺服器上仍會保留該投稿。


因此,有時會說「在分散式 SNS 中,一旦發布的內容無法刪除」。


網域封鎖


網域封鎖是一種限制來自特定網域(伺服器)通信的功能。ActivityPub 本身並沒有關於此功能的具體規範,但許多支持 ActivityPub 的軟體都有實現這個功能。


如果無限制地接受內容,惡意伺服器可能會傳入垃圾郵件或非法內容。為了應對這個風險,會使用網域封鎖。

ドメインブロック
圖片:pawoo.net 和 misskey.io 被許多海外伺服器網域封鎖。


在 Mastodon 中,可以通過以下三種方法執行網域封鎖。


  • 拒絕媒體(Reject media)

    • 拒絕來自目標伺服器的媒體檔案。

  • 限制(Limit)

    • 隱藏目標伺服器的所有使用者。使用者可以通過搜尋、提及和關注找到,但內容不會公開。

  • 暫停(Suspend)

    • 停止與目標伺服器的所有帳戶的連接。這就是所謂的封鎖(BAN)。


其他


本地時間軸


本地時間軸(LTL)並未在 ActivityPub 的規範中定義,也不是必須的功能。由於與聯邦宇宙(Fediverse)的高度相容性,許多伺服器都實現了這個功能,但也有一些伺服器沒有 LTL。例如,「Fedibird」就沒有 LTL。


帳戶可攜性


在 Mastodon 和 Misskey 上,可以從一個伺服器遷移到另一個伺服器。然而,這項功能僅限於特定的實作,僅能在部分支援的社交網絡服務(SNS)上使用。例如,無法在 Mastodon 和 Threads 之間遷移帳戶。


為了遷移帳戶,原伺服器管理員的協助是必不可少的。如果管理員對用戶的遷移不合作,或者原伺服器已停止運營,則無法進行遷移。


大型聯邦與小型聯邦


實作了 ActivityPub 的 SNS 之間的聯合被稱為「聯邦宇宙」(Fediverse)。


關於聯邦宇宙的定位分類,ActivityPub 的共同作者 Evan Prodromou 先生認為有「大聯邦」(Big Fedi)和「小聯邦」(Small Fedi)兩種定位。


大型聯邦


聯邦宇宙應該更大,真的非常大。地球上的每個人都應該在聯邦宇宙中擁有一個帳戶。這樣一來,互聯網和世界都會變得更好。


商業帳戶伺服器是受歡迎的。這種多樣性也包括商業服務。如果能提供特定用戶所需功能和權衡的適當組合,尤其是當用戶數量龐大時,應該設置這樣的伺服器。


帳戶伺服器可能會變得非常大。規模並不重要。無論是 100 萬、1,000 萬、1 億還是 10 億人都沒有問題。


Fediverse 需要次要服務。為了成長,需要人力資源搜尋、入職工具、全球搜尋、橋接等次要服務。


小型聯邦


Fediverse 必須是安全的。必須防止騷擾和隱私侵害。


不建議使用商業帳戶伺服器。大多數商業服務會造成危害。即使在 Fediverse 上,也會為了賺取更多的錢而造成危害。因此,應盡可能避免。


帳戶伺服器必須保持小規模。由於人類版主能處理的工作量有限,因此版主管理的帳戶伺服器規模也有限。

https://evanp.me/2023/12/26/big-fedi-small-fedi/


「Big Fedi」希望 Fediverse 成長為取代 Twitter 的主要社交網絡服務。


另一方面,「Small Fedi」重視 Fediverse 的小規模特性,並利用這一特性來避免在 Twitter 上常見的騷擾和問題,強調作為一個安全且安心的社區的角色。


Bluesky 曾考慮採用 ActivityPub。


Bluesky 並非從一開始就計劃開發自己的協議,也考慮過採用現有的協議。


例如,Bluesky 的代表 Jay Graber 氏在 2020 年提出了採用 ActivityPub 的提案。


然而,最終 Bluesky 選擇了開發自己的協議。為什麼 Bluesky 放棄了採用 ActivityPub 呢?


其原因與開頭提到的「全球視野」「帳戶可攜性」「可擴展性」這三個要素有關。


ActivityPub 在小規模聯邦(Small Fedi)中是一個非常優秀的協議。然而,當網絡規模擴大成為大規模聯邦(Big Fedi)時,會出現以下問題。


  1. 由於缺乏全球視野而導致的「孤立化」

  2. 由於缺乏帳戶可攜性而導致的「中央集權化」

  3. 由於缺乏可擴展性而導致的「瓶頸問題」


理由 1:由於缺乏全球視野而導致的「孤立化」


全球搜索性


為了讓聯邦宇宙(Fediverse)能夠作為類似 Twitter 的信息基礎設施運作,趨勢話題和跨伺服器的搜索功能等全球視圖是不可或缺的。然而,目前的聯邦宇宙沒有整體趨勢,且在不同伺服器之間的搜索也有限制。


在支持 ActivityPub 的軟體中,通常只有伺服器內存在副本的公開帖子可以被搜索。也就是說,除了通過關注或轉發(repost)傳送到自己所屬伺服器的帖子外,其他帖子是無法搜索的。


用戶搜索也很不方便。比如,想像一下有人想在聯邦宇宙上關注我的帳號(boobam)。我在 misskey.io 上有一個帳號,但由於沒有遠程關注者,從其他伺服器搜索「boobam」時不會顯示結果。

この検索条件では何も見つかりませんでした
圖片:擁有 2 個關注者的男人的結局


要關注我的帳號,需要以某種方式確定並查詢我的帳號名稱。


對爬蟲的文化抵制


讀到這裡,有些人可能會想:「為什麼不有人創建一個類似於『聯邦宇宙搜索』的服務,收集並搜索聯邦宇宙的所有帖子呢?」


然而,絕對不能創建這樣的服務。因為目前的聯邦宇宙(Fediverse)對於未經許可收集帖子(爬蟲行為)有著強烈的文化抵制。


特別是在海外的聯邦宇宙社群中,絕不認可默認收集所有帖子(選擇退出方式),而只允許選擇加入方式(僅收集希望者的帖子)。過去提供選擇退出方式的搜索服務的人們遭受了強烈的批評,並被迫終止服務。


Bridgy Fed 的爭議


有一個名為「Bridgy Fed」的項目將 Bluesky 和聯邦宇宙連接起來。這個服務橋接了 ActivityPub 和 AT Protocol 這兩種不同的協議,使雙方的社交網絡能夠互相連接。Bluesky 團隊對此舉表示歡迎並持積極態度。


當初,Bridgy Fed 計劃以默認連接所有 Bluesky 帳戶和聯邦宇宙帳戶的「選擇退出方式」進行,僅允許希望者個別解除連接。


然而,這一方針引起了厭惡選擇退出方式的海外聯邦宇宙社群的注意,Bridgy Fed 的相關問題頁面上充滿了辱罵。結果,該項目被改為選擇加入方式。


特意選擇加入並啟用連接的用戶數量很少,這樣一來,作為橋接服務的意義就變得微不足道了。於是,這個橋接 AT Protocol 和 ActivityPub 的宏大嘗試實際上變得毫無意義。


如果 Bluesky 採用了 ActivityPub 會怎樣?


考慮到這樣的聯邦宇宙文化背景,即使 Bluesky 採用了 ActivityPub,增加全球視圖這樣的擴展也會很困難。


關於此事,Bluesky 團隊的保羅·弗雷齊(Paul Frazee)表示如下。


「我們觀察到,ActivityPub 社群對於資訊集約的感受,不僅難以讓社群接受我們的前提,甚至嘗試這樣做可能會被視為對社群的敵對行為。」


問:如果在技術上是可行的,那麼這不會是個大問題吧?


全球搜索性低的問題,主要不是技術上的限制,而是文化問題。因此,有人樂觀地認為未來會有所改善。


然而,如果聯邦宇宙(Fediverse)是真正的「去中心化」,那麼改變一旦確立的文化應該是非常困難的。


讓我們考慮一下日本的電扶梯單側站立的例子。要改變這樣的文化,需要通過法規等「中心化」的干預。


另一方面,聯邦宇宙被認為是「去中心化」的網絡。由於不存在中心化的權力,強制性的改變應該是困難的。


理由二:由於缺乏帳戶可攜性導致的「中心化」


ActivityPub 自稱為「去中心化社交網路協議」。那麼,聯邦宇宙(Fediverse)在 Big Fedi 中是否能保持去中心化呢?

一極集中


聯邦宇宙已知的問題之一是「集中化」。


在聯邦宇宙中,由於各伺服器的獨立性很高,屬於不同伺服器的用戶無法獲得相同的體驗。地方時間線的存在以及前述的全球視圖缺乏也助長了這一點。


此外,大型伺服器能提供優秀的基礎設施和合規性,而小型伺服器的運營者有時會表現得像 BOFH(對用戶不寬容的討厭管理員),這常常成為問題。


由於這些原因,用戶集中在大型伺服器上。特別是,尋求影響力的網紅或官方帳號傾向於屬於大型伺服器。結果,用戶的分佈趨近於帕累托分佈。


實際上,2019 年的調查顯示,前 5%的伺服器集中了 90.6%的用戶。

中央集権化


一般來說,ActivityPub 的聯合以全網狀拓撲結構表示。

フェディバースのシンボル
圖片:廣泛用作聯邦宇宙象徵的圖示


然而,這僅限於聯邦宇宙(Fediverse)規模較小的情況。隨著聯邦宇宙的擴大,因為集中化,伺服器之間的權力關係會變得不平衡。

一極集中後


在這種情況下,人們主要會關注以下的用戶。


  • 屬於同一伺服器的志同道合的夥伴

  • 屬於大型伺服器的影響者或官方帳號


換句話說,對其他伺服器的關注主要集中在大型伺服器上,因此聯邦的實際情況會趨近於星型拓撲結構。

スター型トロポジー


這裡的問題在於,依賴關係是單向的。


大型伺服器和小型伺服器之間並不是對等的關係。即使大型伺服器無法看到小型伺服器的帖子,影響也不大,但如果小型伺服器無法查看大型伺服器的影響者或官方帳號,則會對用戶體驗產生重大影響。


反而,對於大型伺服器來說,與小型伺服器的聯合是一種額外的成本。如果被大量的小型伺服器關注,配送的負荷會增加,對帖子的審核成本也會上升。


與 Twitter API 的區別是什麼?


順便一提,這種單向的依賴關係,依賴方沒有直接利益的情況,您是否在哪裡見過?


沒錯,就是在 Twitter 對 API 加限制之前的情況。

Twitter APIとActivityPubは同じ


就像 Twitter 將第三方客戶端排除在外一樣,在 Big Fedi 中,大型伺服器可以通過域名封鎖來排除小型伺服器。


Mastodon 的域名封鎖提供了比媒體限制或暫停更溫和的手段。然而,如果沒有商業利益,是否使用這些手段取決於大型伺服器的「良知」。如果依賴大型伺服器的「良知」,那麼這與 Twitter 這樣的中央集權型社交網絡所提供的 API 本質上沒有區別。


垃圾郵件騷動


這種擔憂在 2024 年 2 月發生的聯邦宇宙垃圾郵件騷動中成為現實。


在這次事件中,攻擊者在被遺棄的 Misskey 和 Mastodon 伺服器上創建垃圾郵件帳戶,並從那裡發送大量提及。由於逐一確認伺服器並進行域名封鎖的方法無法應對,伺服器管理員們感到非常頭痛。


作為對策,部分伺服器已轉為白名單制。也就是說,允許大型伺服器聯合,但對於比自己規模小的伺服器則無條件進行域名封鎖。


這種不對稱性之所以出現,是因為在聯邦宇宙中存在「大型伺服器擁有'隱性'權力」的結構。


分散式的意義


當中央集權化進行時,分散式的意義會逐漸淡化。


因為小型伺服器害怕來自大型伺服器的域名封鎖,難以設立獨立的管理標準。如果只能進行與大型伺服器相差無幾的管理,那麼多個實例存在的意義又是什麼呢?


如果只是想形成各個社群的聚集,那麼中央集權型的社交網絡已經足夠。Discord 和 5ch 是中央集權型的平台,但在每個房間或板塊中形成了多樣的社群。


問:企業的官方帳號如果獨自建立伺服器,是否能防止中央集權化?


在 Twitter 上發布災害信息的「特務機關 NERV」,已在聯邦宇宙上設立了自家的伺服器來發布信息。如果企業能從自家的伺服器發布信息,這樣的趨勢擴大,是否能防止中央集權化呢?


然而,這個想法是不切實際的。因為,隸屬於大型伺服器可以將資訊傳遞給壓倒性多數的人。


假設,這個世界上的所有社交媒體都支持 ActivityPub 的配送。NERV 會關閉目前的 Twitter 帳戶,並切換到僅從自家伺服器發送資訊嗎?


結論是,無法做到。僅從自家伺服器發送資訊無法獲得足夠的曝光率,會輸給在大型伺服器上擁有帳戶的競爭對手。NERV 目前能夠從自家伺服器發送資訊,完全是因為在 Twitter 這樣的中央集權型社交媒體上獲得了足夠的關注。


對於網紅或企業的官方帳戶來說,能夠觸及更多人且運營成本較低的大型伺服器,幾乎沒有離開的好處。


問:如果是不同類型的社交媒體之間,是否不會中央集權化?


如果是具有不同功能的服務,如「微型博客」和「長文博客」,用戶同時使用兩者,依賴關係不易產生,可以避免中央集權化的情況。


然而,不同類型的社交媒體聯繫時,會出現新的問題。


例如,假設這個博客支持 ActivityPub。雖然可以直接發送博客文章,但在 Mastodon 的 UI 中,博客圖片無法適當顯示,佈局會崩壞。因此,發送內容應限於博客標題和 URL,讓用戶直接訪問博客是更合適的方法。

このブログがActivityPubに対応した際の配送内容イメージ
圖像:此部落格支援 ActivityPub 時的配送內容示意圖


如此一來,不同類型的社交媒體在聯合時,需要根據一方的 UI 進行內容分發。在聯邦宇宙(Fediverse)中,微部落格是核心,因此部落格方會妥協,專注於提供類似 RSS 的更新通知。


在這種情況下,微部落格方會佔據優勢,其他形式的社交媒體則處於從屬地位。結果是依賴關係變成單向,並且趨向中央集權化。


理由三:由於缺乏可擴展性而導致的「瓶頸顯現」


ActivityPub 以無法擴展而聞名。具體來說,系統的哪個部分會成為瓶頸呢?


在 Mastodon 中,為了將活動分發到其他伺服器,使用了名為「Sidekiq」的背景工作框架和名為「Redis」的內存資料庫。

Mastodonアーキテクチャ
圖片:https://softwaremill.com/the-architecture-of-mastodon/


ActivityPub 在分發這些活動的 PubSub 機制上存在可擴展性問題。當來自其他伺服器的遠程關注增加時,分發工作的負荷會加重,從而產生瓶頸。


例如,在 2022 年 Twitter 被收購時,有數萬名新用戶加入了聯邦宇宙(Fediverse),導致許多伺服器的 Sidekiq 隊列堵塞。


最近的消息顯示,支援 ActivityPub 的 CMS「Ghost」的官方博客報告稱,為了向 5000 名追隨者發送新聞信,需要 10 台伺服器。24


為什麼會發生這樣的問題呢?


因為有一個容易理解的比喻,所以直接引用。


比如,想像一下有 10,000 台伺服器和 50 萬名追隨者的用戶。每當這樣的用戶發佈帖子時,會創建 10,000 個 Sidekiq 任務。每次互動,還會再創建 10,000 個 Sidekiq 任務。如果帖子變得受歡迎,在短時間內獲得 1,000 個喜愛(相當於該用戶追隨者總數的 1/500),那麼就會產生 10,000,000 個 Sidekiq 任務。

https://softwaremill.com/the-architecture-of-mastodon/


需要注意的是,這種可擴展性低的問題並不是由於 Mastodon 的實現,而是 ActivityPub 這種「全對全通信」的協議本身所帶來的根本性問題。25


如果 Bluesky 採用了 ActivityPub 會怎麼樣?


2024 年 8 月底,巴西最高法院命令停止 X 的服務,導致大量用戶湧入 Bluesky。結果,用戶數在一週內增加了 200 萬人,峰值時的流量是平時的 20 倍。


由於流量急劇增加,部分第三方製作的訂閱源停止運作等問題出現了。26 然而,Bluesky 公司提供的基礎設施能夠承受這種負荷。


如果 Bluesky 採用 ActivityPub 並將所有用戶連接到聯邦宇宙(Fediverse),可能已經達到了擴展的極限。


Bluesky 的技術顧問 Why(ワイ)表示:「如果 260 萬用戶試圖加入 Mastodon,系統將完全無法運作。」


負面循環


順便一提,負荷增加的條件「擁有大量被多個伺服器遠端關注的熱門用戶的伺服器」這種構圖,是否在哪裡見過?

スター型トロポジー


沒錯,這正是第二個理由中提到的「集中化的大型伺服器」。


本次提到的三個理由密切相關,結果形成了負面循環。


  1. 由於缺乏全球視野,伺服器的孤立化加劇

  2. 因為不同伺服器之間無法提供相同的體驗,用戶會集中到大型伺服器上

  3. 大型伺服器為了擴展需要承擔巨大的成本。保存聯合帖子和進行審核也會帶來很大的負擔

  4. 為了削減成本,限制向其他伺服器的配送,進一步促進集中化


事實上,最近的 misskey.io 似乎正在考慮為了削減成本而限制聯合功能。


每月處理 49 億次請求,現在的金額已經很吃力,未來可能需要正式對聯合功能進行限制。


— 村上さん (@AureoleArk) 2024/10/2 21:13:26


由 Threads 引起的鎖定


既然提到了「限制向其他伺服器的配送」,那麼我們也稍微談談 Threads。


最近的 Threads 展現了一些不安的動向。


聯合功能的限制


Threads 預設情況下與聯邦宇宙(Fediverse)的連接是被禁用的。用戶若要與聯邦宇宙連接,必須自行更改設定並選擇加入。因此,截至撰寫本文時,大多數的 Threads 帳戶尚未連接到聯邦宇宙。


根據 2024 年 8 月底的數據,Fedibird 認識到的帳戶數量中,「mastodon.social」約有 136,000 個,「misskey.io」約有 85,200 個,而「Threads」僅有 4,374 個。


API 的限制


2024 年 6 月公開的 Threads API 基本上是僅供寫入使用。讀取類的 API 被有意限制,無法讓第三方客戶端創建。Meta 表示未來也沒有改變這一方針的計劃。


對非官方 API 的警告


過去曾有項目通過逆向工程 Threads 客戶端,使用非官方 API 創建第三方客戶端。然而,Meta 通過律師發出警告信,迫使這些項目停止。



如此一來,Meta 使得非自家服務的用戶無法獲得與 Threads 相同的用戶體驗。他們將用戶鎖定在 Threads 上,讓用戶無法離開。


他們從一開始就沒有運營非中央集權型社交網絡的意圖,只是想要借「分散型社交網絡」的名義來奪取 Twitter 的用戶罷了,不是嗎?


如果不這麼考慮,就無法解釋對應 ActivityPub 和排除第三方客戶端這兩個矛盾的行動。


因此,像 MisskeyHQ 這樣的中小企業因成本原因,像 Meta 這樣的大型科技公司則因為封閉策略,會限制聯合功能。


聯邦宇宙(Fediverse)到底出了什麼問題?


「可用性」和「去中心化」之間存在權衡關係。


在聯邦宇宙中,通過加入大型伺服器可以享受高可用性,但相對地也存在依賴特定伺服器的風險。


另一方面,參與個人或小型伺服器可以實現分散化,但由於缺乏全球視野或受到大型伺服器的不利對待,使用者體驗會受到影響。


結果,人們優先考慮可用性,集中於大型伺服器。本來應該設計一個機制,即使使用者為了最大化自身效用而行動,也能實現去中心化。


「理念」和「架構」不一致。


ActivityPub 有一個名為「共享收件箱」的機制。這樣,即使被某個伺服器上的多個用戶關注,配送到該伺服器也只需一次。


總而言之,ActivityPub 這個協議越是分散,性能就越低。從可擴展性的角度來看,更多的用戶集中在一個伺服器上會更有效率。


這與推崇分散的聯邦宇宙(Fediverse)的理念相矛盾。


分散已經成為目的。


分散化本來應該是手段,其目的應該是其他的。


如果「社群的形成」是目的,那麼解決這個問題的手段真的應該是分散嗎?像 Misskey 的頻道功能一樣,在一個服務內建立社群不就可以了嗎?


如果「創建不會變質的社交網絡」是目的,那麼解決這個問題的手段真的應該是分散嗎?即使一開始有選擇伺服器的自由,但之後被鎖定就沒有意義了。


一些聯邦宇宙(Fediverse)的支持者似乎過於重視反中央集權,以至於將分散本身作為目的。


前篇的總結


在當前的聯邦宇宙(Fediverse)中,隨著規模的擴大,會出現以下問題。


  • 由於缺乏全球視野而導致的「孤島化」

  • 由於缺乏帳戶可攜性而導致的「中央集權化」

  • 由於缺乏可擴展性而導致的「瓶頸顯現」


因此,Bluesky 所目標的大聯邦宇宙(Big Fedi)無法實現。即使「Threads」有可能成為事實上的中央集權型社交網絡服務(SNS)來取代 Twitter,但「ActivityPub 聯盟」要取代 Twitter 則是困難的。


ActivityPub 這個協議本身,在小規模的聯邦宇宙(Small Fedi)中使用並不是壞事。問題僅在於它不適合在大規模環境中使用。


這與 ActivityPub 的設計背景有關。回顧聯邦宇宙的歷史,可以追溯到其前身 OStatus 以及 2009 年出現的 StatusNet。


當時的社群媒體並未預見到如今由大型科技公司主導的局面,認為只要有共同的通信協定,所有的社群媒體都可以整合。


某種意義上,社群媒體的發展已經超出了當時的預期,變得非常龐大。


正是因為這樣,Bluesky 無法採用 ActivityPub 的原因可以用一句話來概括:「時代不允許」。


後續內容待續……



在後續內容中,我們將比較 AT Protocol 和 ActivityPub 的架構


  • 背後的理念差異是什麼

  • AT Protocol 如何解決「全球視野」「帳號可攜性」「可擴展性」的問題

  • AT Protocol 如何在不使用「分散」的情況下獲得去中心化的特性


進行相關解說。

(以下追記)


宣傳第一


我們發布了一款 Chrome 擴充功能「ShareSwitch」,可以從 Twitter(現稱 X)的分享按鈕發佈到 Bluesky!


發佈時撰寫的部落格

https://chromewebstore.google.com/detail/shareswitch-twitterのシェアボタ/llfcobjpmnnnccbofmkhlfdbefmceloi


除了 Bluesky,暫時也支援 mastodon.social 和 misskey.io。


宣傳第二


本週五(10/11)將舉辦「Bluesky Meetup in Tokyo Vol.3」。

https://428lab.connpass.com/event/331611/


作為特邀嘉賓,React 和 Redux 的共同作者 Dan 將進行演講。Dan 去年從 Meta 離職,目前是 Bluesky 團隊的一員。


雖然我很遺憾無法親自參加,但對 Bluesky / AT Protocol 感興趣的人,或是想聽 Dan 先生談論 React 幕後故事的人,不妨參加看看如何?

Footnotes


  1. https://pluralistic.net/2023/01/21/potemkin-ai/ 日文翻譯: https://p2ptk.org/monopoly/4366 ↩


  2. 本文中的「去中心化」和「分散」這些術語,參考了以太坊創始人 Vitalik Buterin 的文章《The Meaning of Decentralization》,並按照以下定義使用。


    • 去中心化(Decentralization)……指的是"政治去中心化"的意思,即從系統中有多少個人或組織控制這些電腦的角度來使用。

    • 分散(Distribution)……指的是"架構去中心化"的意思,即從系統由多少台物理電腦構成的角度來使用。



      請注意,我們不遵循 Paul Baran 先生在 1964 年論文中使用的定義。

  3. Threads 預設情況下在聯邦宇宙(Fediverse)中的分享功能是關閉的。用戶若要與聯邦宇宙連接,需自行更改設定並選擇加入。因此,截至本文撰寫時(2024/10/07),大多數 Threads 帳戶尚未連接到聯邦宇宙。 ↩ ↩2


  4. 截至本文撰寫時(2024/10/07),Threads 對 ActivityPub 的支持有以下限制。


    • 在聯邦宇宙中的分享功能預設為關閉。要連接到聯邦宇宙,需在設定→帳戶中將「聯邦宇宙中的分享(測試版)」打開。

    • 居住在歐洲地區的用戶無法在聯邦宇宙(Fediverse)中開啟分享功能。

    • 無法從 Threads 查看聯邦宇宙(Fediverse)的帖子。

    • 無法從 Threads 關注聯邦宇宙(Fediverse)的帳戶。

    • 無法從 Threads 回覆聯邦宇宙(Fediverse)的帳戶。

    • 無法從 Threads 搜尋聯邦宇宙(Fediverse)的用戶。

    • 從 Threads 到聯邦宇宙(Fediverse)的傳送始終會延遲 15 分鐘。因此,無法與聯邦宇宙外的用戶共享實時體驗,如同時直播。

  5. 「聯邦宇宙(Fediverse)」這個術語有以下三種不同的解釋。


    • 狹義的立場……聯邦宇宙(Fediverse)僅指使用 ActivityPub 協議的聯合型社交平台。在這種觀點下,使用非 ActivityPub 協議的平台不包括在聯邦宇宙內。

    • 廣義的立場……聯邦宇宙(Fediverse)是指通過共同的協議進行通信的所有聯邦型社交平台。在這種情況下,即使是使用非 ActivityPub 協議的平臺,只要具有社交功能,也包含在聯邦宇宙中。

    • 最廣義的立場……聯邦宇宙是指所有進行聯邦化的事物。在這種觀點下,XMPP 和電子郵件等也被視為聯邦宇宙的一部分。



      本文基於「狹義的立場」,將聯邦宇宙這一術語僅用於指代使用 ActivityPub 的聯邦型平台。
    2

  6. 截至撰寫時(2024/10/07),聯邦宇宙約有 120 萬月活躍用戶(MAU),Bluesky 約有 520 萬月活躍用戶。由於 fedidb 未計入 Misskey,因此估計需加上 20 萬用戶。 ↩


  7. https://bsky.app/profile/bnewbold.net/post/3kzcvdtdehr2t 截至 2024/10/07,巴西(葡萄牙語)壓倒性地位居第一。 ↩


  8. 使用名為 Bridgy Fed 的橋接服務,可以在 ActivityPub 和 AT Protocol 之間進行聯邦化。 ↩

  9. https://www.w3.org/TR/activitypub/


  10. ActivityPub 也有關於從客戶端到伺服器的協議(C2S)的規範,但由於幾乎未被使用,本文不會涉及。 ↩


  11. 也定義了可以查看該人發布的消息的「outbox」,但由於話題較為複雜,本文不會涉及。 ↩


  12. 為了改善這種情況,有 FEP(Fediverse Enhancement Proposals)和 SWF(Social Web Foundation)等舉措。 ↩


  13. 依我之見,這是系統聯繫多寡的問題,使用「分散型 SNS」這種表達是不恰當的。即使是像 Twitter 這樣的中央集權型 SNS,通過 API 聯繫,外部系統也有可能繼續保留已刪除的內容。 ↩

  14. https://gitlab.com/-/snippets/2535398


  15. Mastodon 系軟體有更嚴格的限制,即使是公開的帖子,如果帳戶不允許全文搜索,這些帖子也不會被納入搜索範圍。 ↩


  16. 嚴格來說,Bridgy Fed 原本是作為連接 Fediverse 和網站的服務存在的,後來才增加了對 Bluesky 的支持。 ↩

  17. https://bsky.app/profile/bnewbold.net/post/3kfbcderomr27

  18. https://github.com/snarfed/bridgy-fed/issues/835


  19. 儘管如此,我因「理由 2」而不認為 Fediverse 真正是非中央集權的。 ↩

  20. https://web.archive.org/web/20230713014738/https://anond.hatelabo.jp/20230713050627

  21. https://emilianodc.com/PAPERS/mastodonIMC19.pdf

  22. https://unnerv.jp/@UN_NERV

  23. https://nora.codes/post/scaling-mastodon-in-the-face-of-an-exodus/

  24. https://activitypub.ghost.org/beta-plans/


  25. https://gist.github.com/jdarcy/60107fe4e653819138396257df302eef 關於快取的討論,請閱讀評論中的反駁意見。 ↩


  26. 目前,官方已經發布了「Jetstream」,它通過去除不必要的 MST bits 等,節省了超過 99%的帶寬。內容創作者應該使用這個工具。 ↩

  27. https://fedibird.com/@noellabo/113044308165407144

  28. https://developers.facebook.com/docs/threads/

  29. https://www.threads.net/@0xjessel/post/C3_cKf5vs_0

  30. https://github.com/junhoyeo/threads-api

boobam.bsky.social
Bam

@boobam.bsky.social


軟體開發人員

- ShareSwitch https://chromewebstore.google.com/detail/shareswitch/llfcobjpmnnnccbofmkhlfdbefmceloi


在 Bluesky 發表反應


*要顯示為反應,請在帖子中包含文章連結或添加連結卡片


所有人的反應 (0)