> ## 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.

> ## Agent Instructions
> These docs target Mesh SDK v0.27.0. Match the installed package and binding before generating code. Start at /getting-started/agents for task-specific reading paths.
> Call the company and product Offline Protocol, never Offline alone. Current packages: @offline-protocol/mesh-sdk 0.27.0 (React Native), @offline-protocol/id-react 0.2.0, @offline-protocol/id-react-native 0.3.3, @offline-protocol/pol 0.1.2 and @offline-protocol/cli 0.2.6. Canonical docs URLs start with https://www.offlineprotocol.com/docs.
> The Mesh SDK runs in a native app or gateway. A browser OfflineID SDK integration does not provide browser mesh transport. Local mesh operation does not require a portal API key.
> Service RPC is signed plaintext in v0.27.0. Message delivery, durable local acceptance and backend commit are distinct outcomes. Use the workflow guide for the required application logic.
> Offline Protocol CLI 0.2.6 is on npm (@offline-protocol/cli, command offline). Its local MCP server runs with offline mcp serve and requires no login or key. Hosted MCP is at https://mcp.offlineprotocol.com/mcp with an application API key in Authorization: Bearer and a matching x-app-id; organization keys are rejected. Follow /tools/overview for setup and do not invent commands beyond it. MCP provides integration context and planning, not mesh execution; file-writing tools are local only.
> Phone Wi-Fi Direct and MultipeerConnectivity carry no data in v0.27.0. Use BLE or a provisioned relay. The receiver core ACKs before application persistence; use application acceptance for durable workflows.
> Proof of Location is Sepolia testnet witness evidence, not zero-knowledge proof or proof of presence. The geohash is public onchain. Read /proof-of-location/security before integration.

# Data handling by service

> What each Offline Protocol hosted service and developer tool receives, stores and keeps, and who controls it.

Use this page to write your app's privacy notice and to fill in a data protection assessment. It describes how the services behave. The [privacy policy](https://www.offlineprotocol.com/privacy), [developer terms](https://www.offlineprotocol.com/legal/developer-terms) and [data processing addendum](https://www.offlineprotocol.com/legal/dpa) are the binding documents; if this page and those documents differ, those documents control.

## Roles

For end-user data that your app sends to hosted services, your organization is the controller and Offline Protocol is your processor under the data processing addendum. OfflineID is the exception: the core OfflineID account (email or phone, username, sign-in security) can be used across several apps, so Offline Protocol controls that account record and processes your app's records for you. Offline Protocol controls developer account, billing and service-log data.

Local peer-to-peer traffic over Bluetooth LE, Wi-Fi or other local transports never reaches Offline Protocol. The SDK opens no connection to Offline Protocol unless your app configures a hosted service.

## Hosted services

### OfflineID

| Data | Notes |
| - | - |
| Email address or phone number | Sign-in codes expire after 10 minutes. Phone codes are sent and checked by Twilio Verify. |
| Username and profile | Optional text, picture, social links and a location your app sets. Exact profile location is visible only to its owner and to connections the owner shares it with. |
| Connections | Each side's location sharing is off until that person turns it on. |
| Device address and push tokens | Optional `off1` address, push tokens with device model, OS and app version. |
| Per-app activity | Which apps the person signed in to and daily sign-in counts. Your portal analytics are built from these. |

Requesting deletion of an OfflineID account signs the person out on every device and starts a 30-day grace period; signing in during it cancels the deletion. When the grace period ends, the account is deleted together with its related records: profile details and connections, relay identity keys, group memberships and queued messages, uploaded media and profile pictures, Proof of Location commitment secrets and off-chain records, and the person's profile and events in Offline Protocol's product analytics (PostHog). When Offline Protocol deletes an account on request, it keeps a record of the deletion that holds only keyed hashes of the email address and usernames, for three years, to show it was carried out.

### Relay

