Privacy Policy

Local-network content is not stored

When you transfer files or exchange text between devices on the same network, no account is needed and Relayium does not store the content. The signaling service temporarily handles connection metadata such as IP addresses, room membership, device names, presence, capabilities, and WebRTC negotiation so the devices can connect directly.

What an account stores (only if you sign in)

Same-network (LAN) sessions need no account. To create a cross-network pairing code for a browser or CLI session, the code creator must sign in; the person joining with that code does not need an account. Creating a stored download link also requires signing in. If you sign in, we store the minimum needed to run an account:

• Your email address and a display name.
• Which sign-in method you used (Sign in with Apple, Google, an email magic link, or email + password). Magic-link tokens are stored only as a hash, never in clear text; if you set a password, we store only its bcrypt hash, never the password itself. If you use Sign in with Apple with Apple's private email relay, we only ever see that relay address.
• A login session, kept in a secure, httpOnly cookie.
• Devices you register, as a random device id and a device name (e.g. your platform name).

Stored transfer (download links)

When you use the optional stored download-link mode, your files are encrypted with AES-256-GCM on your own device before they leave it. That is true of every client that can create or open one of these links: a browser, the command-line tool, and our native macOS and iOS apps all encrypt and decrypt locally, and none of them uploads anything the server could read. The decryption key exists only in the URL fragment — it is never sent to the server. This means:

• The server stores only ciphertext. It cannot read your file contents, filenames, or keys.
• We record the ciphertext size and timestamps (upload time, expiry) for quota management and cleanup.
• Ciphertext is automatically deleted at expiry or on the first complete download (burn-after-read), whichever comes first.

Content we cannot read

Relayium servers never receive the following in plaintext and cannot decrypt them:

• The contents of your files.
• The names of your files.
• The bodies of your live text messages.
• Your encryption keys.

Cross-network relay (TURN)

Cross-network browser file and text sessions use a TURN server by design. TURN carries only end-to-end encrypted ciphertext and transport metadata. We attribute relayed-byte totals and timestamps to the code creator's account for quotas and abuse prevention, without inspecting message or file plaintext. CLI text is direct-only and does not use or count against TURN. Live text requires both participants to be online; Relayium provides no offline delivery or server-side message history, though either endpoint may copy or retain what it receives.

Usage metering and quotas

Paid plans mean the service has to count how much of it each account uses. While you are signed in, we keep a running per-account record of the bytes you upload and download through Relayium, the size of the ciphertext your stored links are holding, and the relayed-byte totals attributed to pairing codes you created. These counters outlive the transfer that produced them — we keep them as monthly per-account totals — because they are what enforces the usage, storage and relay quotas included in your plan, and what our billing and account records rest on. A paid subscription is a fixed price for a plan, not a per-byte charge.

• What is recorded: byte volumes, stored-object sizes, and the times they were measured, linked to your account.
• What is not: your file contents, file names, and message bodies stay encrypted and unreadable to us. Separately from account metering, we retain three first-party, identifier-free monthly aggregate action counts for cross-network pairing: successful code mints, the first admitted socket for a live code, and the first transition to two admitted peers. Each aggregate contains only UTC month, one of those three fixed stages, and a nonnegative count—never an identifier, event row, exact timestamp, or content metadata.
• Those three product-interaction totals are bounded, best-effort lower-bound action counts, not unique users, a cohort, or an exact conversion rate. Any displayed ratio divides same-month action totals and is not cohort conversion. Our apps and website carry no advertising or third-party analytics SDK, and neither the aggregate nor the account meters are used to track you across other apps or websites.
• You can see your account-linked usage totals at any time on your account page, in the app or on the web. The identifier-free aggregate appears only in the administrator overview; the database does not store it against your account and contains no field linking it to an account.

Cookies and local storage

We use one session cookie to keep you signed in. In your browser's local storage we keep a random device id so a device you registered can be recognized. We do not use advertising or tracking cookies.

Third-party services

A few third parties are involved only when you choose to use them:

• Google, if you sign in with Google — we receive your email and basic profile to create the account.
• Apple, if you use Sign in with Apple — we receive a stable identifier and the email (or Apple's private relay address) you choose to share.
• Stripe, our payment processor for subscriptions purchased on the web — see Payments.
• Apple, for subscriptions purchased through Apple's App Store — see Payments.
• An email delivery provider, to send account emails such as magic-link sign-in and verification.

Payments

You only share payment data if you buy a paid plan. We never receive or store your full card number.

• On the web, payments are handled by Stripe. Card details go to Stripe, not to us; we receive only a customer reference and the resulting subscription status.
• In a native app, subscriptions are bought through Apple's App Store rather than from us. Apple processes the payment under your Apple ID, and we never see your payment method. The app sends us Apple's signed record of the transaction, and we keep what it says about the purchase: which subscription product you bought, Apple's identifier for that subscription, and its status, billing period, and renewal or expiry dates. We also generate a random token that ties an App Store purchase to your Relayium account; the app hands that token to Apple with the purchase and it comes back to us in the signed transaction, which is how the two records are matched without adding any further personal identifier to the exchange.
• For your account we store only your current plan, subscription status, billing cycle, period dates, and your payment provider's reference for the subscription — never card data.

The Relayium apps for macOS and iOS

Our native apps handle a little device-level data that the website does not, and the two platforms do not handle the same data. Each item below says which platform it describes.

• The label this device carries in your account. On macOS the app reads the computer name from your Mac's Sharing settings and uses it as that label — sent with an email-and-password sign-in so your account can tell your devices apart and you can sign one out, and announced to the other devices in the room when you pair over the same network. macOS often seeds that name from your full name, so renaming the Mac changes what is sent. On iOS the label is generic and is never a name you chose: the app reads the hardware model and sends the device family — "iPhone", "iPad" or "iPod touch" — and nothing else, in those same two places. No personal name reaches us from an iPhone or iPad this way.
• An installation identifier, on macOS only. It is 32 random bytes the app generates on that Mac and keeps in its keychain, sent when you sign in through your browser so that signing back in returns to the device entry this Mac already has instead of adding another. It is random and never derived from your hardware — no serial number, MAC address, or hostname — so it identifies an installation and nothing about the machine. The iOS app has no browser sign-in to continue, so it generates no such identifier: today it sends us no installation identifier and no identifier read from the device itself. The random device id in your account's device list is one we issue for your account, as described above, and is not derived from your phone.
• What these apps do not do. Neither registers a push token and neither receives push notifications: on macOS, a finished transfer or a new inbox delivery is announced by macOS on that Mac itself, and those banners deliberately carry no file names, links, or codes, while the iOS app has no push capability and registers nothing with Apple's push service. The iOS app asks for the camera for one purpose — reading the pairing QR code another device is showing, so you do not have to type its join code by hand — and that happens entirely on your device: the picture and the code in it are used on the spot to join that pairing, and nothing the camera sees is stored by the app or sent to us as camera data. The macOS app asks for no camera access at all, and neither app has access to your photo library: when you pick photos to send on iOS, the system's own picker runs outside the app and hands it only the items you chose. Neither app tracks you across other apps or websites, and neither contains advertising or third-party analytics SDKs.

Data retention and deletion

Account data is kept while your account exists. You can delete your account and its data at any time from your account settings, in the app or on the web. Deletion starts a 30-day grace period during which you can undo it by signing back in; after that, your account and personal data are permanently removed. Aggregate usage counters we must keep for billing and abuse-prevention are anonymized so they are no longer linked to you.

Your rights

You can access, correct, export, or delete your account data, and object to or restrict certain processing. Most of this you can do yourself in your account settings; for anything else, email support@relayium.com. We do not sell your personal data. Where the GDPR or similar laws apply, our basis for the little data we process is performing the service you asked for and our legitimate interest in keeping it secure and preventing abuse.

Children

Relayium is not directed to children. We do not knowingly collect personal data from anyone under 13, or under the minimum age of digital consent where you live. If you believe a child has given us data, contact support@relayium.com and we will delete it.

Changes to this policy

We may update this policy as the service evolves. When we do, we will change the "Last updated" date above.

Contact

Questions about privacy? Email support@relayium.com.