Fernweh brings private messaging beyond internet coverage

I got lost at an event and was able to communicate with my boyfriend through this app! Thank you!

App Store review, September 1, 2026¹

The conversation belongs on the device

Encrypted SQLite holds Fernweh's local conversation history. Sending first creates a durable local message; receiving commits into the existing thread. Delivery and read receipts can advance independently of the message body. An internet relay extends reach by forwarding ciphertext, but it does not become the authoritative inbox.

The Offline Protocol Mesh SDK³ supplies the underlying discovery and delivery runtime. Its automatic transport selection solution, the Dynamic Offline Relay Switch (DORS), selects an available qualified nearby or internet path. A message arriving over more than one path retains the same identifier, so reconnection updates the conversation instead of duplicating it.

This architecture changes the visible experience. A person can open a previous conversation while a new message remains pending. Nearby participants can exchange messages without waiting for the internet. If no supported path exists, the sender retains the message and its unresolved delivery state. A locally stored bubble never stands in for a recipient's receipt.

Meeting nearby does not mean accepting every message

Fernweh supports nearby Bluetooth discovery, invitations, QR exchange, contact matching, and searchable OfflineIDs. Each leads to an explicit connection request. Discoverability and permission remain separate decisions.

OfflineID⁶ supplies a memorable identity around device-backed proof. In the shipped V2 identity profile, an Ed25519 public key derives a SHA-256/Base58 peer identifier; signed identity material can be verified locally. The private key remains on the phone. The directory resolves a human-readable username, while an already established nearby connection does not depend on another directory round trip.

Messaging Layer Security (MLS)⁷ protects conversation traffic. Identity verification establishes control of a key; it does not decide whether its holder is welcome. Connection acceptance, blocking, rate limits, and membership checks remain product controls. Reputation gives a recipient context rather than silently overriding that choice.

Search stays beside the history

Fernweh's FTS5 index lives inside its encrypted local database. A query resolves matching message IDs back to the conversation store, so opening a result returns the existing message and thread. Message inserts, edits, and deletions update the index; older history backfills in resumable chunks. Locked-chat results remain concealed until authentication succeeds. Search therefore follows the same on-device access boundary as the history it retrieves.

This is an everyday benefit of the architecture: retrieval uses data the phone already holds. Searching a globally registered username still reaches the directory because that task needs information the phone may not have.

Calls have a different requirement. LiveKit carries internet-dependent voice and video. Fernweh creates a fresh 256-bit call key on the device and wraps it separately for invited devices through established secure sessions. If the key cannot be delivered securely, the application does not fall back to plaintext. Asynchronous message retention is never presented as continuous offline calling.

The implementation behind the experience

The runtime composition includes offline-protocol, offline-protocol-core, offline-protocol-transport, offline-protocol-router, offline-protocol-reliability, and offline-protocol-mls. Native bindings through offline-protocol-uniffi connect platform capabilities to the application. The deployed SDK and identity format are pinned together; changing the address format requires a deliberate migration.

The application owns its encrypted database, message IDs, outbox, and receipt transitions. Receiver deduplication and message insertion share a transaction. Attachments retain their own completion state, so a received message does not falsely promise that its media has finished downloading.

What changed for people using Fernweh

People now have a usable conversation even while a message is waiting for a route. They can reopen history, find an earlier message, and continue a nearby exchange inside the same application. Recipient receipts distinguish a stored message from one that another person has received. The published event review gives that architecture a human outcome: two people were able to reconnect when they needed to find each other.

Release validation follows the same user-visible boundaries:

Managed services and expansion

Fernweh's next service layer grows out of the same moment that makes nearby messaging useful: people arriving somewhere together and needing to communicate. Travel groups and temporary event communities can reuse the application's conversations, invitations, and device identity, with services added around the group experience.

Reach and delivery support. Hosted Relay extends encrypted message delivery beyond nearby peers when an internet path is available. A managed Telemetry integration⁸ can help the product team diagnose failed routes and aging delivery queues across application releases. The application selects and buffers permitted diagnostic events; message bodies, search queries, and contact lists stay outside that stream. Local messaging does not wait for diagnostic ingestion.

Services inside the community. Capability Exchange can expose an organizer's help desk, cached event schedule, or a travel host's local information through authenticated discovery and invocation.⁹ People choose the service and approve the interaction. An organizer gains a service channel that remains useful on site, while Fernweh retains control of the conversation experience.

Optional attendance verification. Proof of Location¹⁰ adds a separate, consented way to verify presence during an event window without disclosing a continuous journey. It is useful for an attendance benefit or venue service, with witness and freshness requirements defined for that event. These extensions create room for organizer and travel-partner offerings combining private group communication, hosted reach, operational support, and selected service access.