项目

一般

简介

 

为什么我们不建议普通用户的撤回消息功能?

导出 PDF

为什么我们不建议普通用户的撤回消息功能?

消息的不可抵赖性

  1. 如意通RTP的应用场景,大部分是政府和企业以及严肃的电子商务或服务平台。

  2. 不论是从政企内部管理的角度来说,还是从运营平台服务方和用户之间的诚信角度来说,消息应该具有 可追溯性不可抵赖性

  3. 事实上,我们主要的目标是保障消息的完整性和可靠性,而不是相反。

  4. 如果客户想要实现阅后即焚的功能,则是另一种玩法,那么我们可以另行设计一个方案来满足

服务器的互通

如意通通RTP是基于XMPP协议的,它的一个基本特性是可以跨服务器互通,这主要发生以下场合

  • 集团企业多点部署的服务器互通
  • 供应链上下游企业服务器之间互通
  • 电子商务平台或社会服务平台和企业之间互通
  • 如意通服务中心平台和各种支持XMPP的服务器以及如意通RTP服务器之间互通

基于此,消息的双方或多方可能存在于两个或多个服务器上。要撤回消息,那么所有相关的服务器都必须同意该条消息可以撤销,而且涉及的服务器还都得支持撤回消息这个功能。而这几乎是不可能的。

举例来说:假定有一个RTP服务器S4,上面挂接了一个群服务器G4,G4里面有一个群里有三个用户C1,C2,C3,他们分别是S1,S2,S3三个服务器上的用户,S1和S2是RTP服务器,S3是XMPP兼容服务器(例如gtalk服务器)。从下图我们可以看出,C1提出的撤销群消息请求,首先依赖于S4和G4服务器的安全策略(是否允许外部服务器来的指令删除已到达本服务器的消息,以及是否允许用户使用XMPP兼容客户端),对C2取决于S2服务器的安全策略(是否允许外部服务器来的指令删除已到达本服务器的消息),对C3则根本不生效

跨服务器撤销群消息流程

sequenceDiagram participant 用户C1 participant RTP服务器S1 participant RTP服务器S4 participant 群服务器G4 participant RTP服务器S2 participant XMPP兼容服务器S3 participant 用户C2 participant 用户C3 用户C1->> RTP服务器S1: 请求撤销一条群消息 Note over RTP服务器S1: 开启了撤销功能 RTP服务器S1->> RTP服务器S4: 转发撤销群消息请求 Note over RTP服务器S4: 允许从外部撤销本服务器消息 RTP服务器S4->> 群服务器G4: 转发撤销群消息请求 Note over 群服务器G4: 支持撤销功能 群服务器G4-->> 群服务器G4: 删除一条群消息 群服务器G4->> RTP服务器S4: 广播通知群成员删除一条群消息 RTP服务器S4->> RTP服务器S1: 通知该服务器上的群成员删除一条群消息 RTP服务器S1->> 用户C1: 通知群成员删除一条群消息 用户C1-->> 用户C1: 在本地记录中删除一条群消息 RTP服务器S4->> RTP服务器S2: 通知该服务器上的群成员删除一条群消息 Note over RTP服务器S2: 允许从外部撤销本服务器消息 RTP服务器S2->> 用户C2: 通知群成员删除一条群消息 Note over 用户C2: 使用RTP客户端 用户C2-->> 用户C2: 在本地记录中删除一条群消息 RTP服务器S4->> XMPP兼容服务器S3: 通知该服务器上的群成员删除一条群消息 Note over XMPP兼容服务器S3: 不支持撤销消息 XMPP兼容服务器S3-->> 用户C3: 不会通知群成员删除一条群消息 用户C3-->> 用户C3: 本地记录中不会删除任何群消息

当前建议的替代方案

只允许管理员在后台撤回消息

考虑到实际应用中,确实存在某些紧急特殊的情况,我们考虑了一种替代方案,就是有限制地授权超级管理员在后台删除特定消息,它的限制有以下几点

  1. 删除消息的动作由管理员在后台完成
  2. 删除消息只对本服务器生效,即消息涉及的相关用户和组件服务都在本RTP服务器中
  3. 如果撤销消息的时候,某个对方客户端已收到消息并离线了,该客户端如果允许在离线方式下读取消息记录,那么在它下次上线之前仍然能看到已被撤销的消息

有限度地开启撤回消息功能(仍然是一个坏的选择)

好吧,尊重规则能让你走得更远,但是遵循人性能让你活下来先,如果客户确定需要让普通用户可以撤回消息,我们也可以想办法满足。但是为了避免造成隐患,还是需要在设计上做以下的约束:

  1. 只允许一对一消息和群/讨论组的消息撤回,即不支持撤回紧急通知(管理员从控制台发出的),新闻消息,服务中心消息,集成的其他业务系统发出的通知等
  2. 只允许交互界面使用消息撤回,即不可通过服务器的SDK/API撤回消息
  3. 限制在尽量短的时间内才可撤回,即1分钟内可撤回消息
  4. 普通用户撤回一对一消息的功能,要在RTP服务器上做一个开关配置,并警告跨服务器时此功能不生效(实际上如果用户使用兼容XMPP客户端此功能也会失效)
  5. 群/讨论组消息撤回的功能,应该在群服务器处增加开关配置,并警告跨服务器时此功能不生效

这个功能真是个污点,我来讲一个别的宇宙的故事哈,注意是平行宇宙,请勿对号入座,呵呵。

在那个宇宙,也有中国象棋比赛,规则本来也是落子无悔。某天中国象棋协会棋协为了献媚观众,提出了一个可以悔棋的规则,这显然是个不合逻辑的选择。但是因为全世界只有中国人下象棋,而中国所有的象棋比赛都归中国象棋协会管,所以这个规则竟然就这么的存在了,嗯嗯,存在即合理。

同样的,在那个宇宙,也有国际象棋比赛,规则本来也是落子无悔。因为中国象棋有一个落子可悔的规则,所以中国的国际象棋玩家很自然地认为国际象棋也应该遵循此规则。那么问题来了,如果是和歪果仁比赛怎么办?情况一,有的国家因为和咱们关系好,所以也执行同样的落子有悔规则,情况二,有的国家认同落子有悔,但是对于能悔几步以及几分钟内能悔棋和中国规则不一样,情况三,有的国家根本不接受落子有悔规则,情况四,有的国家去年允许悔棋,今年又不允许了或允许悔棋的步数或时间改了。

幸运的是,全世界的人都会下国际象棋,所以举办国际象棋比赛的权力并没有被郭嘉垄断。不幸的是,操办国际象棋比赛的这些公司,被中国象棋规则带到沟里去了,沟里去了,沟里去了。。。。。。