Skip to content

Privacy Policy

Last updated: July 17, 2026

This policy covers Orbitr (the software and this website). For Pulsar cloud services, see the Pulsar Terms of Service and Privacy Policy.

Orbitr is Self-Hosted

In Plain English When you run your own server, your data stays on your hardware. We have no access to it. There is no central server that sees your messages.

Orbitr is designed so that you run your own server. Your messages, voice conversations, files, and user data live on hardware you control. We have no access to your server, your database, or anything on it. There is no central message store: your conversations live on your server, never ours. The application does not currently include a telemetry pipeline or analytics SDK, and if we ever add operational logging or metrics, it would be opt-in and disclosed here before it took effect.

When you host an Orbitr server, you are the data controller, and that responsibility is not limited to your own data. Everything the people who join send to your server (their messages, voice, files, and profiles) lives on your hardware too, and you control it. You decide what data is stored, how long it is retained, and who has access. Hosting other people's data is a responsibility, and depending on where you and your members are located it may carry legal obligations; running a server means accepting that role.

Connecting to Someone Else's Server

In Plain English If you join a server you do not operate, the server owner can see everything you send: messages, files, metadata. This is like email: your app is private, but the server is controlled by its operator. Join servers run by people you trust.

When you join an Orbitr server operated by someone else, your data is stored on and processed by their server. The server operator has full access to messages, files, user profiles, and metadata stored on their server. Orbitr (the application) does not phone home or share data with us, but the server you connect to sees everything you send to it.

This is similar to how email works: your email client does not spy on you, but the email server operator could read your messages. Orbitr's maintainers have no control over, access to, or responsibility for data on third-party servers.

If you don't trust the operator, don't join. If privacy is critical, consider running your own server.

What a Server Records About Your Connection

In Plain English A server has to know who is connecting. When you connect, the server is what carries your messages and voice between you and everyone else, so it sees the IP address and browser/app (user agent) you connect from, and it keeps a record of that in its security logs. The operator uses this to run the place: to block abusive IPs, spot ban evasion, and review unusual connections. On a self-hosted server this is stored in readable form, because the operator is the person responsible for the server and needs to be able to read it. They control how long it is kept (90 days by default).

Connecting to a server is not anonymous to that server. By design, the server sits in the middle. It is what relays messages, voice, and files between members, so it necessarily sees the IP address you connect from and the user agent (browser or app build) you connect with. Like virtually every server on the internet, it records this connection metadata. On an Orbitr server, your IP address and user agent are recorded in the server's security and audit logs (which capture connection and other security-relevant events) and in your active session records.

This exists for the operator's security tooling, not for tracking. The IP address is what lets an operator block an abusive address, recognize someone evading a ban, and review where an unusual connection came from. These are the basic moderation and incident-response tools any server operator needs to keep their community safe.

On a self-hosted Orbitr server, this metadata is stored in readable (un-hashed) form. That is a deliberate choice: the operator of a self-hosted server is the data controller, and these security tools are only useful if the operator can actually read the values. An operator cannot manually block an IP they cannot see, or recognize a returning abuser from an unreadable hash. The operator also already has access to the raw IP addresses of everyone connecting (at the operating system or reverse-proxy layer), so storing them readably in the application does not expose anything the operator could not already see. Operators control how long this data is kept through their server's audit-retention setting (90 days by default). Session records are not governed by that setting; they are removed when the session expires or is signed out.

Pulsar, the optional central cloud service, handles connection metadata under its own policy. For how Pulsar treats this data, see the Pulsar Terms of Service and Privacy Policy.

The Orbitr Application

In Plain English The Orbitr app itself does not track you, phone home, or auto-collect analytics. It may keep diagnostic logs on your device, but nothing leaves your device automatically. The only data sent to us is a bug or crash report you explicitly choose to send: you approve each one before it goes to Pulsar, and can review the exact payload first. Nothing is transmitted without your approval. Otherwise the app talks only to the servers you connect to and, if you opt in, our own assets host for optional content such as extra emoji sets (see “Optional Content Downloads”). For anything sent to Pulsar, see the Pulsar Terms of Service and Privacy Policy.

The Orbitr application (web client, desktop app, mobile app) does not auto-collect analytics, telemetry, or usage data, and does not phone home. It may generate diagnostic logs locally on your device, but these are not collected or transmitted automatically. The only data it sends to us is reporting you explicitly trigger, such as a crash report or a bug report you choose to send. You explicitly approve each such submission before anything is sent, and you can review the exact payload first. It goes to Pulsar (see “Feedback & Feature Board” below), governed by the Pulsar Terms of Service and Privacy Policy. Aside from that, the app communicates only with the Orbitr servers you connect to and, if you opt in, our first-party assets host (assets.orbitr.chat) for optional content such as extra emoji sets (see “Optional Content Downloads”); nothing is sent to third-party analytics services.

