本週四有幸受邀作爲發言人之一參加了W3C中國舉辦的「Web進化論・SOLID：技术、标准与生态」系列活動（鏈接二），向其他人介紹和交流了一下我們EWADA團隊在Solid上的一些經驗的展望。會上其他人的發言和問答也很有價值，涵蓋了關於Solid發展來源、現狀和未來的一些討論，我覺得其中一些內容值得記錄下來。之所以寫成博文，也是因爲在其圓桌環節有一些關於Solid現狀和未來的討論，但由於某些因素，我當時未能清晰地闡述自己的觀點，所以借此機會更系統地整理一下。

W3C中國方面說後續會把活動錄像放上去，有興趣的也可以看一下原始視頻。

會議主議程

這個活動針對的目標羣體並非只是熟悉Solid的人，也面向不太瞭解但感興趣的人。但看得出來會議方希望兼顧兩個方面，而且似乎從結果上看似乎做得還可以。

除了我之外，會議的發言人分別是Pierre-Antoine Champin（W3C；Université Lyon 1）和陳華鈞（浙江大學）老師，二人分別從Solid的來源和現狀，以及對其和LLM結合這兩個方面做了報告。

Pierre-Antonie報告的主題是《Solid技術及W3C的Solid標準化工作》。他首先用十分簡練的方式闡述了Solid要解決什麼問題（數據被困在各個中心化平臺上，需要反覆重新輸入，且用戶缺乏控制能力），以及Solid的解決方案（數據存在用戶擁有和控制的Solid Pod中，應用程序要去Pod申請訪問讀寫）。然後解釋這樣做帶來的好處——不僅是對用戶的，還包括對應用開發者的。在此之後他談到Solid作爲技術、系統和標準的現狀，各個組的情況，然後提到了下一步關於更進一步推進標準化的努力。他尤其着重談到了創建W3C Working Group的相關信息，即2023年9月提交了一次申請，但被否決，因爲申請沒有足夠地細化集中於這個Working Group的（具體可執行）目標，以及Solid和其他標準/工作組之間的關係。在這個過程中，他還簡單討論了一下Solid和其他的W3C中進行去中心化標準討論的組（或標準）的關係，比如ActivityPub和DID（Decentralized ID）。最後，他強調，Solid的主要貢獻和目標在於使用已有Web技術（即保持兼容性），但使用另一種方式組織組合它們，以便提供不同的結果。 後續提問中有人問到Solid和其他一些去中心化倉庫的關係，尤其是比如區塊鏈的Web3以及歐洲的Common Data Space。Pierre-Antonie回答道Solid和Web3有顯著不同，尤其是Web3基於區塊鏈而放棄已有的萬維網技術，相當於「把嬰兒和洗澡水一起倒掉」，有些過頭；而他覺得Solid和Common Data Space不是矛盾的關係，二者有很多地方相似，兩個社區需要更多交流（以便可以達成共通的共識）。這倒是讓我想起來去年三月在德國紐倫堡舉辦的Solid Symposium，其中有Gaia-X的人參與，也做了報告，希望可以和Solid社區加強交流。

陳華鈞老師報告的主題是《AI大模型与Solid的可能结合》。他從Solid以及語義網的連接展開，回顧了他們以前在語義網和知識方面的工作。然後他展望了Solid數據（包括作爲知識圖譜和普通數據）在未來和AI大模型的幾種結合方式，包括以RAG方式使用公開的大模型（數據查詢），和用個人私有數據訓練小模型再和公開大模型結合；同時他也提到這些結合也分別伴隨各自需要解決的問題。雖然對於結合部分主要是展望，但由於從已有實踐入手，聯繫已有嘗試，給人比較紮實的信心。 由於我們團隊也在嘗試將Solid和LLM進行結合，前一段Tim（Berners-Lee）也寫了一篇相關的Design Draft（也是展望），所以我也借機向陳老師提問他關於結合的潛在問題的看法。

