> ## Documentation Index
> Fetch the complete documentation index at: https://www.offlineprotocol.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# User Experience

> Discover how Offline Protocol ensures a seamless, secure, and user-friendly experience.

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

<Columns cols={2}>
  <Card title="Disaster Zones" icon="wind">
    Share SOS alerts when cellular networks are down.
  </Card>

  <Card title="Events & Gatherings" icon="users">
    Discover and connect with nearby participants.
  </Card>

  <Card title="Peer-to-Peer Sharing" icon="share">
    Transfer files or messages without the internet.
  </Card>

  <Card title="Remote Communities" icon="globe">
    Enable communication in rural or remote areas with limited connectivity.
  </Card>
</Columns>