The application uses browser localStorage and IndexedDB for local settings, cached data, and session state. This data stays on your device and is not sent to Orbitr maintainers or any third party. The Orbitr server you connect to receives only what is necessary to authenticate and sync, exactly like an email client talks to its email server.

The orbitr.chat Website

In Plain English The marketing pages are static: no cookies, no analytics, no tracking. The feedback and roadmap pages add an interactive board where you can sign in with your Pulsar account to post; anything you submit there is handled by Pulsar under its Terms of Service and Privacy Policy.

The orbitr.chat marketing pages are static. They do not use cookies, do not run analytics scripts, and do not collect any personal information. There are no tracking pixels, no third-party ad networks, and no fingerprinting. The site is served via a CDN, and standard web server access logs (IP address, user agent, timestamp) may be retained by the hosting provider for operational purposes, but we do not process or analyze them.

The feedback and roadmap pages are different: they include an interactive board, powered by Pulsar, where you can sign in with your Pulsar account to vote and post. Signing in redirects you to the Pulsar portal, and anything you submit (your account identity, feedback content, and votes) is sent to and stored by Pulsar, not by this site. This site keeps only a tab-scoped session token in your browser (no cookies), which is cleared when you close the tab. Data handling on these pages is governed by the Pulsar Terms of Service and Privacy Policy.

Download Counter

In Plain English We count how many times the app has been downloaded so we can show a total on the download page. The counter stores a scrambled, non-reversible code derived from your IP address for up to 48 hours (so refreshes and resumed downloads are not double-counted), then keeps only anonymous totals.

When you download an installer from our release host (get.orbitr.chat), we currently record the download in an aggregate counter. To avoid counting the same download twice, a keyed, non-reversible hash of your IP address (HMAC-SHA256 with a server-side secret) is stored for up to 48 hours and then deleted. The raw IP address is never stored by the counter. What we keep long-term is aggregate only: a per-platform, per-day download count with no per-user data. These aggregate totals are public (they appear on the download page and at get.orbitr.chat/stats.json). The counter runs on the same Cloudflare infrastructure as Pulsar; no third-party analytics service is involved.

Optional Content Downloads

In Plain English Optional content such as extra emoji sets is downloaded only if you ask for it. The app confirms first, then fetches it from our own server, not a third party. No content pack is downloaded unless you choose it.

To keep the app small, only the default (Twitter/Twemoji) emoji set is bundled. If you switch to another set (Apple, Google, or Facebook) in appearance settings, the app shows a confirmation naming the origin and, on your consent, downloads that set's images from our first-party assets host (assets.orbitr.chat) and caches them on your device for offline use. Like any request to our host, this makes your IP address and user agent visible to that server (and its Cloudflare infrastructure) for the duration of the one-time download; no third-party CDN is used, and we keep no per-user record of which set you picked, beyond the transient edge logs any web request generates. The style picker in appearance settings also loads one small preview image per non-default set from the same host, so you can see what a set looks like before downloading it. The default set is served from the app itself and involves no such request. Any other optional content packs we may offer this way in future, such as theme packs, follow the same rules: downloaded only on your explicit request, from our first-party assets host, with no per-user record kept.

What the Orbitr App Does Not Collect

In Plain English The app does not spy on you. It does not read your messages, record your voice, track your clicks, or fingerprint your device.

As of this writing, the Orbitr application does not collect:

  • Message content, chat history, or channel data (this lives on the server you connect to)
  • Voice or video data
  • Browsing behavior, click tracking, or usage analytics
  • Device fingerprints, hardware identifiers, or installed software lists
  • Contacts, friend lists, or social graphs
  • Keystroke data, clipboard contents, or screen recordings

If our data practices change in the future, this policy will be updated before any such change takes effect.

How Server Traffic Flows

In Plain English Orbitr servers run in one of two modes. In standalone mode, no third-party service sees your server: the operator shares an orbitr:// link directly and members connect straight to the server. In Pulsar mode, your server checks in with Pulsar so invite links keep working without manual sharing; the server's registration, heartbeats, the invites the operator publishes, and the server's public key are the only things that touch Pulsar, and for members it is just the moment an invite is redeemed. Either way, chat, voice, and file transfer always go directly between members and the server.

Orbitr servers operate in one of two privacy modes, chosen by the operator at setup. In both modes the actual conversation (chat, voice, and file transfer) always flows directly between members and the server. The modes differ only in how a member first finds and reaches the server.

Standalone Mode (Default)

In Plain English The most private option, and the default. Nothing about your server ever reaches a third party. The operator hands out the connection link themselves.