接下來是我的報告，題爲《探索Solid的社交與社會技術屬性》，主要介紹我們團隊的相關工作。我首先回顧了一下自己多年前瞭解諸多去中心化社交網絡系統時首次看到Solid，然後切入EWADA項目的信息，以及EWADA項目在Solid上的探索。EWADA在社交社會之外還對Solid有別的探索，我也簡單提到它們，尤其是DToU（Data Terms of Use），但在此之後我重新聚焦於三個和社交、社會有更直接聯繫的探索上，也就是Solidflix、KNoodle (+Orchestrator)以及Libertas。接下來我首先回顧了Solid名稱及提供的相關功能，強調Solid現有技術可以完成社交功能，所以需要討論的主要是「如何」「恰當地」使用它們。然後我列舉了一些其他人關於社交社會功能的探索，着重提到了兩個社會功能的項目（比利時Flanders大區政府所做的My Citizen Profile項目，和曼徹斯特NHS使用Solid存儲和管理醫療數據），並解釋EWADA項目相關探索的一个不同聚焦點：Ethical，在提供某個功能的同時，還可能給用戶（個人）什麼額外的（人文）特性。再之後我對三個項目分別進行了介紹，尤其分別介紹了它們各自的獨特着眼點：Solidflix側重推薦算法如何做到更加隱私/數據友好，比如探索去中心化的協同過濾算法（Collaborative Filterting）；KNoodle側重多人交互場景的同步和數據維護；Libertas關注對羣體數據的使用時如何做到數據祕密/隱私保護，同時兼顧各數據所有者的自主性。在過程中，我也解釋了在部分場景下由於現有Solid設計（主要是Pod不具有計算能力），所以需要引入額外組件來完成功能，但如果可以爲Pod提供計算能力，那麼也許這些問題可以有更好的解決方案。 最後我對前面這些項目探索的經驗進行了總結，包括探索中明確的Solid的功能和泛用性，以及我們在其中留意到的Solid上進行開發和傳統系統開發的不同之處。在此之後，我還簡單提出了一些Solid未來發展的可能展望，聚焦於對功能和協議進行擴展。

在發言後，有不少人跟進詢問了一些问题。其中包括Solid中國社區的發起人之一林東吳，問到我們在Solidflix上做的（關於協同過濾的）嘗試是否可以視爲將Solid Pod作爲CMS來使用，畢竟在執行第一步之後將數據當作binary存在Pod中。這個問題其實挺有意思的，因爲它讓我聯想到了Solid論壇中一篇關於如何看待Solid的貼子：Why Backend-for-Frontend for Solid is categorically wrong。我的看法是：在一些情況下， Solid中的數據的確只是作爲單獨的數據存在，被前端調用；但在另一些情況下，如果我們考慮互操作性以及Solid作爲「個人」數據和知識庫後，我們不應該把Solid只看作單獨的數據倉庫，而是要以整體的角度去看這個問題；目前的Solid協議沒能讓這點非常明確地顯現，但我們對KNoodle和Orchestrator的探索讓它暴露在目光中。於是，我回答道的確第一步MinHash是將數據作爲binary存下來，因爲Hash值本身的確不具有語義；但由於去中心化的考量，這個數據需要每個用戶自己去維護（通過KNoodle自動進行），而不是通過某個中心系統完成，而且原始（觀影）數據和它是分離的；所以如果只看數據管理和使用，的確有相似之處，但維護部分則不太一樣。

在各自報告之後就是圓桌環節，由文因互聯創始人鮑傑博士主持，參加者增加了華爲標準部的李力博士。該環節中我們着重討論了兩個問題：以Solid爲代表的Web3.0和區塊鏈的Web3之間關係的討論，以及爲了Solid的哪些方面可以退讓/捨棄以換得更大推廣。

