Pause Nostr geohash firehose in background to cut mobile data Closes: #700#706
Open
dmcarrington wants to merge 2 commits into
Open
Pause Nostr geohash firehose in background to cut mobile data Closes: #700#706dmcarrington wants to merge 2 commits into
dmcarrington wants to merge 2 commits into
Conversation
The Bluetooth mesh uses no mobile data, but the Nostr relay layer ran unbounded in the background: the live geohash channel subscription kept streaming across 5 relays, the presence heartbeat broadcast every ~60s, and a participant-refresh timer polled every 30s. Combined with reconnect/re-subscribe replay on public relays, this could burn gigabytes while idle. GeohashViewModel now tears down the high-volume subscriptions when the app is backgrounded (onStop) and restores them on foreground (onStart): - drop the live channel message stream (currentGeohashSubId) - drop sampling subscriptions - cancel the presence heartbeat and participant-refresh timer Gift-wrap DM subscriptions are intentionally kept alive in the background since they are filtered to our pubkey (lightweight) so DMs still arrive. The selected channel is tracked in activeChannelGeohash so the stream can be rebuilt on foreground without losing the user's selection. The channel subscription logic is extracted into subscribeChannelStream() / subscribeChannelDM() helpers. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
|
The problem is that the geohash-$geohash subscription has a filter for both kind 20000 and kind 20001 (message and heartbeat). So the same sub is used for the heartbeats as well. You propose to pause it when backgrounded, but doing so would also pause receiving actual messages from the geohash chat. When we measured traffic, heartbeats where by far the biggest issue for mobile data. Maybe we could articulate this PR more, and create a different subcription for sampling the heartbeats of the current geohash, instead of using the same one for the messages. Then we can pause that one? |
Author
|
Updated to pause geohash heartbeats (20001) while keeping alive geohash messages (20000) by using different subscriptions |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Nostr relay layer ran unbounded in the background: the live geohash channel subscription kept streaming across 5 relays, the presence heartbeat broadcast every ~60s, and a participant-refresh timer polled every 30s. Combined with reconnect/re-subscribe replay on public relays, this could burn gigabytes while idle.
GeohashViewModel now tears down the high-volume subscriptions when the app is backgrounded (onStop) and restores them on foreground (onStart):
Gift-wrap DM subscriptions are intentionally kept alive in the background since they are filtered to our pubkey (lightweight) so DMs still arrive.
The selected channel is tracked in activeChannelGeohash so the stream can be rebuilt on foreground without losing the user's selection. The channel subscription logic is extracted into subscribeChannelStream() / subscribeChannelDM() helpers.
Description
Checklist