本周四有幸受邀作为发言人之一参加了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发展和推广。