In standalone mode the server does not register with Pulsar. Pulsar sees nothing related to the server, and Cloudflare's network is not involved at all. The operator shares a copy-pasteable orbitr:// URI with members out-of-band, such as a private message, email, or QR code. Members paste it into their client, which connects directly to the server's IP address. Because there is no central registry, the operator is responsible for distributing the link and for sharing an updated one if the server's address changes.

Pulsar Mode (Optional)

In Plain English Adds convenience: invite links keep working on their own, even if the server's address changes. In exchange, the server checks in with Pulsar, and the moment someone redeems an invite briefly involves Pulsar.

In Pulsar mode the server registers with Pulsar and posts periodic heartbeats so that Pulsar can return the server's current IP address when someone redeems an invite. This is what lets invite links keep working without the operator re-sharing them. The server's traffic to Pulsar is limited to its registration (and deregistration), heartbeats, publishing or revoking the invites the operator chooses to share, and the server's public signing key. For members, the invite-redemption call is the only traffic that transits Pulsar and Cloudflare. After redemption, the member's client connects directly to the operator's IP address for everything else, exactly as in standalone mode. Pulsar's practices apply to that handshake. See the Pulsar Terms of Service and Privacy Policy; the latter's "How Invite Resolution Works" section has the full per-mode breakdown.

Content Reports (Moderation Data)

In Plain English When you report something on a server, that server stores who reported it, what was reported, the reason, and any note you add, so its moderators can review it. This stays on that server. If content is deleted, it is permanently removed and only a short, content-free record of the moderation action is kept.

When you report content, the server records who reported it, what was reported (a message, attachment, or member), the reason, and any note you add. The reporter is visible to that server's moderators so they can act on it, but is never shown to the reported user. This data stays on that server and is never sent to Orbitr's maintainers or any central service.

Operators control how long reports are kept (90 days by default), and resolved reports are purged on that schedule. Deleted content is removed permanently, leaving only a short, content-free record of the moderation action. For a report on a third-party server, contact that operator.

IP Certificates & Transparency Logs

In Plain English Orbitr servers get their HTTPS certificate from Let's Encrypt, often issued directly for the server's IP address. Let's Encrypt publishes every certificate to public Certificate Transparency logs, so the certificate for a server's IP is publicly recorded and can be linked to that IP. The logs do not reveal what is running on the IP, who operates it, that it is Orbitr, or anything about users.

Many Orbitr servers are reached by IP address rather than by a domain name. To enable HTTPS, the server obtains a TLS certificate from Let's Encrypt issued for its IP address. Let's Encrypt publishes every certificate it issues, including those issued for IP addresses, to public Certificate Transparency logs, an industry-wide mechanism that allows certificates to be independently audited and misissuance to be detected. Certificate Transparency is a property of the public web's certificate infrastructure and is not controlled by Orbitr.

Because the certificate is issued for the server's IP address, that address appears in the public log record. The entry discloses only that a certificate was issued for the address. It does not identify the software running on the server, indicate that the server is an Orbitr instance, identify the operator, or expose any information about its users, and no domain name is associated with the certificate.

For most operators this is not a concern. However, if your threat model requires that the server be difficult to discover, note that its IP address will appear in these public logs. To prevent this, the server can be operated behind a reverse proxy or content delivery network that terminates HTTPS on its behalf, so that the origin IP address is never issued its own publicly logged certificate. (Technical references: certificates for IP addresses are defined by RFC 8738; Certificate Transparency by RFCs 6962 and 9162.)

Pulsar Integration (Optional) Pulsar

In Plain English Some Orbitr features are powered by Pulsar. These are always optional and clearly labeled. When a feature involves Pulsar, the app marks it so you know.

Pulsar (pulsar.orbitr.chat) is a separate, optional cloud service. Pulsar is not required to use Orbitr. The Orbitr features that can use Pulsar are described in the sections below.

The Orbitr application integrates with Pulsar for certain optional features. Any feature that communicates with Pulsar is clearly identified in the interface with a Pulsar indicator, so you always know when data may be sent to an external service. No Pulsar feature is enabled by default; you opt in to each one individually.

If you use Pulsar features, your data is governed by the Pulsar Terms of Service and Privacy Policy, which detail what data is collected, how it is stored, and your rights.

Pulsar Pulse (Optional Cloud Identity Backup) Pulsar

In Plain English Pulsar Pulse is a paid Pulsar add-on (not part of Orbitr core) that backs up your encrypted identity to Pulsar and syncs it across your devices. Your identity is encrypted on your device before upload, so Pulsar cannot read it. Pulse is a Pulsar product, and what Pulsar stores and how it is handled are governed by Pulsar's terms and privacy policy. Orbitr works fully without it.