之前Pierre-Antonie簡單說了一下關於Web3.0和Web3的關係，在這裏進行了展開，尤其是重新強調了一下不應該「連着嬰兒一起把洗澡水倒掉」。然後林東吳加入討論，側重說區塊鏈的重點技術內容也可以在Solid上實現，比如使用Verifiable Credential之類的（所以如果只是想要特定的好處，未必一定要完全使用區塊鏈）。我則是由於以前在博客中寫過一篇《論Web3.0和Web3》，所以嘗試總結了一下最關鍵的兩點技術問題：1.區塊鏈Web3意味着不兼容（瀏覽器訪問的）Web，而如果要兼容就要設置橋接，但這意味着中心化，和區塊鏈的意義相悖；2.區塊鏈Web3沒法存儲私有數據，且沒辦法有意義地設置訪問權限（修改版客戶端可以輕易繞過），除非接受鏈下存儲，但這又和使用區塊鏈的價值相悖。這兩點都導致使用區塊鏈的初衷受到質疑，而Solid則完全沒有這些問題。當然，就像林東吳說的那樣，我覺得區塊鏈的一些特性也完全可以加入Solid中（比如provenance或交叉簽名），不過需要明確的作用和意義。

關於Solid的發展和推廣，華爲的李力博士認爲需要意識到Solid的推廣一定會影響到現有大廠的業務，所以會受到它們的阻力，故而需要尋找方法突破這一約束。林東吳認爲RDF可以被一定程度犧牲，以換取更多人更容易上手開發。我也提到了RDF的困難點，以我們指導Intern爲例說明RDF的門檻；但我認爲問題的核心不出在RDF本身上，而是相關庫和開發者生態的問題——主要的庫的抽象層級都太低了，會影響新開發者學習使用；而高級的庫則不太容易被人注意到，需要更好的介紹文檔。

總之，這次活動讓我得以和中國的Solid相關人士進行交流，分享各自的看法。令人欣喜的是，我發現我們在多數話題上都能達成共識，交流過程中大家也都較爲透明和積極。我很希望未來有機會和他們繼續交流，也希望類似的活動可以繼續辦下去，提高Solid在中國的認識度，畢竟Solid要解決的是用戶日益被大平臺綁架及數據管理複雜（以至放棄）這一在中外都日益顯著的問題。

關於Solid發展推廣以及犧牲的看法

交流中關於Solid推廣是否需要一定犧牲（以及進行什麼犧牲）的話題很有意思，這是一個我在研究和開發中有一些認識，但沒有整理過的問題。由於種種（個人）原因，在活動中我沒能較好地闡述我的看法，所以在這裏整理一下以彌補一些遺憾。

首先，我覺得這個問題是一個很重要的問題，因爲Solid技術性上有很多優勢，而且有「Tim Berners-Lee提出」的光環，但推廣速度並不快，這必然意味着哪裏需要改進。改進的方面可以是推廣方式，可以是描述用語，也可以是技術取捨。我同意Solid設計中部分技術（主要是RDF相關技術）不太爲開發者和用戶熟悉，但我不覺得它們是根本性的問題。

的確，根據我們過去兩年指導Intern的經驗來看，RDF有學習成本，而且對RDF的足夠理解這件事是不少Intern一直沒能掌握的——他們大多能理解RDF是個「圖」結構（或至少不是平面結構，比如列表或表格），也能（使用現有庫乃至自行維護數據來）讀寫RDF文檔，但既不理解爲什麼要用RDF，也不理解Linked Data和RDF的關係。JSON-LD的存在方便了他們理解50%的內容，但50%到60%之間這一步則往往不好跨過去。具體來說，他們能夠用RDF存數據，但存下來的數據往往只是將一個JSON數據用RDF表示，而不足以稱爲Linked Data，因爲數據完全沒有考慮「關聯」/「鏈接」這個方面。

