Replace the priority-only heuristic in handlePushListen
(highPriority = !expired && minPriority == 0) with isHighPriorityPush,
so the proxy promotes a notification to high (urgent) push priority
only for real-time call signaling.
Previously every value published at the default priority 0 — including
the frequent connection-request refreshes that carry an empty
pushType — triggered a high-priority push. On mobile this floods the
platform's adaptive high-priority quota; once tripped, the platform
silently drops genuine call pushes, so incoming calls fail to ring
while the device is in the background.
Restricting high priority to audioCall/videoCall keeps calls waking the
device while the surrounding presence/sync noise is delivered at normal
priority. This is a strict subset of the previous high-priority set, so
no notification that was normal before becomes high.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Extract the decision of whether a push-listen notification must be
delivered at high (urgent) FCM/APNs priority into a static, pure
helper (isHighPriorityPush) so it can be unit-tested without a push
gateway.
Only real-time call signaling — values whose pushType is "audioCall"
or "videoCall", published at high priority (priority == 0) — warrants
an urgent push. Presence/connection-request refreshes (empty
pushType), non-call types and expirations are not urgent.
The helper is not wired in yet; this commit only adds it and its
tests, keeping the current handlePushListen behavior unchanged.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Because there is multiple unifiedpush endpoint (ntfy.sh is one),
we should not pass it as an option to dhtnode, but use the one
provided by the user in the token (from unified push library).
Make the proxy able to support the UnifiedPush platform, so that
applications using the proxy server can use any UnifiedPush provider.
Documentation: https://unifiedpush.org/
How to test:
+ Install a UnifiedPush provider on a device (e.g. https://ntfy.sh)
+ Run dhtnode with a proxyserver and --unifiedpush https://ntfy.sh
+ Subscribe to a random topic on ntfy (e.g. "dhtproxytest")
+ Subscribe to a hash on the DHT:
curl -X SUBSCRIBE http://my.dht.proxy:8000/key/foo \
-d '{"key":"dhtproxytest", "platform":"unifiedpush"}'
+ Send data on the subscribed hash
Note: the topic should be completely random.
when searching for a value to put, the proxy server returned
a json with value->id = 0, causing the client to not refreshing
correctly the values later (when timeout-ing, the value to refresh
is not found).
When a second permanent put request was received, we didn't call
async_wait after changing the expiration, causing push to not be
sent the second day and presence to expire on some devices after
~3 days.
If the android device is offline during more than 10 minutes, it
can misses push notifications and cause an incorrect state with
values not expired even if the re-subscribe is correct.
Cyrille BéraudandCopilot
Adrien Béraud
Pavan Koushik Nellore
Adrien Béraud
Lucas Fryzek
François-Simon Fauteux-Chapleau
Andreas Traczyk
Lanius-collaris
Kateryna Kostiuk
Sébastien Blin