Geohash Prefix Filter for Nostr Relays
Currently, there is no way to query ranges, dimensional data, or hierarchical data from Nostr relays. For most events this is acceptable, but finding geohash events at a specific region and depth is not feasible. This is an important use case for map applications that want to show events in a region from the highest zoom level (shortest geohash) to some specific zoom level. If you want to query each geohash value separately, the number of query tags grows exponentially based on query depth.
Proposed Extension
One way to support efficient searches is to extend relay subscription filtering with geohash prefix searches. The proposed syntax for filtering is to add a caret (^) symbol after the g-tag to indicate a prefix filter, optionally followed by a number that defines the maximum length of returned geohashes. For example:
| Query | Value | Description |
|---|---|---|
#g |
abc |
Find events with exact geohash ‘abc’ |
#g^ |
abc |
Match geohashes starting with ‘abc’ |
#g^5 |
abc |
Match geohashes starting with ‘abc’ that have maximum length of 5 |
Prefix search enables searching ranges. For hierarchical or tree-like data (like geohashes), specifying maximum length would target the filter for specific levels or depths of the data.
Other Solutions
This proposal differs from previous prefix search proposals in that the prefix operation is declared in the tag key (#g^=abc) and not in the tag value (#g=abc*). Some existing events contain geohashes up to the root level. For example, an event with geohash 'abcd' would also contain hashes 'abc', 'ab', and 'a'. I believe this is a way to circumvent the filtering problem, but adding derived values into events might not be the way to go. This also bloats the top-level geohashes and partly hides the actual precision level of the event.
Implementation
I implemented geohash prefix filtering support in the Rnostr relay. The implementation is quite simple, and for lexicographically sorted values, it requires only selecting the correct ranges with no extra indexing needed.
Beyond Geohashes
Prefix filtering would probably be useful for other tags too. For example, matching dates would be handy: assuming an event has an ISO 8601 date tag, a filter for all events in October 2025 would be date^=2025-10. Whether prefix search is generic enough to be extended directly to other tags would require some discussion.