How BitChat Uses the Nostr Protocol for Global Reach: A Technical Deep Dive

BitChat combines a local Bluetooth mesh with the decentralized Nostr protocol to enable worldwide messaging without central servers, using geohash-based channels and custom encrypted envelopes for global connectivity.

BitChat is an open-source messaging application developed by permissionlesstech that bridges offline Bluetooth mesh networks with the Nostr relay infrastructure. By implementing a hybrid transport layer, BitChat ensures users can communicate globally even when direct peer-to-peer connections are unavailable, all without requiring phone numbers or centralized intermediaries.

Geohash-Based Channel Discovery

BitChat organizes global communication around geographic proximity using geohash-based channels. According to the project documentation in README.md, messages route through Nostr relays inside location-specific channels identified by geohash prefixes representing blocks, neighborhoods, or cities.

Each geographic channel operates as a separate Nostr kind event, allowing peers in the same physical area to discover each other across the distributed relay network. This design enables location-aware messaging where users receive relevant communications based on their physical presence while maintaining global reach through Nostr's decentralized infrastructure.

The Private-Envelope Event Format

Rather than reusing existing Nostr implementation possibilities (NIPs) such as NIP-44, BitChat defines a custom private-envelope format using event kind-1059. This envelope carries a BitChat-specific payload encrypted with XChaCha20-Poly1305, providing authenticated encryption for message contents.

The encoding logic resides in bitchat/Nostr/NostrEmbeddedBitChat.swift, specifically within the encodePMForNostr method:

let embedded = NostrEmbeddedBitChat.encodePMForNostr(
    content: "Hello world",
    messageID: UUID().uuidString,
    recipientPeerID: peerID,
    senderPeerID: senderPeerID
)!

This approach ensures that only BitChat clients can decode the encrypted payloads, creating a secure messaging layer on top of the public Nostr relay network.

Transport Selection and Fallback Logic

BitChat implements intelligent transport selection in bitchat/Services/NostrTransport.swift. When a user sends a private message, the system first attempts delivery via the local Bluetooth mesh. If the recipient is unreachable locally, the transport layer automatically falls back to Nostr relay publication.

The fallback process involves several key steps implemented in NostrTransport:

1. Resolve the recipient's Nostr public key (npub) and convert it to hex format:

private func resolveRecipientNpub(for peerID: PeerID) -> String? {
    if let noiseKey = Data(hexString: peerID.id),
       let fav = dependencies.favoriteStatusForNoiseKey(noiseKey),
       let npub = fav.peerNostrPublicKey {
        return npub
    }
    if peerID.id.count == 16,
       let fav = dependencies.favoriteStatusForPeerID(peerID),
       let npub = fav.peerNostrPublicKey {
        return npub
    }
    return nil
}

2. Publish the encrypted envelope via the relay manager using dependencies.sendEvent(event), where the event is created by NostrProtocol.createPrivateMessage.

This dual-transport architecture ensures messages reach their destination whether recipients are nearby (via Bluetooth) or anywhere in the world with internet access (via Nostr).

Reliability and Rate Limiting

To maintain high delivery reliability while respecting Nostr relay constraints, BitChat implements acknowledgment pacing through the AckPacer class. Acknowledgments—including read receipts and delivery confirmations—are queued and paced to avoid triggering relay rate limits.

As implemented in NostrTransport.swift lines 84-92:

dependencies.ackPacer.enqueue {
    // send ACK as a private-envelope Nostr event
}

This mechanism ensures that delivery confirmations flow back to senders reliably without overwhelming the volunteer-operated relay infrastructure.

Privacy Enhancements with Tor Integration

BitChat provides optional Tor routing for users requiring additional privacy protections. As documented in docs/TOR-INTEGRATION.md, all outbound Nostr traffic can be forced through TorURLSession, routing communications through the Tor network's onion routing system.

This integration allows users in restrictive network environments to access Nostr relays anonymously, preventing traffic analysis and bypassing censorship while maintaining the same global reach capabilities.

Summary

• Geohash channels enable location-aware message routing through Nostr relays by organizing communications into geographic zones.
• Kind-1059 envelopes provide application-specific encryption using XChaCha20-Poly1305, ensuring only BitChat clients can read message contents.
• Dual-transport logic in NostrTransport.swift prioritizes Bluetooth mesh locally while falling back to Nostr relays for global reach.
• AckPacer implementation prevents relay rate limiting by pacing acknowledgment events.
• Optional Tor support allows users to route all Nostr traffic through the Tor network for enhanced privacy.

Frequently Asked Questions

How does BitChat route messages when Bluetooth peers are unavailable?

When the Bluetooth mesh cannot reach a recipient, BitChat falls back to the Nostr protocol. The NostrTransport class resolves the recipient's public key (npub), converts it to hexadecimal format, and publishes an encrypted event to Nostr relays. Any device with internet access can then retrieve the message from the relay network.

What encryption standard does BitChat use for Nostr messages?

BitChat uses XChaCha20-Poly1305 authenticated encryption within a custom private-envelope format. Unlike standard Nostr direct messages that might use NIP-44, BitChat defines its own kind-1059 event type implemented in NostrEmbeddedBitChat.swift to ensure compatibility with its specific cryptographic requirements.

How does BitChat prevent overwhelming Nostr relays with status updates?

The application implements an AckPacer class that queues acknowledgment events—including read receipts and delivery confirmations—and releases them at a controlled rate. This pacing mechanism prevents BitChat clients from hitting relay rate limits while still providing reliable delivery feedback to users.

Can BitChat operate entirely over Tor without revealing IP addresses?

Yes, BitChat supports optional Tor integration through TorURLSession. When enabled, all Nostr relay connections route through the Tor network, concealing the user's IP address from relay operators and protecting against network-level surveillance or blocking attempts.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}