但在我看來，如果有適當的庫，這個學習成本可被攤開到長期開發中，而不是要求在一開始掌握，畢竟他們此時還需要同時去掌握Solid的去中心化理解以及Solid協議和庫——這兩者已經是很不一樣的新知識了。但現在的情況是，新開發者往往要麼去使用rdfjs，要麼使用Inrupt的Solid Client庫。之所以會去看rdfjs，是因爲（理所當然/想當然地）這是JS的RDF庫。然而事實上rdfjs系列的庫是極其低級/底層的，本身並不是給初學者準備的。而Inrupt的Solid Client雖然沒有rdfjs系列那麼低，但同樣也使用很低的抽象層級——雖然將Solid Pod中的數據以Resource Dataset的形式呈現來訪問（而不是直接暴露爲一個RDF圖/KB），但嘗試讀寫它的時候仍然需要RDF知識以理解該讀哪個數據，以及該選哪個函數/方法。

我自己早就學過RDF相關知識，所以在理念方面沒有障礙（甚至可以說這是一個加分項）。但我仍然花費了一段時間來習慣這些庫，因爲它們各自有各自使用中的細節問題/知識。而且，即使我已經較爲活躍且主動，但我也花費了較長時間纔瞭解到除了它們之外的其他庫及其定位：Comunica用來做SPARQL（或GraphQL）查詢，同時支持公有和私有數據；LDflex等庫提供更直覺化和簡便的RDF資源訪問（和修改）。而且，在調用這些庫的時候我也遇到了一些障礙——部分因爲我使用Vue+Vite，文檔完全沒有覆蓋類似場景，所以只能自己去摸索；部分是因爲我原本並非前端開發者，對遇到的各種報錯不能很好定位問題歸屬，時常陷入「是我配置錯了，還是庫的bug」的疑問中。即使到了現在，我也經常需要重新掌握相關庫，因爲它們的用法對我來說並不足夠直覺化。

所以整理一下：在我看來，新Solid開發者學習RDF的這部分障礙完全不應該存在，或者至少應該且可以遠比現在平緩；現在的相關問題與開發生態（尤其是庫）的不足緊密相連。Solid社區需要更好的，抽象程度更高的，更易掌握的對Solid數據讀寫的庫，以便讓新開發者更容易在不具備足夠RDF知識的情況下也能使用。而且該庫也應該留下給開發者的發展空間，讓他們在掌握了更多RDF知識後可以將其融入到自己對庫的使用中，或是通過學習庫的進階使用來掌握更多的RDF知識。當然，我明白RDF其實是很大的一個領域，所以這個庫不可能完全提供所有的RDF功能，仍然需要專門的RDF庫來讓開發者擁有完整的控制能力。但這並不意味着這樣一個庫沒必要存在。事實上，我覺得LDflex就是一個不錯的開頭，LDO（另見論壇貼子）也是一個有意義的嘗試（雖然它需要ShEx知識，掌握要求知識更多，但用法上方便很多）。

在直接解決RDF事宜的庫之外，我覺得也有必要開發或促成Solid開發中常用功能的庫。我理解Solid設計中允許不同傾向和用法的部分，但這不影響大家形成一個主體性用法，且有一個庫提供該用法的對應常用功能。例如Inrupt的Solid Client本身應該只是一個數據讀寫（和管理）的庫，但它同時也提供了類似getPodUrlAll()這樣的函數來方便地從WebID Profile中讀取信息。我覺得有必要將類似的功能擴展到「標準」以外的「常用做法」上，比如getName()用來從WebID Profile中讀取其名字（同時考慮如何處理多種謂詞），或比如getSettingLocation()來得到某個App的配置存放地址而不是要求App自己管理。我開發solid-helper庫其實就是在嘗試這個目的，比如它提供了findStorage()來獲取Pod地址，或（假如WebID Profile中沒有pim:storage則）嘗試發現Pod地址——這個需求我已經在多個App中碰到了。

額外話題——Pod擴展

上面這些是對我在活動中相關發言的重新整理。但在此之外，我覺得還有其他方面也值得討論，尤其是對Pod功能進行擴展。

