ToolsEdits
    All tools
    Web Demo Mode

    Private communication without central infrastructure

    MeshChat offline mesh messenger

    Explore how encrypted messages can move through nearby participating phones, wait safely when a route disappears, and deliver when the destination returns.

    Honest capability boundary

    This browser tool simulates discovery, routing, queueing, and delivery. Real Bluetooth/Wi-Fi mesh radio requires the separate native Android implementation described below. It does not promise a direct 10 km connection.

    Interactive simulator

    Test a four-node mesh route

    5 virtual peers active
    S

    Sarah

    Reachable through 1 hop

    E2EE model
    Demo packets only · no Bluetooth or Wi-Fi radio is active

    The community point is open. The mesh route is stable.

    10:38 · 1 hop · Read

    Thanks — I can reach you without an Internet connection.

    10:42 · 1 hop · Delivered
    TTL 24 hours

    How it works

    Store, relay, recover

    A native MeshChat device discovers nearby compatible phones, selects a stable limited-hop route, and forwards an encrypted packet. Duplicate message IDs are discarded, loops are prevented with a hop limit, and unavailable destinations use an expiring local queue.

    01

    Discover

    BLE, Wi-Fi Direct, or Wi-Fi Aware finds compatible nearby devices.

    02

    Encrypt

    Use established authenticated encryption and hardware-backed keys where available.

    03

    Route

    Prefer stable peers, limited hops, duplicate detection, and route recovery.

    04

    Deliver

    Confirm delivery or retain the encrypted packet until its expiry time.

    User guide

    From identity to delivery

    The real Android workflow stays simple while advanced network details remain optional. No central account is required for the core offline mode.

    1. 1

      Create a local identity

      Choose a display name. MeshChat does not require a phone number, email, SIM, or account.

    2. 2

      Allow nearby access

      The native Android app will explain and request only the Bluetooth and nearby Wi-Fi permissions it needs.

    3. 3

      Find a contact

      Pair through a public-identity QR code, enter a Mesh ID, or discover a nearby compatible device.

    4. 4

      Send an encrypted message

      Your message is encrypted before it leaves the sending device. Relay nodes only handle encrypted packets.

    5. 5

      Let the mesh route it

      If there is no direct link, a limited-hop route forwards the packet through participating nearby phones.

    6. 6

      Deliver when reachable

      If the recipient disappears, the encrypted packet remains queued until a route returns or its expiry time passes.

    Android implementation plan

    Native radio layer

    The production Android app should use Kotlin, Jetpack Compose, a Room local database, Coroutines, Android Keystore, BLE, and device-dependent Wi-Fi Direct or Wi-Fi Aware. A foreground service should run only where Android permits it, with adaptive scans and exponential retry to protect battery life.

    Presentation: Compose UI and accessible state

    Domain: message lifecycle, routing, identity and policies

    Data: Room queues, peers, routes and delivery receipts

    Radio: capability-tested BLE and Wi-Fi adapters

    Requires Android native implementation

    Real nearby discovery, background radio operation, Android Keystore protection, Bluetooth connections, and Wi-Fi peer-to-peer transport cannot be delivered by this browser simulator. Device support and operating-system restrictions must be detected honestly at runtime.

    Security architecture

    • X25519 key agreement
    • Ed25519 identity signatures
    • AES-256-GCM or ChaCha20-Poly1305
    • Android Keystore private-key protection
    • No invented cryptography

    Reliability tests

    • Bluetooth-only and Wi-Fi Direct pairs
    • Three-phone and alternate routes
    • Receiver disappears and returns
    • Relay disconnect and route recovery
    • Duplicate and expired packet handling

    Battery policy

    • Adaptive discovery windows
    • Connection timeout
    • Exponential retry
    • Battery-aware relay participation
    • No excessive network flooding

    Frequently asked questions

    Can this browser demo send real Bluetooth messages?

    No. It is a working simulation of the interface, routing states, queue, and message lifecycle. Real radio communication requires the native Android layer.

    Does MeshChat guarantee a 10 km range?

    No. Normal Bluetooth and Wi-Fi links do not provide a guaranteed direct 10 km range. A longer logical path is possible only when enough participating devices form a usable multi-hop route.

    Can relay devices read a message?

    In the planned native architecture, messages are encrypted before transmission and relays handle encrypted packets. A compromised endpoint can still expose its local messages, so no system can promise absolute security.

    Does it need an account, SIM, or server?

    The planned core offline mode uses a local decentralized identity and does not require a phone number, email, SIM card, or mandatory cloud server.

    What happens when the recipient is unavailable?

    An encrypted message can remain in a local store-and-forward queue until a route returns or the configurable expiry period ends.