Status App 在 iOS 上的通知功能

通知是聊天软件的必备功能。它们扮演了一个内在纽带的角色，因为用户通过通知知道他们何时收到了消息。

鉴于 Status 信使的去中心化 P2P 架构，通知的意义甚至更大（如我们先前的文章所述1）。例如，如果将消息发送给处于脱机状态的 Status 用户，则当前实现是将这些消息临时存储在“历史记录”节点上，保存 30 天然后删除。因此，如果用户在那 30 天内没有上网（不太可能，但似乎合理），并且如果没有发送收到消息的通知，则用户将无法接收到这些消息。这与服务器（几乎）无限期地存储消息的典型客户端-服务器信使体系结构不同。

Status 应用程序 V1.4 版就支持 Android 系统上的通知功能。Status 应用程序 V1.7版 则实现了 iOS 上的通知功能。

虽然 iOS 通知功能的典型客户端-服务器实现允许服务器连接发送和接收通知的客户端，但是Status 信使使用去中心化的推送通知和 Waku2 协议以隐私友好的方式实现了这一点。

本文深入探讨 Status iOS 应用上的通知实现。我们首先将本地通知与推送通知进行对比，并描述推送通知在 Apple 设备上的工作方式。我们将详细说明如何在 Status 信使的去中心化 P2P 架构中实现 iOS 通知功能，然后通过讨论此方法的安全性和隐私性进行总结。

目前状况

到目前为止，当将消息发送给 Status iOS 应用程序用户时将不会收到任何提示。如果有人在向他们发送消息时碰巧他们在线，则他们将收到这条消息。否则，此类消息将在中继节点之间传播，直到它们的生存时间（TTL）过期（当前设置为 15 秒），然后暂时保存在“历史记录”节点中长达 30 天。

在用户离线时历史记录节点会为他们保存消息。这些节点不知道消息的内容或接收者，只能访问消息主题。（这些概念在我们前面的文章3中进行了详细说明。）

如果预期的接收者在接下来的 30 天内未使用其 Status iOS 应用，则这些消息（以及其他消息）将从“历史记录”节点中删除，并且用户永远不会收到这些消息了。对于聊天软件来说，这显然是糟糕的用户体验。假设大多数用户会在一个月内登陆查看其应用中的消息，但是即使这样，用户也希望能够及时阅读他们的消息。

通知：本地与推送

通知既可以在应用程序/设备内部本地触发，也可以从关联的服务器远程“推送”到应用程序，即使应用程序未运行也是如此。Status 应用本身在收到消息时生成的通知称为本地通知。从特定的推送通知服务器发送到 Status 应用程序的通知，与消息本身分开，称为推送通知。

Status 可在 Android 和桌面应用程序上实现本地通知。本地通知要求应用程序始终运行以接收消息并随后触发通知。尽管在桌面版本上很容易做到这一点，但 Android 应用程序需要连续运行的前台服务来接收消息，即使该应用程序在后台，也可以触发相应的通知。

Status 在其 iOS 应用上部署推送通知。这是因为 iOS 仅允许某些类型的应用程序（例如 VOIP）在后台保持打开状态。iOS 应用程序在后台运行时可以请求执行时间，但是用例数量有限，并且通常响应速度不足以支持推送通知系统。此外，与 Android 不同，iOS 不提供让我们实现本地通知的前台服务功能。这有效迫使我们实施推送通知。

iOS 上的推送通知

Apple Push Notification Service4（APNs）是一项在 iOS 和 macOS 设备上启用远程通知的技术。APN 服务位于应用程序提供商和用户设备之间。

当用户最初启动应用程序时，将在应用程序和 APN 之间建立加密的持久连接，使它能够接收通知。另一端的应用程序提供商使用 Apple 提供的加密证书配置从应用程序服务器到 APN 的持久安全通道。

应用程序提供商将通知请求发送到 APN，然后将其转发到目标设备。收到通知后，设备会将其转发到适当的应用程序并管理与用户的交互。这些通知具有特殊的特权，即使在应用未运行或处于后台时，也可以接收和显示这些通知。即使设备已关闭电源，APN 也会缓冲所有通知并稍后重新发送。

所有需要通知的 iOS 应用都使用 APN。

Status 在 iOS 上的通知

Status 在 iOS 上使用 APN 进行通知。该实现还包括其他两个重要组件：Status 推送通知5（SPN）服务器和 Gorush6 服务器。SPN 服务器用于管理通知的客户端注册/查询，而 Gorush 用于实际发送通知。

Gorush 是使用 Gin 框架以 Go（Golang）编写的开源推送通知微服务器。本节的其余部分描述 SPN 服务的客户端注册和通知功能。规范7中提供了详细的流程，消息格式和协议详细信息。

客户端注册

客户端可以向他们选择的一个或多个 SPN 服务器注册。向 SPN 服务器的公钥分区主题8中发送推送通知注册（PNR）消息。

PNR 消息包含其他客户端发送推送通知所需的信息，例如 APN 发出的 device_token，设备的 installation_id 和 access_token。它可能包括 allowed_key_list，它是使用 Diffie-Hellman 在客户端和允许发送通知的特定联系人之间生成的 AES 密钥加密的 access_token 的列表。它还可能包括 blocked_chat_list，该列表是不会触发通知的聊天 ID 的 SHA2-256 哈希列表。它还允许客户端使用特定的 allowed_mentions_chat_list 指定是否要在提及时得到通知。 allowed_mentions_chat_list 是要接收提及的聊天 ID 的 SHA2-256 哈希列表。

SPN 服务器对此消息进行必要的检查，然后以成功/失败作为响应。客户端可以向多个 SPN 服务器注册以提高可用性。

