现有的所有Messenger都有其优点和缺点，但由于与他人的不兼容，它们各自将其拉到了一边-用户因此而遭受痛苦。
XMPP可以成为一个单一的标准，但是它与电子邮件不同，它出现得相对较晚，并且没有获得足够的受众，因此公司无法拒绝它。 毕竟，他们很快意识到，在不将观众留在自己的生态系统中的情况下，他们赚不到多少钱。 此外，我必须承认，XMPP由于存在大量的扩展而具有足够的缺点，尽管其中许多扩展很重要，但仍处于试验状态，并且有些相互完全重复。
生活在智能手机中十几个即时通讯程序的“新奇世界”中，并且感受到了这种状况的所有缺点，我们终于为新事物做好了准备。
是的，我们需要一个新的标准！
出色的Future Messenger满足以下要求：通过开放式开发和分散化确保可靠性，安全性，可移植性（跨平台），多协议（连接到其他通信网络的能力）和用户友好性。
为什么一切都那么糟糕？
但是首先，让我们弄清楚为什么每个人都不会切换到任何已经流行的==集中式Messenger，无论是有条件的WhatsApp还是Telegram，在俄罗斯都有相当多的受众。
当然，集中式建设可以使所有者赚取更多的钱，从而不仅可以为开发付费，而且还可以在广告上投入大量资金，甚至可以美化几乎没有的功能 ，例如服务安全性。 但是，与此同时，所有者可能突然决定关闭服务，用拖拉机从数据中心移走电线，或者仅在特定国家/地区禁止使用Messenger。 可能不一定是出于政治原因，应有条件的版权所有者的要求，可能有很多原因。 尽管市场规模微不足道，但Telegram继续在俄罗斯开展业务并取得不同程度的成功，这很好，但这是由于所有者的个人帐户所致，并且如果阻止了相同的WhatsApp，Facebook不太可能投入大量资金来绕过锁。
所有集中的使者都很难立即讲话，一口气收集下来。 专有客户端，服务器和协议甚至完全只能在少数几个最流行的平台上运行，并且没有任何加密，这是绝对邪恶的。 也有相对的好处，例如，Signal Messenger是完全开放的，但是服务器不支持联合模式，这就是为什么每个人都依赖中央服务器来承担所有后续后果的原因。 这里，应该根据不同的原理进行分类，但这不在本文的讨论范围之内。
好吧，为什么不改用联邦政府的东西呢。 例如，相同的矩阵。 我不会谈论HTTP长轮询，较差的服务器弹性以及客户端界面的明显怪异之处，尽管不是微不足道的（尽管在全球范围内，这并没有改变），但所有这些都是可解决的任务。 我喜欢开发人员考虑XMPP的经验并开发通用规范而不是一堆独立的XEP，但这只是XMPP的缺点之一。 另一个问题是联邦网络的经典设备，当我们被迫选择某台服务器并信任它的所有者时，它将确保该服务器正在运行并且不会关闭它。 如果数据中心再次发生故障，我们将与世界隔绝，无法与另一台服务器上的先前帐户进行通信。 即使您创建了一个新帐户，并且以某种方式将联系人列表从旧服务器转移到该帐户，在进行通信时，您也必须以某种方式再次确认它是您的真实身份，而不是向您介绍您的人。
在这种情况下，也许完全放弃了服务器？ 有许多基于无服务器技术的即时通讯程序。 这里的一个特例是在狭窄的圈子中流行的Firechat，它使用wifi和蓝牙设备的网状网络与用户进行通信。 当所有用户都集中在该区域时，此Messenger确实可以很好地工作。 但这是一个相当特殊的情况，即使我们想象一个地球上每个居民都安装了应用程序的情况，这还会产生很多其他问题，从地理标志的网状网络中断以及与远方用户交换消息的速度到设备上必要的存储数据量，不一而足。 但是，很可能该信使已从总质量中剔除，在我们的比较中是多余的。 它比以用户为中心更具实验性。
还有诸如Tox之类的项目试图实现p2p Messenger。 这种方法使您不必担心服务器的安全性，并且几乎不可能阻止此类信使。 Tox有很多问题，但这是一个非常有趣的项目，它有自己的定位。 列出Tox的特定缺点是没有道理的，因为该项目正在开发中，尽管p2p服务的开发更加困难，但是如果您设置了这样的任务，则可以提出各种有趣的体系结构来构建这样的网络：具有其自身的优缺点，对Internet通道宽度的不同要求以及设备上的空间量，包括超级节点，同时从不同设备登录甚至离线消息传递。 但是，与客户端-服务器体系结构相比，常见的情况通常是大量的流量冗余，并且由于需要不断保持大量的连接和进行各种计算，因此移动设备上的电池消耗增加。
因此，尽管p2p是一项有趣的技术，但如果将坐标发送给救援人员，位于针叶林中的一棵树上，几乎没有互联网连接和1％的电池电量的情况下，它将证明无效。
如何解决？
因此，我想介绍一种混合客户端-服务器体系结构，该体系结构可以充分利用现有方法并避免其缺点。
因此，为了使具有最少必需资源的Messenger能够在移动设备上工作，我们将使用客户端-服务器模型，其中最大的计算操作和流量需求资源集中在服务器上，并且在客户端将数据解密并显示给用户。
编址
每个用户以电子邮件或XMPP的格式接收其地址，即昵称@域。 但是，与上述服务不同，在该体系结构中指定域并不具有相同的重要地址角色。
域更可能用作昵称注册商，以排除所有现有昵称可能被有意或无意占用的可能性。
域名是在Internet上花钱的，这不排除大规模注册的可能性，但会大大缩小其范围。 在集中式服务中，访问通常是通过移动电话的链接进行的，这也不是唯一的因素，但是SIM卡也不是从空中获取的！ 顺便说一下，在这方面，我想知道他们将如何在https://toxme.io/中与之抗争-Tox的一项服务，允许您将长键与短昵称相关联。 我认为没有理由不让他们被数十亿个垃圾昵称所笼罩。
另外，对于家庭和工作的各种帐户，该域可能很有意义。 或组织内部公司网络。
从用户的角度来看，为了给某人写信，您需要知道他的完整登录名或公共密钥。
从服务器软件的角度来看，如果请求用户提供其指纹，则服务器将在表中搜索与之相关的登录名，如果立即请求用户登录，则跳过此步骤。 然后，创建帐户当前被委派到的服务器的登录名和地址。 如果没有这样的条目，则认为在登录名中@后面指示的帐户负责该帐户。
用户资料
客户端应用程序存储代表以下内容的用户个人资料：
- 完整的用户登录
- 备份服务器列表
- 公私钥
- 个人资料信息，例如联系人列表，聊天设置和用户个人资料
每个用户的公共密钥分布在联合网络中的每个服务器之间。 由于身份验证不使用存储在服务器数据库中的密码哈希，而是用户的私钥，因此用户可以登录到任何服务器。
授权过程如下：服务器向客户端发送使用客户端的公钥加密的随机数据集，客户端使用其私钥解密，并将解密后的数据的哈希值发送到服务器。 如果数据哈希匹配，则服务器将授权用户。 同时，如果用户上次更改了与之建立连接的服务器，则将用户的新位置通知给联合网络的所有服务器。
无需记住密码（但是，客户端允许您加密私钥）既简化了与Messenger的交互，又存在丢失密钥的风险。 为避免这种情况，建议将它们复制到其他用户设备。 没有什么可以阻止在同一帐户下同时从多个设备聊天，唯一的限制是它们必须全部都连接到同一服务器，否则架构将变得混乱。 但这并不是很大的缺点。
浏览器插件
对于许多产品，弱点是Web应用程序。 当然，这种解决方案有很多缺点。 脱机时将不会下载此类聊天，然后您需要等待完整下载，并且该地址可能被阻止，或者服务器可能崩溃。 手动对地址进行排序-我不太喜欢。
而且，攻击者仍然有可能选择攻击网络应用程序并嵌入将合并所有数据的代码-即使在应用程序的另一部分为您解密数据之后，您甚至都不知道。
在这方面，我建议放弃这样的Web应用程序，并建议为浏览器安装一个附加组件，该附加组件在定义上不存在所有这些缺点。
此外，Web客户端配置服务器的所有者无需降低用于创建其服务器的进入阈值。 每个家庭都有自己的服务器！
运输工具
谁需要一个没有人可与之交流的使者？ 有一些不寻常的Messenger有趣的项目，但是缺少听众的问题使他们至少无法获得一定的知名度。 结果，拥有大量受众的Messenger往往会获得更多的受众，而拥有少量受众的即时Messenger往往会失去它。 通常情况下，这种情况只能改变对广告的大量投资。
嗯，此外，当您紧急需要联系不在其他网络上的某个人时，这种状况需要安装另一个Messenger。
因此，服务器必须支持到第三方网络的传输操作。
如果用户指定数据以连接到其他即时通讯程序中的帐户，他将在联系人中看到他所连接的网络中的人。
与第三方网络的连接是在服务器端进行的，并且在客户端中，联系人显示为最普通的联系人，并且差异很小-例如，显示用户所在网络的图标。
不利的是，有必要使用其数据信任服务器以连接到第三方网络。 并非所有人都准备将其权限委派给第三方服务器，因此您需要鼓励以各种方式创建自己的服务器。
密码学
当然，分散的网络设备无法不对所有传输的数据进行加密，因为我们无法确定即使在委托给我们的服务器中，也没有某种选项卡可以合并所有数据。
之前已经表明用户密钥对用于授权，发送给其他用户的所有消息也都使用发件人的私钥签名，并使用收件人的公钥加密。
这里没有新内容，使用了标准的GPG加密工具。
组中的加密问题尚未解决，但是您可以使用Signal中使用的机制。
已经做了什么
目前，我们已经使用Tornado在Python中创建了一个服务器，该服务器实现了Messenger的基本功能。存在一个稍微冻结的Web版本，应该将其转换为浏览器的附加组件; Rust中有一个库，在此基础上客户端使用QML接口进行操作。
与服务器的连接是使用WebSockets执行的，其中默认情况下将数据序列化为CBOR数据表示形式的二进制格式，但是在建立WebSockets连接时，可以请求其他格式，例如protobuf。
我还认为需要注意的一点是，客户将聊天列表分为多个部分，按最新消息的日期排序（广泛用于现代即时通讯程序和传统花名册），并将联系人分类。 随着Messenger的积极使用，您必须与大量的聊天进行交互，并且变得难以以不断变化的列表顺序进行搜索。 在同一封电报中，部分解决了将所选聊天固定在列表顶部的问题，但这只是该问题的临时解决方案。
→这是包含我们见解的存储库