iOS/Android 推送通知在自托管 Dicsourse (Docker) 上

支持
, ,
1

我花了 6 个多小时阅读 Discourse Meta 上 2018 年及以后的消息，与 Discourse AI 机器人交谈，使用多种模型进行深入研究和测试。我希望确认我的理解。感谢您的耐心，我意识到这个问题可能会被问到很多次。

总体成功：我重视出色的用户体验，出色的用户体验要求用户在完成目标时思考最少。我期望收到类似 WhatsApp 的新消息通知到我的 iOS 设备（iPhone 15 Pro，iOS 26.2）。

  1. 在最高级别上，似乎解决这个困境/iOS 限制的“最佳答案”是 Discourse Hub。它使用轮询，因此会有轻微的延迟，但这目前是从自托管的 Discourse 实例（在 docker 上）获取 iOS/Android 推送通知的最佳/最稳定的方法。如果是这样，有人知道我们谈论的延迟是多少，是几分钟还是几小时？我找不到具体信息。

  2. 如果第 1 点成立，我是否正确理解推送通知仅限于聊天？

  3. 我花了大量时间在 Mac OS X Safari、Chrome、Safari 无痕模式、Chrome 无痕模式下，在我的测试环境中与多个用户一起测试。此外，我尝试了 20 多次设置和重新安装 PWA。我仔细检查了 PWA 上的通知设置。我使用多个帐户，在不同的浏览器中测试，所有这些都是通过在 discourse 中发送聊天消息进行的。我特意退出了所有会话，以确保帐户不处于活动状态。除了最初的“通知已启用”推送消息外，经过 3 多个小时的测试和 20 多次在多个帐户上重新安装 PWA，我无法获得任何 pushover 通知或 PWA 上的徽章。这听起来像是 2026 年 1 月 iOS 上 PWA 推送通知的准确状态吗？我没有安卓手机可以测试。

  4. 似乎导致推送通知出现这些不一致行为的主要原因是 iOS Safari 通知“技术问题”。在目前这个时间点，看不到解决的希望。

  5. 还有一个使用 pushover 应用的选项，但这需要设置一个帐户并每月支付 5 美元。如果我希望为用户创造出色的用户体验，像 pushover 这样的东西肯定不是一个选择。我没有用过 ntfy，也许那个更容易。即便如此，我可能也不会要求我的用户这样做。这是一个由非技术人员组成的社交团体。

  6. 我在桌面 Safari 上收到了推送通知。电子邮件工作也正常。

  7. 如果人们可以自行授权以在他们选择的第三方应用程序（例如 Telegram 或 WhatsApp）中接收通知，那可能是一个潜在的解决方案，我看到了 https://www.discourse.org/plugins/chat-integration 用于 Telegram。这可能是一个变通方法……尽管在我这个圈子里，人们唯一可能拥有的应用程序是 Telegram。

  8. 我不反对 Twilio 集成，即使我需要为短信付费给 Twilio。我没有看到这方面的选项或插件。这一举动纯粹是出于绝望。而且我将不得不为每条消息收取 1-3 美分或 Twilio 收费的任何费用。

  9. 采用“原生的 Discourse iOS 应用”可能不切实际，并且极有可能在 Apple App Store 中被拒绝，确认吗？我看到过很多关于此的报告。

  10. 推送通知在安卓上是否可能工作得更好，更一致/可靠？

总之；2026 年 1 月，获得像原生应用一样稳定可靠的 iOS/Android 推送通知的最佳、最可靠的方式是使用 Discourse Hub。

附注：我私下里真的很希望我遗漏了什么，我的经验并不准确。

2 个赞
2

在 Android 上，PWA 应该运行得非常好。多名员工每天都使用 PWA。

在 iOS 上，由 Discourse 托管的站点可以在 DiscourseHub 中获得完整的推送通知。自托管用户通过轮询获得推送通知，是的。

不幸的是，自托管用户的 DiscourseHub 轮询依赖于系统后台任务。它们不能保证在任何特定时间运行……所以，没有人知道延迟是多少。操作系统决定。如果你经常使用该应用程序，我认为（非常不确定地）轮询大约每 15 分钟发生一次。如果你不经常使用该应用程序，频率可能会低得多。

不，它应该适用于主题、聊天、私信。

Webview 包装器应用很有可能被拒绝，是的。但完全原生的应用则复杂得多。

3 个赞
3

我对推送通知的情况也非常困惑。

它在 Mac 上作为 PWA 可以工作，但在 iOS 上却不行。我收到了徽章，但没有收到通知（除了最初的“成功”通知）。

为什么它不工作？我的托管服务商是 communiteq.com，我不想安装一个应用程序。

4

我们的托管不施加任何限制，它与 iOS 上的通知配合得很好。

不过，它通常相当脆弱，特别是当你是管理员时——假冒其他账户似乎会破坏通知设置。

5

我让技术支持测试了，但它似乎不起作用（我没有进行任何模仿或类似的操作）。

6

我记得结论是它在您的特定设备上不起作用？

我理解这不是一个令人满意的答案，但问“为什么不起作用”可能有点太笼统了。

话虽如此，如果有一个针对 iOS 的好的故障排除指南，那就太棒了。

7

不，在我们的社区中，任何使用 iOS 设备的人都没有成功。

8

我决定再试一次，所以我把它打开了，现在它能用了！:exploding_head:

也许是 Discourse 更新修复了它？谁知道呢！

1 个赞
9

我敢打赌是 iOS 更新。

1 个赞
10

还有其他人确认过吗？

我刚从主屏幕删除并重新添加了。如果通知能启用那就太好了！

1 个赞
11

它应适用于任何添加到 iOS 16.4 及以上版本主屏幕的 Discourse 实例。

如果您已将 Meta 添加到主屏幕，我的这条回复将会触发其中一个。

2 个赞
12

感谢 @Falco！

我意识到我在另一个自托管论坛上还有一个测试账号……我登录并给自己发送了一条测试消息。

成功了！现在已经有好几次成功了。

哇，这太棒了。

1 个赞
13

这句非常不幸的代码就是原因所在

依我看，这毫无意义。

2 个赞
14

也许是时候去掉那行代码了😀

2 个赞
15

这是为了防止出现这种情况：你不想让推送通知发送到已登出的设备上。你在某台设备上开启了推送通知，但之后你退出了登录。

随后，有人通过私信向你发送了一条敏感消息。系统向所有已注册的设备发送了推送通知。而你已登出的设备在技术上仍属于已注册设备，因此它仍然会收到通知的完整预览内容。哎呀。

为了安全起见，我在首次推送时直接清除了所有密钥，但这显然过于极端且令人困扰。或许我们应该将推送通知订阅与特定用户会话关联起来，或者以某种方式确认预期用户是否仍处于登录状态？

1 个赞
16

是的，就是这样！我认为他们不应该使用 user_id，而应该使用 user_auth_tokens.id？

1 个赞