UnifiedPush：自由的去中心化开源推送通知协议

引子#

我之前为寻找一个体验最棒的移动设备浏览器发愁：Edge 部分插件未登录移动平台，Via 现在用不了大部分油猴脚本了，Cromite 使用体验下来也非常沟槽（插件不适用，不能自定义下载器……）。我尝试转战 Firefox (Gecko) 系列，但发现火狐系的浏览器依旧还是有性能问题：浏览网页很卡。

但本文主题依旧不是浏览器，而是我使用 Fennec F-droid Browser (一款基于 Firefox 的注重隐私的浏览器分支) 时偶然发现一个新奇的设置选项：它一直提示我未配置“UnifiedPush”需要我去启用。于是激发我的好奇心去主动了解一下这到底是什么东东，花了好几个小时研究配置完体验了一下，才有了这么一个文章。

什么是「UnifiedPush」？#

UnifiedPush is a decentralized push notification system that lets you choose the service you want to use. It’s designed to be privacy-friendly, flexible, and open — making it perfect if you want control over your push notifications. —— UnifiedPush 官网

翻译：

UnifiedPush 是一个去中心化的推送通知系统，允许你选择你想使用的服务。它设计得注重隐私友好、灵活且开放——如果你想控制推送通知，它非常合适。

简单来说，UnifiedPush (译名：统一推送) 就是一个开源的通知推送协议。相较于 Google 的 FCM (Firebase Cloud Messaging)，苹果的 APNs (Apple Push Notification service)，微软的 WNS (Windows Push Notification Services)，以及中国大陆的 统一推送联盟 (只是英文撞名了，与 UnifiedPush 无任何关系)，它的优势是 去中心化，即不依赖任何单一公司或服务，消息经服务器推送过程中保持点对点(端对端)加密，保障消息推送的隐私安全。

貌似墙内的翻译：https://www.bilibili.com/read/cv21845282

为什么要选择「UnifiedPush」？#

摘自：https://unifiedpush.org/

UnifiedPush 的 主要优势：

• 开放标准： 具备互操作性且有韧性(弹性)。

• 去中心化： 不依赖任何单一公司或服务，减少对守门人的依赖。

• 隐私优先： 推送通知是加密的。

• 自我托管： 你可以自己运行通知服务器，以获得所需的控制权。

• 用户控制： 用户选择他们使用的服务，而不是开发者。

主要特点：

• 无需特权服务： 使用轻量级服务并遵循最低权限原则。可在 去谷歌化 (de-Googled) 的安卓设备和自定义 ROM 上运行。也可作为用户服务在 Linux 设备上运行。

• 多个发行版(分发商/服务端)： 从发行版列表中选择。

• 轻松集成： 开发者可以轻松地为他们的应用添加 UnifiedPush 支持。

工作原理 (如下图)：APP送出通知之后，需要一個服务端(Distributor)负责转发消息，再由手机上的APP收发。这里服务器可以自建，也能使用 Mozilla 的公共服务器代发。

总之，你选择了 UnifiedPush，你将拥有很多隐私与自由，无需担心你接收的任何一条消息推送会被大厂监管或拦截，用户相比开发者拥有更多自主权（比如可以自己搭建消息推送服务器，以获得控制权）。

如何使用？#

Step 1: 安装发行版服务端 App#

