1. There is no account, so there is no account data

MeshLine.net doesn't ask for an email address, phone number, or password. When you join, a random display handle and a local cryptographic identity (a Nostr keypair) are generated in your browser. Neither is tied to any real-world identity, and nothing is asked of you to create one.

2. What lives on your device vs. our servers

Your chosen handle, local room bookmarks, and your view of message history are stored in your browser's IndexedDB, on your own device. Clearing your browser data or closing a private/incognito tab removes your local copy.

MeshLine.net also runs infrastructure on Cloudflare Workers and Durable Objects to coordinate the parts a pure browser-to-browser connection can't do alone: relaying presence and call-signaling messages, issuing short-lived TURN credentials for calls that can't connect directly, and — for public lobby messages and public channels specifically — storing that message content server-side so it can be delivered to peers who join later. Public messages are capped at a rolling history limit (oldest messages are automatically deleted once that cap is reached); we don't currently offer on-demand deletion of an individual public message before it ages out naturally.

Direct messages are different: they're end-to-end encrypted in your browser before they ever leave it, using keys only you and your recipient hold. Our infrastructure relays the encrypted bytes but cannot read their content.

Public media (images, videos, and other files you attach to public posts) are uploaded to third-party Blossom servers (BUD-01/02). Those servers receive and store the file as-is; they can see the file content, its SHA-256 hash, and your Nostr public key from the upload authorization event. If you want a file to remain private, send it in a direct message instead.

Direct message files are encrypted on your device with AES-256-GCM before upload. Only the encrypted ciphertext reaches Blossom — the server sees opaque random bytes and cannot determine the file type or content. The AES key and IV are wrapped inside the same NIP-44 end-to-end encryption that protects the DM text, so only the intended recipient can decrypt and download the file.

3. Automated content moderation

Before a public lobby or channel message is stored and delivered to other peers, it's screened by an automated moderation pipeline running on Cloudflare Workers AI — first a fast keyword/heuristic filter, then an AI model check for content that slips past it. This applies only to public messages; end-to-end encrypted direct messages are never sent to, or readable by, this pipeline. Messages that fail the check are rejected and not stored or delivered.

4. What peers can see about each other

Because calls connect browsers directly over WebRTC, the trade-off for that directness is that peers see more of each other than they would through a managed service:

• Your IP address is visible to any peer you call directly over WebRTC, the same way it would be on a direct video call. If a direct connection can't form, media is relayed through a Cloudflare TURN server instead, which hides your IP from the other peer but is visible to Cloudflare.
• Public room membership and presence (who's online, in which room) are visible to anyone else in that room, and — since presence is coordinated through our Durable Object infrastructure — to that infrastructure as well.
• Direct messages are sealed with end-to-end encryption before they leave your browser; the content is not readable by us, but the fact that two handles are exchanging messages is visible to the signaling layer that relays them.

5. Signaling infrastructure and Nostr

Peer discovery, presence, and call signaling are coordinated through Cloudflare Workers and Durable Objects that we operate — not through public BitTorrent/WebTorrent trackers. As with any Cloudflare-fronted service, Cloudflare's edge network sees the IP address of the connection your browser opens to it.

MeshLine.net also uses the Nostr protocol for identity: your display handle can optionally be bound to a Nostr public key (MeshID), and public channel messages you send may be additionally published as signed Nostr notes to public relays (e.g. relay.damus.io) so they're visible to other Nostr clients following the same tag — not merely as a fallback path, but as an intentional public-broadcast feature. Those relays are third-party infrastructure we don't control.

6. Age requirement

MeshLine.net requires users to confirm they are 18 or older before joining. This is self-reported at join time; we have no independent way to verify age given the absence of accounts, and we don't retain the value you enter beyond your local session.

7. Cookies and analytics

MeshLine.net does not use tracking cookies or third-party analytics scripts. Local storage is used only to persist your own session and preferences on your own device.

8. Changes to this policy

If this policy changes, the updated version will be posted on this page with a new "last updated" date. Since there are no accounts, we have no way to notify you individually.

9. Contact

Questions about this policy can be directed to the project maintainers through the repository listed in the footer of this site.