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的核心之一。

相关推荐

微信扫一扫,分享到朋友圈

DIM白皮书(中文版)