UnifiedPush 官网提供许多服务端，其中 Ntfy 需要自建服务器，提供REST API。有公用节点，但需要注册账号才能使用。这里我推荐 Sunup，优势是不用注册与不用自建服务器，使用 Mozilla 的推送服务器 ( https://push.services.mozilla.com )。

Step 2: 安装要使用 UnifiedPush 的 App#

以 Matrix 客户端 FluffyChat 为例。注意：必需要在 F-Droid 平台上下载！不要从 Google Play 商店下载！ 因为 F-Droid 的 APP 不能依赖 FCM，所以它会要求你使用 UnifiedPush。

同理，上文提到的 Fennec 浏览器设置里也有 UnifiedPush 开关，开启后该浏览器的资讯等消息都经过 UnifiedPush 服务端推送。

底层原理#

UnifiedPush 的核心是一个规范。该规范分为两半：

• 在设备（客户）端，它定义了一个应用编程接口 (API) 以允许任何最终用户应用（例如您的消息应用）与任何分发器应用（ ntfy、NextPush 等）
• 在服务器端，API 描述了应用服务器（Matrix homeserver、Mastodon 实例等）如何向推送服务器（ntfy 服务器、Nextcloud 服务器等）发送消息.

我们的客户端库和参考代理分别协助实施规范的两端。

为获得 UnifiedPush 端点（向其发送通知的功能 URL），最终用户应用向 UnifiedPush 分发器注册，该分发器与推送服务器保持持续连接。注册后，分发者向应用提供指向推送服务器的唯一 URL。该端点 URL 然后由应用客户端传输到应用服务器。

当应用服务器需要向最终用户应用发送推送消息时，它会使用简单的 HTTP POST 请求将消息发送到推送服务器。推送服务器然后将推送消息转发给分发器，分发器将其传递给最终用户应用。

UnifiedPush 的一个关键特性是不指定推送服务器和分发器之间的通信。这意味着可以采用多种技术，例如 WebSocket、服务器发送事件、XMPP、原始 TCP 甚至 SMS，只要最适合用户即可。

分发器使用平台特定的 IPC 机制（例如 Android 上的 Broadcast Intents 或 Linux 上的 D-Bus）来唤醒应用并允许它处理推送消息。然后应用可以处理数据并根据内容决定是否显示通知。重要的是要注意 UnifiedPush 不处理用户可见通知的显示；它只向应用提供数据。因此，应用可以支持各种平台的通知功能，而无需 UnifiedPush 或服务器的参与。

在应用服务器本身不支持 UnifiedPush 的情况下，推送网关可以将特定于应用的通知转换为 UnifiedPush 服务器协议。一些流行的推送网关，例如用于 Matrix 的推送网关，被直接集成到推送服务器中以方便自托管。此外，Rewrite Proxies 用于推送服务器不支持 UnifiedPush 的极少数情况，例如 FCM 分发器发送 UnifiedPush-over-FCM。

针对大陆用户的 FAQ#

碎碎念#

起初，我第一次从 Fennec 那边无意发现了它，UnifiedPush 激发我的好奇心比我第一次了解到 FCM、以及各家手机厂商的推送协议（MiPush、HMS Push、OPPO Push等）都更加强烈。毕竟我想不到一个小小的通知推送协议也可以开源透明，同时也符合少数人对隐私的敏感需求，这是在现在通知协议被各大手机厂商垄断的时代都意想不到的。

但这玩意儿的处境也非常艰难：

比如上文的 FAQ 也提到，对于大陆用户，许多国产软件/开源项目，抑或是大众商业化软件，都不支持 UnifiedPush，这对于开发者与极客用户来说无疑是一个极大的生态挑战，这样的推送协议在大陆开源社区的存在感 和棍母没啥区别 非常低。简单类比，在车万社区中，灵梦厨、魔理沙厨和早苗厨不是那个早苗，是东风谷早苗都非常多，在哪随便都能遇到；而冴月麟厨极少能被看见，像是被忽略了）））

(可能有点冒犯一些群体，属实抱歉)

这是在大陆的现状。其实放眼全球，无论在哪个互联网社区，UnifiedPush 都依然非常小众，绝大部分国外用户都使用的是 FCM 与 APNs，其实与全球的开源社区/自由软硬件社区一样，终归属于特定的群体小范围传播，很难迈向大众化，同时还要面临大厂的垄断枷锁冲破软硬件市场的防线。如果有一天，某个知名开源软件大众化了，还能保持初心，我看到也没啥可遗憾了）

补充：你们猜我为什么一直特别强调它的小众特点？因为我撰写这篇文章搜集素材的时候，发现国内关于 UnifiedPush 的记载少之甚少，全是被 腾讯云，CSDN，gitcode 等神秘内容农场充斥着，没有一点有价值的信息供我参考。最后发现只有一丢丢的极少部分的中文 Blog 文章对此有介绍，可见它在中文社区真的小众得不能再小众了。(它的用户群体估计都没 FreeBSD 的个人用户体量大)

小结#

如果你像我一样，对这个推送协议项目非常感兴趣，你可以根据上文的 教程 来体验 UnifiedPush 带来的新鲜感。如果你是接手了一个或多个 Android/Linux 软件开源项目的开发者，读完这篇文章希望你可以为自己的项目接入 UnifiedPush（官网也有开发者文档教你如何接入），为开源推送协议社区献出一份力量。如果有朝一日，一种注重隐私的推送服务能被普及开来，对于用户简直利大于弊，从此无论什么消息再也不必担心经过大厂服务器审查或被大厂截获触发警告了。我非常期待这一天的到来……