Summary
This issue documents why Airhop does not currently implement NIP-13 Proof of Work (PoW) for geohash channels. The intent is to capture the rationale for future reference rather than propose immediate implementation.
Background
NIP-13 allows a publisher to perform Proof of Work by varying a nonce tag until the event ID hash satisfies a target difficulty (leading zero bits). This increases the computational cost of publishing events, allowing clients to filter messages below a chosen difficulty threshold.
Currently:
- bitchat Android supports optional NIP-13 PoW for geohash channels.
- bitchat iOS does not implement it.
- Airhop does not implement it.
Current implementation in bitchat Android
- Applies only to geohash channels.
- Disabled by default.
- Default difficulty is 12 (~4,000 hash attempts).
- Mining is capped at 2 million iterations.
- If mining does not converge, the event is published without PoW.
- Validation only credits difficulty when a valid
nonce tag is present.
Why Airhop does not implement it
Limited benefit
PoW only provides value for public geohash channels. DMs, private channels, and groups are already protected by cryptographic keys, while Bluetooth mesh communication naturally limits spam through physical proximity.
Cost falls on constrained devices
A desktop or laptop can generate the required work quickly, while older or low-power mobile devices incur additional CPU usage and battery drain. This makes PoW a poor fit for Airhop's primary offline and resource-constrained use cases.
Little evidence of demand
The only existing implementation is optional and disabled by default, suggesting there is not yet strong demand for the feature.
No interoperability concerns
The nonce is an optional Nostr tag.
- Clients without PoW remain compatible with clients that support it.
- bitchat accepts events without PoW unless a user explicitly configures a minimum difficulty.
- Airhop accepts events containing PoW without requiring it.
If implemented in the future
The implementation should remain small and isolated:
- Perform PoW only when publishing to geohash channels.
- Do not perform PoW for DMs, private channels, or groups.
- Allow configuring a minimum accepted difficulty for incoming events, defaulting to 0 to preserve interoperability.
- Keep the feature disabled by default, with difficulty configurable under Network settings.
- Limit mining iterations and publish without PoW if the limit is reached rather than blocking message delivery.
- Surface mining progress to the user, as higher difficulty levels may introduce noticeable delays.
Revisit criteria
This proposal should be reconsidered if:
- Geohash channel spam becomes a demonstrated problem.
- bitchat iOS adds NIP-13 support, making a shared minimum difficulty more meaningful across the ecosystem.
Summary
This issue documents why Airhop does not currently implement NIP-13 Proof of Work (PoW) for geohash channels. The intent is to capture the rationale for future reference rather than propose immediate implementation.
Background
NIP-13 allows a publisher to perform Proof of Work by varying a
noncetag until the event ID hash satisfies a target difficulty (leading zero bits). This increases the computational cost of publishing events, allowing clients to filter messages below a chosen difficulty threshold.Currently:
Current implementation in bitchat Android
noncetag is present.Why Airhop does not implement it
Limited benefit
PoW only provides value for public geohash channels. DMs, private channels, and groups are already protected by cryptographic keys, while Bluetooth mesh communication naturally limits spam through physical proximity.
Cost falls on constrained devices
A desktop or laptop can generate the required work quickly, while older or low-power mobile devices incur additional CPU usage and battery drain. This makes PoW a poor fit for Airhop's primary offline and resource-constrained use cases.
Little evidence of demand
The only existing implementation is optional and disabled by default, suggesting there is not yet strong demand for the feature.
No interoperability concerns
The
nonceis an optional Nostr tag.If implemented in the future
The implementation should remain small and isolated:
Revisit criteria
This proposal should be reconsidered if: