Fernweh V2 is live: a private messenger for the network you actually have

TL;DR

Fernweh V2, a private messenger on DORS, OfflineID and MLS, keeps one conversation across Bluetooth, Wi-Fi and an encrypted relay. It adds group chats, rich media, on-device search and encrypted calls, and no server owns identity, history, message index and call keys at once.

Most messengers are designed around one assumption: the server is reachable. The interface may cache a draft or show an offline badge, but discovery, identity, delivery, and reconciliation still stop at the edge of the network. Fernweh began with a different premise: the internet should be a capability, not a prerequisite.

Today, Fernweh V2 is live. What began as Bluetooth mesh messaging is now a complete private messenger that works across local and internet paths. Every installation remains a node in the Offline Protocol network, while the product above that network has been rebuilt around the things people expect every day: direct and group conversations, rich media, private search, verifiable identity, reputation, and end-to-end encrypted voice and video calls. V2 is not a conventional messenger with a separate offline mode. It is one conversation model operating across changing network conditions. Fernweh can use nearby Bluetooth and Wi-Fi paths when they exist, extend delivery through an encrypted internet relay when it is available, retain work on the device when no path is usable, and reconcile without turning one message into several copies. The sender should not have to understand the route. They should be able to send once and trust the application to preserve the conversation.

Fernweh V2 architecture on the Offline Protocol stack

Fernweh V2 runs on the same Offline Protocol foundation that has grown to more than 350,000 devices across 80 countries: the Dynamic Offline Relay Switch (DORS) for multi-transport delivery, OfflineID for locally verifiable peer identity, and Messaging Layer Security (MLS) for encrypted sessions. Around those protocol layers, V2 adds local state, private retrieval, account discovery, reputation, and real-time media without making any one server the authority for the entire product.

Layer	Fernweh V2 component	Local trust boundary	Role of online infrastructure
Delivery	DORS across nearby and internet paths	Queue, retry, route selection, acknowledgments, and deduplication remain with the endpoints	Relays extend reach by carrying encrypted traffic
Identity	Device-generated Ed25519 identity plus OfflineID	The private key remains on-device; peers verify signed identity material locally	The directory binds a memorable username to a proved device identifier
Messaging	MLS sessions and encrypted local conversation state	Message content, session keys, history, and attachment encryption remain endpoint-controlled	Push and relay services move ciphertext and availability signals
Search and reputation	Encrypted SQLite, FTS5, and contextual reputation signals	Message indexing and message-body search happen on the device	Global username lookup and shared reputation inputs require limited shared services
Calls	LiveKit media with Fernweh call signaling	A fresh call key is created on-device and delivered through an existing secure session	Signaling locates participants; media infrastructure carries encrypted real-time streams

This separation is the point. Servers still do useful work, but each one gets a narrow job. A relay moves encrypted bytes. A directory resolves a readable name. A signaling service helps endpoints join the same media session. None of those jobs requires one service to own the user’s identity, conversation history, message index, and call keys at once.

One conversation across multiple network paths

Fernweh uses its encrypted local database as the source of truth for each conversation. If the same encrypted message arrives over a nearby path and an internet path, it is deduplicated. The hard problem was not putting multiple transports behind one send button. It was making them behave like one coherent messenger. When queued traffic reconnects, state reconciles into the existing thread instead of creating a second history. Delivery and read state can advance without making a relay the canonical inbox, and push notifications carry ciphertext rather than readable message content.

That model now supports direct and group conversations with replies, reactions, edits, forwarding, deletion, pinned messages, read receipts, typing indicators, and scheduled delivery. People can exchange photos, videos, voice notes, documents, stickers, GIFs, and locations; organize chats into folders; customize themes and wallpapers; and protect the whole application or individual conversations with biometric locks. These are familiar product details, but implementing them on an unreliable network forces a sharper contract: a feature must either continue locally, queue safely, or expose an honest dependency. It cannot silently pretend that a missing network still exists.

The product contract remains simple: send once, read once, deliver once, whether the bytes crossed a nearby link, several peers, an internet relay, or more than one of those paths before the state converged.

Nearby discovery and verifiable identity

