DIM协议中的meta及其数据交换过程

即时通讯（IM）有两种架构：client-server和serverless。像Tox、Richochet就被分类为serverless IM。但通常IM系统的运作都是需要服务端的。服务端工作任务的其中一个环节是认证客户端（Authentication）。简单讲，客户端只要拿着正确的用户名和密码，就能进入服务端，和其他用户通讯。这个认证服务的背后是成熟的directory server技术。但在这个环节，DIM协议就与众不同。

DIM协议下的IM，也是行走在client-server架构下。但服务端的存在，只是因为它长期在线，便利于桥接客户端，顺便再帮忙存放一下未被取走的消息。那么，桥接客户端又需要做些什么呢？它要求服务端尽可能的保存网络内各个终端地址所对应的meta，并在客户端需要时，随时提供。meta的核心内容就是终端地址的公钥；客户端需要消息接收方的公钥，才能够加密消息并发送成功；而消息接收方需要meta，来对消息进行鉴真。

下面我们过一遍meta在DIM网络的传播（propagate）过程。

首先，客户端在本地用私钥生成公钥，用公钥生成地址，公钥被打包进meta里面。meta需要上传至SP的服务端，传统意义上的“用户注册”过程才算完成。换句话说，如果这个meta没有成功上传到服务端，那么，即使其他人获得你的地址，也无法通过这个SP的服务端与你通讯。这是尝试DIM协议失败的第一个常见错误。

在社交场景下，服务端还会为客户端保存两种数据：用户profile（昵称、头像等）和通讯录。通讯录数据是加密的，只有私钥才能解密读取。而profile是公开的，但是有数字签名，需要用户meta来鉴真。举个例子，某人加你为好友，你要看看这个人是不是你认识的，于是你的客户端读取他/她的profile。在显示profile之前，你必须先获得他/她的meta。此时，无论你是否添加他/她为好友，你的客户端都要获取这个人的meta。没有在鉴真profile之前获得meta，是尝试DIM协议失败的第二个常见错误。

当你拿到新联系人的地址，准备给他/她/它发送消息之前，你的客户端需要凭此地址到服务端获取对应的meta。服务端对此操作不会设限。但客户端应该负责自行保管这些联系人的meta，以提高消息发送的效率。当你收到任何人的消息时，你的客户端也需要有发送方的meta。如果本地没有，就要向服务端请求获取。

当本地的联系人meta不完整时，譬如客户端重装之后，就需要从服务端重新获取meta。这个操作可能涉及多个文件的网络传输，是客户端容易出错的第三个地方。

总而言之，通讯双方需要交换meta才能成功收发消息，社交场景下的很多环节也需要用到meta。在DIM协议下，meta的交换并不仅限于依靠服务端，但client-server架构依然是目前最高效的解决方案。meta在服务端的存储和分发的机制，从某种意义上来说，就是传统directory server的替代，是DIM的核心之一。