在去中心化社交协议下，由于交互界面提供者无权访问内容，因此它们无法自行执行业务逻辑。这必须在用户端通过所谓的「 用户客户端 」来完成。

用户客户端只是一个应用或浏览器插件，可以执行业务逻辑并管理用户的个人资料和钱包。然后，接口提供商的功能只是将业务逻辑发送给用户客户端，指示其收集内容并进行编纂，以通过用户界面进行显示。

图 4

图 4 演示了如何操作过程。用户再次通过用户界面发出请求，该请求被传递到界面提供商的业务逻辑服务器 （步骤 1 和 2） 。然后，界面提供商将适当的业务逻辑发送回用户处的用户客户端 （第 3 步） 。用户客户端执行业务逻辑——根据需要从内容服务器收集内容——将输出发送到用户界面以显示给用户 （步骤 4 至 7） 。在用户客户端和用户界面之间执行的步骤 6 是在用户设备上本地运行的。单个应用或带有 去中心化社交协议 插件的浏览器可以同时处理用户客户端和界面，因此从用户角度来看，用户客户端可能「处于幕后」。

为简单起见，在图 3 和图 4 中未显示广告商。如果上述操作确实运行良好，图 3 中已连接到业务逻辑服务器，图 4 中连接到用户客户端。

更复杂的关系也可能成立。例如，用户客户端可以根据用户设置、钱包余额或任何其他本地存储的信息，在初始请求发送到接口提供商之前对其进行修改。所有这些都未在图中演示，因此图中只是看到了社交网络的基本重组。

什么是社交网络？

到目前为止，我们一直在相对高的层级讨论设计原理。本文的其余部分将讨论 去中心化社交协议在实践中如何运行 的想法。大家请将它们视为这一问题讨论的起点，而不是最终的答案。

从本质上讲，去中心化社交协议到底是什么？我们看一下主要的社交媒体平台，我们会看到 Twitter 主打简短的公开言论，Facebook 强调与朋友分享，Reddit 侧重于小众社区，Instagram 侧重于图片，YouTube 侧重于视频，等等。我们 不需要为它们一一复制一个去中心化版本，因为它们的本质是相同的 ，区别仅仅在于与他人交流和共享内容的方式不同。仅此而已。

从这种层次的抽象着手设计去中心化社交协议，既可以简化它，又可以最大程度地扩展其覆盖范围。

上面列出的所有社交媒体平台，其中很多现在已经存在、有些尚待想象，都应该能够在去中心化社交协议 上运行。这些平台 （和任何通信平台） 区别的维度如下：

内容类型

视频、图片、音频、文本或任何其他内容类型之间本质上没有什么不同。它们都可以被降解为数字 1 和 0，并且需要以相同的基本方式进行处理。存储、访问、语境和各种元数据，无论内容类型如何， 去中心化社交协议都应以相同的方式处理。Instagram、YouTube 和 SoundCloud 基本上是同一网站，只是它们主打的内容类型有所不同。 去中心化社交协议应该 抽象化 ，这样所有内容都可以支持，包括新的内容类型 （例如 VR、触觉） 。 (责任编辑：admin)