Skip to main content
Offline Protocol is designed to feel simple and intuitive, even though it operates on complex decentralized systems. It provides a way to communicate and share data in completely offline scenarios using WiFi-Direct and BLE Mesh, while ensuring security, privacy, and resilience.

​
Onboarding Flow

When a user joins the Offline Protocol network, the following steps ensure a smooth, secure onboarding:
  • Offline Usernames
    Each user is assigned a universal identifier (Offline ID), which is consistent across the ecosystem.
    Example: alice@offline.
  • Key Pair Generation
    A public/private key pair is generated and tied to the username.
    • Public Key → Shared with others for discovery & communication.
    • Private Key → Stored securely on the user’s device, never transmitted.
  • Permissions
    To join the mesh, the user explicitly grants access for the device to connect via WiFi-Direct and Bluetooth LE.
    This ensures user control and prevents unauthorized participation.

​
Interaction Types

Offline Protocol supports multiple communication modes depending on the context:
  1. 1:1 Sharing (Existing Link)
    • Best case scenario: sender already has the recipient’s Offline ID.
    • Connection is direct, fast, and reliable using available mesh links.
  2. 1:1 Sharing (New Discovery)
    • If recipient is not directly reachable, the message hops across nearby nodes until the target is found.
    • Ensures delivery even in fragmented networks (store-and-forward model).
  3. Broadcast Messaging
    • Messages are sent to all nearby nodes.
    • Useful for announcements, alerts, or group discovery.
    • Controlled to avoid misuse.

​
Broadcast Safeguards

To protect the mesh from spam and misuse, Offline Protocol includes built-in safeguards:
  • Reputation System
    • Nodes accumulate trust scores over time.
    • High-reputation users can broadcast farther, while new/low-trust nodes have limited reach.
  • Message Prioritization
    • Critical/emergency broadcasts (e.g., SOS alerts) are prioritized at the protocol level.
    • Non-urgent messages are queued behind urgent ones.
  • Cooldowns
    • Enforces time gaps between broadcasts to prevent flooding.
    • Example: A node can only broadcast once every 30 seconds, unless flagged as emergency.

​
Example Use Cases

Disaster Zones

Share SOS alerts when cellular networks are down.

Events & Gatherings

Discover and connect with nearby participants.

Peer-to-Peer Sharing

Transfer files or messages without the internet.

Remote Communities

Enable communication in rural or remote areas with limited connectivity.
⌘I