使用WebPush和ServiceWorkers围绕推送通知系统解决一些UX注意事项。此外，该系统应该能够优雅地处理共享同一浏览器的多个用户。
更具体地说，我有以下限制：
1）用户不应该看到不适合他们的通知。
2）用户推送订阅的状态应该是其他用户不透明和不可变的。即推送订阅的状态不应该基于任何人的行为/行为，而应该基于我自己的行为/行动。
满足第一个约束条件非常简单。我决定将当前登录的用户ID存储在IndexedDB中，并在推送有效负载中包含目标用户的ID。然后，如果这两个ID匹配，则只向用户显示推送通知是直截了当的。
但是，满足约束2已被证明是非常难以捉摸的。到目前为止，我已经尝试过：
1）用户和推送订阅之间的一对一映射。这是我尝试的第一件事，因为它让我感到最自然的映射。但是，由于创建新的推送订阅会使先前用户的订阅无效，因此需要原始用户在后续登录时创建另一个订阅，从而使第二个约束失败。
2）共享推送订阅。这样做的好处是不会使推送订阅无效，因此原始用户的后续登录将按预期运行。但是，后续用户实际上都不需要向浏览器授予权限，因此第二个约束失败。
3）即使我能够使用上述2个选项中的一个进行操作，仍然没有什么能阻止其他用户简单地进入浏览器设置并禁止通知，从而阻止所有推送订阅。但是，我想这只是我必须忍受的事情，没有优雅的解决方案。
我确信有很多聪明的头脑正在研究上述问题，所以关于如何有效地满足上述约束2，我全力以赴。
感谢。
答案 0 :(得分：1)
我在开发Pushpad时遇到了同样的问题。我们尝试了不同的解决方案，其中一些解决方案，例如用户和浏览器之间的多对多关系，很快就变成了一场噩梦。所以我建议采用以下方法，这对我们来说是最好的方法。
每个订阅（端点）都是一个设备（浏览器），一次最多可以与一个用户关联。 尽可能尝试将数据与用户相关联，而不是与设备相关联。通过这种方式，订阅（端点）可以转移给其他用户，并且当端点到期或被替换时，您不会丢失数据。然后，当您需要根据用户数据发送通知过滤您的受众时，找到收件人并将通知发送到关联的设备。
您可能希望与设备关联的唯一数据是设备首选项，设备首选项对使用该浏览器的所有用户都是全局的。这与浏览器权限（允许/阻止）对所有用户都是全局的事实是一致的。
上述解决方案部分符合您的要求：
1）用户不应该看到不适合他们的通知。
是：
2）用户推送订阅的状态应该是其他用户不透明和不可变的。
是的，因为您没有保留与设备相关联的数据。您将数据与数据库中的用户相关联。
答案 1 :(得分：0)
无法满足这两种约束。您需要选择一对一映射（1）或共享推送订阅（2）。您不能使用浏览器来发送推送通知，同时期望来自同一浏览器的某些行为（w.r.t.权限，nuking）......