Fernweh V2 supports nearby discovery over Bluetooth, privacy-conscious contact matching, and QR or shareable invitations alongside searchable OfflineIDs. A resilient messenger cannot begin and end with “enter a username and ask the directory.” People meet while standing near one another, through existing contacts, or by exchanging an invitation in person. Each path leads to an explicit connection request so discoverability does not automatically become permission to send unsolicited messages.

Underneath the friendly name, Fernweh V2 creates an Ed25519 identity key on the device. The SDK version shipped in the current application derives a deterministic peer identifier from the public key using SHA-256 and Base58, signs the Bluetooth identity advertisement, and lets another device verify that proof locally. The private key does not need to leave the device, and nearby verification does not depend on a live certificate-authority round trip. Ed25519 provides the peer identity proof, while MLS provides message confidentiality and participant authentication inside conversations; the two are complementary rather than duplicate security layers.

OfflineID gives that cryptographic identity a name a person can remember. The shared directory can bind a username to proved device material, while the peer-to-peer layer continues to use the verified device identity underneath. Human-readable identity and cryptographic identity have different jobs; keeping them separate makes impersonation harder and gives Fernweh a cleaner path toward multiple devices per person.

Cryptography can prove control of a key, but it cannot prove that the person controlling it will behave well. V2 therefore treats reputation as context rather than a verdict. Account age, verified connections, referrals, real interaction diversity, ecosystem participation, recency, and optional proofs can contribute with caps and diminishing returns instead of allowing raw activity volume to become unlimited trust. Reputation helps a recipient evaluate a request; it does not silently override their decision. Hard boundaries remain explicit through rate limits, signed identity material, connection acceptance, abuse controls, and blocking.

Private on-device message search

Fernweh message search does not upload conversations to a server. Message bodies do not need to leave the phone, because Fernweh V2 rebuilds search around the location of the data. Conversation names and known people can be matched locally. OfflineID lookup reaches the directory because global name discovery requires shared knowledge.

The application maintains SQLite FTS5 indexes inside the encrypted local database, with separate coverage for direct and group messages and triggers that follow inserts, edits, and deletions. People can search inside one conversation or across their history, filter results, and open the exact matching message. Locked-chat results remain concealed until biometric authentication succeeds. Existing history is indexed in resumable chunks so a large database does not freeze startup: new messages become searchable immediately, older history backfills between interface work, and a completion marker prevents the same migration from running on every launch.

The result is global message search for the user without a global message index for the service. It is fast because the index sits beside the encrypted history, and private because the search engine is the device already trusted to display that history.

Encrypted voice and video calls

Live calls require an internet path, while messaging can survive without one, and the call key is created on the caller’s device rather than by the infrastructure. Live media has different physical requirements from asynchronous messaging. Nearby devices can store, carry, and forward messages through an outage; they cannot honestly promise the continuous bandwidth and latency of a voice or video call.

When that path exists, V2 adds one-to-one and group audio and video calling with LiveKit for real-time media and a deliberately small signaling layer. The service can locate an account and help participants reach the same room, but sensitive call material is encrypted for the recipient through Fernweh’s existing secure device session. A fresh 256-bit key is created on the caller’s device for each call and used to protect the media end to end. For a group call, the room key is wrapped separately for each invited device; if a secure session is not ready, Fernweh does not fall back to sending the key in plaintext.

The operational details matter as much as the cryptographic diagram. Fernweh can select among media regions by latency, use adaptive streaming to reduce work for small or hidden video surfaces, stop publishing layers no participant is consuming, and prioritize active speakers rather than forcing a phone to decode every available stream. Signaling state remains short-lived and deliberately narrow. The infrastructure helps the call happen, but it does not become the permanent owner of the people, the conversation, or the key.

Fernweh V1 vs V2

Fernweh V1 proved that a phone-native mesh could grow through a real consumer application. V2 turns that proof into a messenger people can use for ordinary conversations, not only for the moment connectivity disappears. The visible release is larger and more familiar; the deeper change is architectural. Transport can change without splitting the conversation. Device identity can be verified nearby. Reputation can add context without becoming automatic censorship. Search can span a user’s history without uploading that history. Calls can use internet infrastructure without giving that infrastructure the media key.

Fernweh V2 is the messenger we wanted for ourselves: private, complete, and built to keep the conversation moving when the network cannot. Download Fernweh V2.