The relay forwards MLS-encrypted message content it cannot decrypt. It sees sender and recipient addresses, usernames, group and message IDs, and message timing and size. It stores public identity keys, group membership and last-seen times. Undelivered messages are kept until delivered, for at most 7 days. If your app enables push notifications, notification details go through Firebase Cloud Messaging. The relay offers no anonymity or traffic-analysis resistance; see the [threat model](https://github.com/Offline-Protocol/offline-protocol-sdk/blob/v0.27.0/docs/security/threat-model.md).

### Telemetry

Telemetry is off until you enable it for the application in the portal and call `enableTelemetry` in your app. It measures how the mesh behaves: message delivery results, latency and hop counts, routing decisions and transport changes, relay role changes, neighbor counts, queue sizes and bytes per minute, per-session summaries, encryption session errors, and battery level and charging state. Each record carries the application ID, app version, operating system and major version, a country code and a session identifier. It never carries message content, message IDs, contacts, names, usernames, email addresses, phone numbers, advertising identifiers, or location more precise than the country. Peer, user and group identifiers are hashed on the device and are not stored.

Session identifiers are random and rotate when the app goes to the background. A device identifier is sent only if you set `includeDeviceId`. The service hashes both again with a key that rotates every quarter, does not read the client IP address, and takes the country from its network provider's request header.

| Telemetry data | Kept for |
| - | - |
| Raw events | 30 days |
| Per-minute series | 48 hours |
| Live event feed | 2 hours |
| Daily totals per application | Life of the application |
| Daily breakdowns by OS and country | 2 years |

Your plan limits how far back the portal shows analytics (7, 30 or 90 days, or longer by agreement). That limit does not delete older data.

Offline Protocol also builds aggregated, de-identified statistics across applications, grouped by day, region, operating system and transport. They contain counts, sums and percentiles only, carry no application or customer identifiers, and a group is kept only if it covers at least 100 distinct devices or app sessions. Smaller groups are discarded. The [developer terms](https://www.offlineprotocol.com/legal/developer-terms#customer-data) and the privacy policy's section on aggregated data cover this.

### Proof of Location

Proof of Location runs on the Ethereum Sepolia testnet. Your app sends the username, latitude, longitude and application ID. The service converts the coordinates to a geohash of about 5 km and does not store the raw coordinates. Witness operators receive the coordinates to check the claim.

A random task ID, the geohash, the block time and a commitment (`keccak256(username, geoHash, nonce)` with a secret nonce) are written onchain. They are public and permanent. Offchain, the service keeps the username, task ID, commitment, transaction hash and nonce, and an index of each task with the centre point of its public geohash cell. Read [location evidence security](/docs/proof-of-location/security) and obtain informed consent before you submit a location.

## Developer tools

| Tool | What it sends and stores |
| - | - |
| Developer portal | Account email, organization and application settings, members and roles, API keys (stored as hashes and shown in full once), billing through Stripe. Uses a sign-in cookie and local storage; no product analytics or advertising scripts. Cloudflare Web Analytics counts page views without cookies. |
| CLI | `offline login` sends the computer's hostname as the device name and stores the API key and account IDs in `~/.offline/config.json`. No usage analytics or crash reports. `offline logout` deletes the file and revokes keys created for the CLI. |
| Local MCP server | `offline mcp serve` runs on your computer and sends nothing to Offline Protocol. |
| Hosted MCP server | Checks your application API key and `x-app-id`. Does not store or log request bodies, tool arguments or keys. Rate limits: 60 requests per minute per key and 600 per minute per network address. Do not send end-user data to it. |

## Deletion and export

An owner can delete an organization in **Settings**, **Advanced** once any outstanding balance is paid. Organizations on an Enterprise contract are closed through your account team. Deleting it cancels the paid subscription, bills any overage for the final billing period, and deactivates the organization and its applications and API keys immediately. Thirty days later its data is permanently deleted, except records Offline Protocol must keep for legal, tax, billing or security reasons.

You can delete your developer account in the portal after you transfer or delete each organization you own. The request signs you out everywhere and revokes the API keys created by CLI logins. Your account is deleted 30 days later, with the same exceptions; signing in before then cancels the deletion. To ask for any other deletion, email [legal@offlineprotocol.com](mailto:legal@offlineprotocol.com).

## Contact

Privacy requests and policy questions: [legal@offlineprotocol.com](mailto:legal@offlineprotocol.com). Security and vulnerability reports only: [security@offlineprotocol.com](mailto:security@offlineprotocol.com).