← Blog

April 17, 2026 · roadmap · 6 min read

Roadmap: what we are building next

Hoppr is v2.0. The dual-stack protocol is live on iOS, macOS is in alpha, and the Android direct-APK build is in beta. Forty-odd features landed in the last three months, from NIP-57 zaps and multi-device encrypted backup to on-device translation and the live mesh topology view. With the foundation in place, the next six months are focused on three directions: voice, hardware identity, and federation.

This post is the map. Everything below has code sketches or prototypes already; none of it is vapour. Dates are ranges, because we ship when it is green, not when it is Tuesday.

v2.2 · Voice rooms in geohash channels

Push-to-talk live audio, carried over Bluetooth mesh when peers are nearby and over Nostr fallback when they are not. Same dual-stack identifier scheme the rest of the protocol uses: kind 20200 for Hoppr-native audio, kind 20201 for presence during a voice session. Codec is Opus at 16 kbps VBR mono, the radio-style setting that keeps speech crisp and the bandwidth honest.

The use case is the reason: a protest coordination channel where someone needs to call out a police movement, a festival stage lineup update that has to reach the whole geohash at once, a citywide heads-up that text alone cannot carry fast enough. Text rooms stay the default; voice is a toggle on the same channel header.

v2.3 · Hardware key identity

Tap a YubiKey to the phone at first launch and the identity private key never leaves the token. Stealing the phone does not steal the user's identity. Extends the Noise XX handshake to delegate the static-key signature to the hardware token via libfido2. The rest of the session is unchanged.

This is optional, not required. The default identity still generates on-device, because a hardware dependency cannot be a precondition for using the app. Users who need a higher assurance level get it; users who do not, do not notice.

v2.4 · Voice and video calls via NIP-100

One-to-one and small-group calls. DTLS-SRTP with keys bootstrapped from the existing Noise session, so the media layer inherits whatever trust the chat layer already established. Signaling rides the same Nostr relays the app already uses, which means no central calling server and no vendor-specific STUN/TURN. The same panic wipe that erases the chat history erases call logs and transcripts; nothing leaves the device in the first place.

v2.5 · Federation with Matrix and Briar

Optional bridges, opt-in per user, not a product-wide default. Matrix gets a bidirectional room bridge for users who keep a Matrix identity on the side. Briar gets mutual routing so Briar's Tor-based DMs reach Hoppr's Nostr-over-Tor fallback transparently. A Hoppr user messages a Briar user and the bytes land in the right place.

These bridges run as user-hostable open-source daemons, not as a service Hoppr operates. We do not want to be in the middle of anyone's conversations. If you need federation, you run the bridge; if you do not, you ignore the setting and nothing changes.

v3.0 · Rust core with UniFFI bindings

Extract the protocol layer, BLE framing, Noise, Nostr wire, GCS sync, into a single Rust crate. Swift on iOS and macOS, Kotlin on Android, both consume the same binary via UniFFI. Eliminates one entire class of divergence bugs where the two implementations drift in subtle ways and a message encodes differently on each side of a chat.

Android gets the same battle-tested Arti integration iOS has, for free, instead of waiting for a parallel Kotlin port. The installed binary shrinks further; we are targeting under 10 MB on iOS with the new core.

v3.1 and beyond · Platform breadth

Most feature UIs ship on Android as of v2.2, but the underlying wiring takes a beat longer. v3.1 is the version that brings Android to parity with iOS on the plumbing. A GTK Linux build lands in the same release. A Windows signed MSIX installer by the end of 2026.

What we will not ship

Every roadmap should be honest about absences. Here are ours.

No cloud backup. The encrypted QR-based multi-device flow already covers the legitimate use case. Adding a cloud backup introduces a server we would be pressured to provide content access to, and there is no technical way to honour that pressure while also being end-to-end encrypted. We are not setting that trap.

No read receipts on geohash public rooms. Private chats already have opt-in read receipts. A public room that tells you who read a message is a surveillance tool for anyone watching the room, and Hoppr's users include people who cannot afford to be the someone who was seen reading.

No "Pro" subscription. The app is free. If we need to monetize, it is through server-optional hosted relays for enterprises, not through a paywall in front of the user's own messages.

No ads. Not now, not after the acquisition, not ever.

Closing

Half a year is as far ahead as we plan. Beyond that, Hoppr should be boring enough that the roadmap post stops being interesting. The excitement should move to what the users are doing with it.

Published by the Hoppr team. Mirrored as a NIP-23 long-form event (kind 30023) on the Hoppr publication key. Questions: hello@hoppr.chat.