在我們的探索中，我們發現Solid在部分場景下的開發不夠順暢，主要因素集中在Solid Pod不具有計算能力這點上。這帶來的一個重點問題就是：許多業務（比如兼容已有如ActivityPub、CalDAV的協議）需要服務方對協議數據進行一定計算或響應，甚至需要額外的endpoint來完成功能，但Solid Pod不能被這麼使用，所以只能通過引入額外組件去承擔這個功能，類似KNoodle的Orchestrator或Libertas的Agent。然而這些組件是單獨託管的，而非運行在Solid Pod服務上或集成在裏邊的，於是1.它們需要使用單獨的URL，導致用戶側配置複雜；2.需要在Pod中設置對應的權限。二者共同導致用起來比較麻煩。

在部分情況下，如果我們稍微深入思考會發現，這種擴展並非是爲了完成（用戶側）功能，而是完成兼容。比如ActivityPub也許需要服務器設置一個Inbox來處理流入信息，但其實它可以被拆分成兩步：1.流入信息存在Pod的Inbox中；2.用戶使用App時讀取Inbox並妥善處理數據。這兩步都可以用Solid已有機制完成，而且理論上說也不會需要用戶進行額外配置或有所感知。但現有服務的協議往往都不是這麼設計的，有的還需要額外通信交流，所以如果要提供兼容就必須考慮如何解決。

更理想的狀況是Pod允許動態添加一些額外的endpoint以及自定義計算/鉤子——它們可能可以是在Pod服務器上額外運行的功能，也可能可以是外包/代理出去的計算，取決於最終設計。但核心在於，Pod服務需要能被用戶擴展，以便處理額外的功能。而用戶配置則可以使用某種通用配置結構，放在特定位置或允許配置其位置。

這點還可以進一步和協議/服務發現結合起來。前面沒有提到，但我做完報告後有人問我們系統中是否使用了某種協議發現或聲明機制，我回答說沒有，暫時要麼是硬編碼的要麼是使用自己的配置格式，但我們很期待未來可以有相關通用機制。

更進一步，如果計算需求很大，那麼設計中不應該要求Pod服務提供計算能力。例如，如果要將Solid和LLM進行結合，則必須有某種方式以向量形式存儲和查詢Solid Pod中的信息。顯然，這需要不小的計算量。再者，LLM推理本身也需要強大的計算能力，瀏覽器很難提供，所以很可能需要其他的解決方案。直接使用某個上游提供商（比如OpenAI）不是不行，但這很容易和個人數據的隱私需求相悖，所以只能是後備方案而非優先選擇的方案。但假如我們要求一切功能都由Pod服務全部提供，這又會給Pod提供方過大的計算壓力，導致Pod服務減少，形成中心化趨勢。

所以更好的方案是可以靈活提供計算能力：首先，計算能力需要作爲可選而非強制存在；其次，Pod要能夠通過某種方法告知App或請求方去哪裏（哪個服務器）獲得該計算能力。這樣，如果Pod服務器提供計算，那麼該目標地址只要指向Pod即可，而如果Pod不能提供計算，那麼要麼返回空，要麼返回一個用戶配置的服務地址。

除了聲明endpoint以外，該機制也有機會被擴展到支持虛擬資源上——某個資源並不直接存儲在Pod中，但可以在需要時計算出來。但這可能會涉及更多話題，包括但不限於配置的複雜度，權限管理，推理（是否使用Open World Assumption），性能和緩存，以及虛擬資源的相互依賴關係。而且這樣做同樣有中心化還有隱私風險，畢竟運行在用戶瀏覽器中的App相對難以做手腳，且自然而然地去中心化，但運行在某個服務器上的服務就是另一回事了。

總之，我覺得這是另一個值得討論的相關話題，畢竟它也涉及Solid是否需要爲了推廣而進行適當犧牲。我在這裏嘗試討論出儘量完善的方案，但似乎並不能完美完成所有預期。還是希望其他人可以加入討論，並形成共識，最終推動Solid發展和推廣。