E.G. kylewm.com used to not support PuSH 0.4 (i.e. did not have rel=hub and rel=self links on the topic page), and as such I have several fallback hub/polled subscriptions (for kylewm.com and kylewm.com/ due to poor deduping in shrewdness). Now kylewm.com does support PuSH 0.4, and taproot/subscriptions should seamlessly upgrade the subscription to a real PuSH 0.4 subscription.
The same code which handles this should also handle the case of hubs changing, as it’s effectively the same thing (i.e. changing from no hub (subscription using the fallback hub) to a PuSH hub).
Idea: create a listener on the ping event, applied by default which simply checks to see a topic has changed hub, and, if so, unsubscribe + subscribe to the topic again.
E.G. kylewm.com used to not support PuSH 0.4 (i.e. did not have rel=hub and rel=self links on the topic page), and as such I have several fallback hub/polled subscriptions (for kylewm.com and kylewm.com/ due to poor deduping in shrewdness). Now kylewm.com does support PuSH 0.4, and taproot/subscriptions should seamlessly upgrade the subscription to a real PuSH 0.4 subscription.
The same code which handles this should also handle the case of hubs changing, as it’s effectively the same thing (i.e. changing from no hub (subscription using the fallback hub) to a PuSH hub).
Idea: create a listener on the ping event, applied by default which simply checks to see a topic has changed hub, and, if so, unsubscribe + subscribe to the topic again.