每个注册了一个或多个 SPN 服务器的用户都会定期发布有关它的消息。如果没有基于公钥进行过滤，则此广告中将包含 access_token。这将通过与正常的联系代码广告耦合在联系人代码9主题上进行广告。这允许其他人发现用户的推送通知详细信息。

发送通知

想要发送推送通知的客户端需要具有来自相应用户的广告或查询 SPN 服务器所需的access_token。这用于构造发送到 SPN 服务器的推送通知消息。

SPN 服务器验证 access_token，然后将通知请求转发到 Gorush 服务器，该服务器传递实际的通知消息。

Status 信使默认情况下启用发送通知，但是需要用户选择接收通知。

安全和隐私注意事项

Access token：如我们早先文章中10所述，在开放、无需许可、以隐私为中心的去中心化 P2P 消息传递平台上，垃圾邮件相对更容易产生。所述的 access_token 用于将访问控制添加到通知流中，使得该协议可以实施策略，例如仅接受来自特定联系人的通知。这样可以在一定程度上减少垃圾邮件的通知。

一个人可以生成一个随机的聊天密钥，获取另一个用户的 access_token，然后通过通知对该用户发送垃圾邮件。在 allowed_key_list 中使用加密的 access_token 可以缓解这种情况，但这意味着事先向 SPN 服务器公开了（客户端在注册过程中）的实际聊天密钥（请参见下面的匿名模式）。

使用 access_token 还可以提高可否认性，因为 SPN 服务器只知道谁要求令牌，而不必知道谁发送了推送通知。然而，在某些情况下，两者之间的相关性可能微不足道。

隐私：客户端与 SPN 服务进行交互时，他们会披露通知协议正常工作所需的某些信息，从而在一定程度上降低了他们的隐私。

向 SPN 服务器注册时，客户端会公开其聊天密钥以及将接收通知的设备。客户端还可能公开其感兴趣的聊天 ID 的哈希值（allowed_mentions_chat_list）和 要过滤掉的聊天 ID 的哈希值（blocked_chat_list）。

查询 SPN 服务器时，客户端将显示它有兴趣向另一个客户端发送推送通知，但是不公开查询客户端的聊天码。

匿名模式：可以使用匿名操作模式来提高隐私性。处于此模式的客户端可以使用不同于其聊天密钥的新通知密钥向 SPN 服务注册。通知密钥实际上是私密的，仅向希望接受通知的用户客户端展现。客户可以直接通过联系人更新来共享此密钥，并在该密钥的联系人代码主题上广告 access_token。

此匿名模式实际上不会与服务器共享发送者或接收者的聊天身份。但是，这可能会导致丢失推送通知，因为通知密钥的广告留给了客户端，而没有 SPN 服务器的参与。

去中心化：尽管 Status 现在可以运行 SPN 服务器，但从技术上讲，推送通知服务器可以由任何人运行。Gorush 服务器也可以由任何人运行，但是它们将需要 Apple 发行的证书才能通知 Status 客户端。

结论：在 iOS 通知功能的典型客户端-服务器实现中，客户端 A 通过提供其设备令牌向应用服务器 S 注册，并连接到 APN。当客户端 B 将消息发送到客户端 A，服务器 S 将消息传送到客户端 A 并且还通过 APN 发送一个推送通知到客户端 A。这种模式使服务器 S 很容易地连接发送和接收的客户端。

Status 使用去中心化的 P2P 架构在 Waku 上的对等点之间传递消息，那里没有服务器可以连接消息发送和接收节点。通过使用 SPN 服务器的通知，我们可以达到相同的目的。

好处有四个方面：1）客户端可以选择要与之交互的 SPN 服务器，甚至可以自己运行2）SPN 服务器在体系结构上是去中心化的，因此无法轻松地连接通知的发送方和接收方3）SPN 服务器没有访问与通知相对应的消息，这使连接变得更困难4）查询 SPN 服务器不会公开发送者的身份。

这种架构使我们能够在保持最高隐私考量的同时，在 iOS 上实现通知功能。

概要

Status 应用程序 V1.7 版集成了 iOS 上的通知功能。Status 信使现在在桌面、Android 和 iOS 应用程序中都具有备受期待的通知功能。

在本文中，我们区分了本地通知和推送通知，并描述了在我们的 iOS 应用程序上实现推送通知的基本原理。我们描述了此实现的关键知识点，重点介绍了 Status 推送通知服务器和 Gorush 服务器。最后，我们讨论了此方法的安全性和隐私注意事项，以说明 Status 如何在 iOS 上实现隐私友好的通知功能。

因此，现在，iOS 上的 Status 用户可以收到通知，而不会再错过任何消息。

（感谢 Andrea Piana 和 Jonathan Zerah 审阅了本文的草稿并提供了有用的反馈。感谢 Alex Howell 的详细说明。）

在此处11安装 Android 和 iOS 版 Status。

参考链接：

https://our.status.im/the-life-of-a-message/

https://our.status.im/peer-to-peer-messaging-where-whisper-falls-short-and-waku-picks-up/

https://our.status.im/the-life-of-a-message/

https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html

https://github.com/status-im/specs/blob/master/docs/raw/push-notification-server.md

https://github.com/appleboy/gorush

https://github.com/status-im/specs/blob/master/docs/raw/push-notification-server.md

https://github.com/status-im/specs/blob/master/docs/stable/10-waku-usage.md#partitioned-topic

https://github.com/status-im/specs/blob/master/docs/stable/10-waku-usage.md#contact-code-topic

https://our.status.im/can-we-can-spam/

https://status.im/get/

—-

编译者/作者：Status

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。