DOOTIKA – Stay Connected, Even When the World Goes Offline

Inspiration

Communication is essential, especially during emergencies. However, traditional messaging applications depend heavily on mobile networks or internet connectivity. During natural disasters, network outages, remote-area operations, or infrastructure failures, people can suddenly lose the ability to communicate.

This inspired us to create Dootika, an offline-first mobile communication application that enables nearby smartphones to communicate directly without depending on cellular networks or internet access.

Our vision is simple: communication should not stop just because the network does.

What We Built

Dootika is designed around decentralized, multi-hop mesh communication using Bluetooth Low Energy (BLE) and Wi-Fi peer-to-peer technologies.

When two users are nearby, they can exchange messages directly. When the intended recipient is outside the sender's range, other participating devices can act as relay nodes and forward messages towards the destination.

Its key capabilities include:

Direct Communication: Exchange messages between nearby devices without internet access.

Multi-Hop Messaging: Forward messages through participating devices to reach users beyond direct communication range.

Store-and-Forward: Temporarily store messages and forward them when a suitable connection becomes available.

Secure Messaging: Use end-to-end encryption so relay devices cannot read message contents.

Offline-First Design: Keep essential communication features independent of cloud servers and cellular infrastructure.

Dootika is designed to use available local radio connections. It cannot overcome physical radio jamming if Bluetooth and Wi-Fi signals are also blocked.

How We Approached Building It

We planned a mobile-first architecture using Flutter for the application interface and native platform integrations for device-to-device communication.

The proposed architecture consists of:

User Interface: A clean, modern messaging experience with contacts, conversations, connection status, and message delivery indicators.

Device Discovery: BLE advertising and scanning to discover nearby participating devices.

Peer-to-Peer Communication: Wi-Fi Direct or Wi-Fi Aware on supported Android devices, with platform-specific alternatives for iOS.

Mesh Routing: Message identifiers, duplicate detection, hop limits, acknowledgements, and controlled forwarding to prevent endless message loops.

Security Layer: Public-key-based key exchange, authenticated encryption, and secure key storage.

Local Storage: An on-device database for conversations, message queues, delivery states, and temporarily stored messages.

Our approach prioritizes reliability, privacy, practical battery consumption, and compatibility with real mobile operating-system restrictions.

What We Learned

Working on Dootika helped us understand that building a communication application involves much more than creating a messaging interface.

We explored:

Wireless communication using Bluetooth and Wi-Fi technologies.

Decentralized systems and multi-hop mesh networking.

Routing algorithms and store-and-forward communication.

End-to-end encryption and secure device identities.

Mobile operating-system restrictions and background execution.

Battery optimization, message reliability, and network performance.

Designing applications that remain useful without an internet connection.

One important lesson was that a technically possible feature is not automatically practical on every smartphone. Platform limitations must be considered from the beginning.

Challenges We Faced

Some of the most important challenges in designing Dootika were:

Device Compatibility: Android and iOS provide different levels of support for Bluetooth discovery and peer-to-peer networking. We needed a platform-specific networking layer rather than assuming identical capabilities.
Multi-Hop Routing: Forwarding messages through multiple devices introduces duplicate packets, routing loops, congestion, and delivery uncertainty. Message IDs, hop limits, acknowledgements, and controlled forwarding are essential.
Background Connectivity: Mobile operating systems restrict background Bluetooth activity to conserve battery and protect user privacy. Designing reliable communication within these restrictions is challenging.
Security and Privacy: Relay devices must forward messages without accessing their contents. This requires carefully designed encryption, identity verification, and replay protection.
Battery and Performance: Continuous device discovery and communication can consume significant battery power. Our design therefore considers adaptive scanning, controlled advertising, and connection management.

Our Vision

We envision Dootika as a communication network powered by people rather than traditional network infrastructure.

Potential applications include disaster response, remote communities, crowded events, outdoor activities, and situations where conventional connectivity becomes unavailable.

Our long-term goal is to make resilient, private, device-to-device communication accessible through everyday smartphones.

DOOTIKA — Because staying connected should never depend on being online.