Pulsar Pulse is an optional, paid Pulsar product. Pulse is not part of Orbitr core, and you do not need it to use Orbitr. When you enable Pulse, your client encrypts your identity on-device and uploads only ciphertext to Pulsar, which cannot decrypt it. Orbitr's maintainers cannot access Pulse data.

Pulse is a Pulsar product, so what Pulsar stores (including the account and device information needed to sync across your devices), how long it is kept, and your rights are governed by the Pulsar Terms of Service and Privacy Policy.

Sponsorship & Donations (Optional) Pulsar

In Plain English If you choose to subscribe or donate to support the project, payments are processed by Stripe through Pulsar. We never see your card details. The Orbitr app surfaces a public list of opted-in supporters, but the data itself is fetched from Pulsar; no payment data touches your Orbitr server.

Orbitr's sponsorship and donation flow is operated entirely through Pulsar; the Orbitr application and the Orbitr server you run do not handle payment data at all. When you subscribe or donate, your card details go directly to Stripe. We retain only the Stripe customer / subscription / payment-intent IDs and amount totals (mirrored from Stripe webhooks into Pulsar's database). For full details see the Pulsar Terms of Service and Privacy Policy, and Stripe's privacy policy.

The Orbitr landing site and the Orbitr app's Settings → Support tab display a "supporter wall" of people who have explicitly opted in to public listing. The wall data is fetched live from pulsar.orbitr.chat; the wall display name is user-supplied and editable at any time. Default is off; nobody appears on the wall without explicit consent.

Feedback & Feature Board (Optional) Pulsar

In Plain English If you send a bug report or post or vote on the feature board, that goes to Pulsar, not to your Orbitr server. Posting and voting on the board require signing in with a Pulsar account. Bug logs are scrubbed of obvious personal data on your device before they are sent. We currently keep bug reports for 90 days and feature ideas until they ship or are declined. Some items appear on a public board, but bug reports are shared publicly only if you opt in.

Orbitr's feedback feature, bug reports and the feature-request voting board, is operated through Pulsar, not your Orbitr server. To post or vote on the board, you sign in with a Pulsar account. We collect the report title and body, optional category/severity/app version, optional scrubbed client logs and screenshots (bug reports only), and your feature votes. Bug logs are scrubbed of obvious personal data (emails, IPs, tokens) on your device before transmission and re-scrubbed on Pulsar's side; logs and attachments are visible only to admins and never appear on the public board.

Feature requests and opted-in bug reports may appear on a public feedback board (including on this landing site), which exposes only the reference code, title, body, kind, category, tags, version, status, vote count, and creation time, never your email, logs, or attachments. We currently retain bug reports for 90 days and retain feature items until they are shipped or declined. Posting and voting are gated by your Pulsar account; the one anonymous exception — the optional pre-boot crash reporter — uses Cloudflare Turnstile for bot detection (which sends your IP and a challenge token to Cloudflare). For full details and your rights over this data, see the Pulsar Terms of Service and Privacy Policy.

Your Rights

In Plain English If you run your own server, you control everything. If you use Pulsar, see the Pulsar Terms of Service and Privacy Policy for your data rights.

For self-hosted servers, you have full control over your data. You can export, back up, or delete your database at any time.

Depending on your jurisdiction, you may have additional rights under privacy regulations (GDPR, CCPA, etc.), including the right to access, correct, delete, or port your personal data, and the right to lodge a complaint with a supervisory authority. For data held by Pulsar, see the Pulsar Terms of Service and Privacy Policy. For data on a third-party Orbitr server, contact the server operator.

Your Members' Rights (If You Operate a Server)

In Plain English If you run a server, the people who join you are trusting you with their data, so their privacy rights are now partly your responsibility. When a member asks you to delete their data, you should honor it, and the tools to do that are built into Orbitr.

Because you are the data controller for everyone on your server, you may have a legal obligation under privacy regulations (GDPR, CCPA, and similar) to act on your members' access and deletion requests. Orbitr is designed so you do not have to fulfill these requests by hand:

  • Members can delete their own data. Every member can remove their own account, with a grace period to reconsider, or delete the data they have contributed to a specific orbit, without needing to go through you.
  • Operators can remove a member's account. From the server admin tools you can archive or permanently delete a user account, which is useful when you receive a request you are obligated to fulfill on a member's behalf.
  • Deletions remove the associated files. Removing a message or an account also releases its attachments from storage, so a deletion is not left half-finished.

We treat the ability to honor these requests as a core part of the software, not an add-on. If you receive a request you are unsure how to handle, the responsibility for responding rests with you as the operator, but the technical means to act on it ships in the box.

Changes to This Policy

We may update this policy as the software evolves. The "Last updated" date at the top reflects the most recent revision.

Contact

For privacy questions, data requests, or concerns, contact us at: