Privacy Policy

What Yeetline: chat, mail and search that mind their own business holds about you, for how long, and who can see it — and what it cannot read, which is the content of every message and file you send.

1. Who Is Responsible

Yeetline: chat, mail and search that mind their own business operates Yeetline: chat, mail and search that mind their own business at https://yeetline.com and is responsible for the personal data this server holds. This policy says what that is, why it is held, for how long, and who can see it.

2. What the Server Cannot Read

Messages, files, call audio and video are encrypted on the device that sends them and decrypted only on the devices that receive them. The server stores and forwards ciphertext and holds no key that can open any of it, even with complete access to its database and its disks. That is not a policy we could change by editing this page; it is how the software is built, and it is described in full in the application's documentation.

3. What the Server Holds

What any messaging server must hold to work, and no more:

• Your account — your username, the public half of your identity key and the one-time keys other devices use to start a conversation with you, the email address you registered with, and — if you set them up — the secrets that verify a second factor, your passkeys, and your recovery codes (stored hashed). If “Let me sign in from other devices” is on, which it is by default, also your keystore: your identity keys sealed under your passphrase, which we never see, and a hash that lets the server check a passphrase before it releases that copy.
• Your devices — a label for each device you have signed in on, its keys, and when it was last seen.
• Recovery — if you made a recovery key: a public key it makes, a hash of a value it derives, a signed binding to your account's identity key, and a backup of your account's keys that this server cannot open, kept until you turn the key off or replace it or the account is deleted, renamed or recovered. If your account was recovered with a mailed code: the times, hashes of two codes and which kind of second factor was shown, for 30 days after it ends; the codes themselves and a request not yet proved are in memory only.
• Sign-ins — the network address and browser or app each sign-in came from, kept for 30 days. It exists so a suspension can cover the addresses behind it and so you can recognize your own devices. A separate log of failed sign-ins, and of every sign-in to the admin panel, keeps the same details and which account was tried, for 90 days. Wrong passphrases tried on an account's synced keystore are counted per network address for seven days, so that a stranger guessing from one address is slowed down and the person restoring from another is not.
• Messages — the encrypted form of each message, with what any relay must see to deliver it: who sent it, which conversation it belongs to, when, and how large it is. Not its content, and not the names of anyone mentioned in it.
• Files — the encrypted form of each file you send, its size, who uploaded it and which conversation it belongs to. Not its name, its type or its content — those travel inside the encryption.
• Rooms — each room's name, topic and description, which rooms you are a member of, any room role you hold, and how far you have read in each conversation.
• Friends — who you are friends with, the friend requests waiting, with who asked whom and when, and who you have blocked. They are not encrypted, so that the friends list, the accept step and a block can work.
• Reports — whatever you put in a bug report or a feature request, pictures included, with the page and the browser it was sent from: a report is written for staff to read.
• Presence — whether you are online right now, shown to the people you share a room or a conversation with, and not stored.
• Profile — a display name and a profile picture, if you set them. The picture is published to everyone signed in to this server and cannot be recalled from anyone who has kept a copy.
• Push subscriptions — if you turn notifications on, the address your browser's push service gave us for this device. What we send through it is a wake-up with no content in it.
• Staff records — an audit trail of what administrators and moderators do (kept for 365 days; where moderators are asked for a reason when they remove a message, it holds the reason they typed, in the clear), the notes staff write about an account and the reasons they give for a suspension or an address ban (which the person is not shown), and a server log that records connections, errors and rate-limit events by address, kept for as long as the host keeps its logs.
• Organization records — where an administrator has set them up, the directory of units and who belongs to them, roles, clearances, on-call schedules and retention rules, and, where sign-in goes through the organization's identity provider, the provider's identifier, email address and groups for each person.
• Payments — if you buy a plan or a hosted deployment, a record of each payment: when, how much, in what currency and for which account, and for a deployment the company, the contact email and the plan on its order. The card number goes to the payment provider and never to this server.

4. Your Email Address

If your account has an email address — one you typed in, or the one Google handed over when you signed in with a Google account — it is held for one purpose: to reach you. Account notices (a welcome, a sign-in from a new device, a page of this service opened from a signed-in device, a change of role, wrong passphrases tried to open your keys, a moderator's removal of one of your messages, and a recovery of your account or its recovery key being made, replaced, turned off or used) and codes (sign-in, second-factor, recovery and unlock codes) go to it, and nothing else does. You can stop the optional kinds (answers to reports you sent, staff digests, product updates) from the link at the end of each such letter or under Settings → Email in the app; codes and the notices that protect your account are always sent.

It is never shown to another user, never published on any page, and never sold, rented or shared. The admin panel's user list does not carry it; the one place staff can meet it is the audit trail, where enabling email as a second factor records it masked (a***@e***). No message, file, room or profile ever carries it.

5. How Long

These are the windows this server is actually configured with; the operator can change them, and this page changes with them.

Deleting your account removes your account record, keys, devices, room memberships and the encrypted files you uploaded. Encrypted messages you sent stay in the conversations you sent them to until their own retention window ends, as a letter stays with the person you sent it to.

6. Who Can See It

We do not sell, rent or share what the server holds with anyone, and no analytics or advertising service is loaded by the app. The parties that can see something are these:

• The people you talk to see your username, display name, picture, presence and — of course — what you send them.
• Staff (administrators and moderators) see your account details, your devices, the addresses you signed in from, how much storage you use and the audit trail; they cannot see message or file content.
• Your browser's or phone's push service (Apple, Google or Mozilla, depending on the device) receives the content-free wake-ups described above.
• A call relay, if this server runs one, forwards call audio and video between devices that cannot reach each other directly. The media is encrypted end to end; the relay sees the addresses and the volume of traffic.
• Google, if you sign in with a Google account, learns that you signed in to this service and when; we receive your Google account's identifier and email address and nothing else. The address is used only to reach you (see Your Email Address): it is never shown to another user, never published, and never sold or shared.
• A mail provider, if you have an email address on your account, delivers the notices we send you — the welcome, the notices of a new device, a change of role, a removed message, wrong passphrases and a recovery, and the codes (second-factor, sign-up, recovery and unlock). The provider sees the address and the message.
• Any network or CDN in front of this server sees your address and the encrypted connection, as any network does.

7. If We Receive a Legal Demand

A court or a public authority can order a service to hand over what it holds. If one is ever served on us, the answer can be only what this server holds, as What the Server Holds lists it and for the windows under How Long. We review each demand, answer only what it validly requires, tell the person it concerns where the law allows and we have a way to reach them, and push back on a demand that is too broad. We do not build a way to read messages, for anyone.

What could be handed over is the ciphertext and the records around it:

• Messages: the encrypted form of each, with who sent it, to which conversation, when and how large, until you or the room's moderators delete it.
• Files: the encrypted form, its size, who uploaded it and to which conversation, for 30 days.
• Account records: the username, public keys, devices, the rooms you are in with their names, topics and descriptions, how far you have read in each conversation, friends, friend requests and blocks, the profile, any email address on the account and whether a code has shown it to be yours, and the secrets that verify a second factor and the hashes of recovery codes if you set them up, and, if you turned notifications on, the push address your device gave us, until the account is deleted.
• Your keystore, if “Let me sign in from other devices” is on (it is by default): your identity keys, sealed under your passphrase, which we never see, with a hash that lets this server check a passphrase before it releases that copy. On its own it does not open a chat message or a file, and we cannot open it; but anyone who holds a copy can try passphrases against it offline, so your passphrase is what protects it.
• Recovery records, if you made a recovery key or your account was recovered. For a recovery key: a public key that it makes, a hash of a value it derives (which cannot be turned back into the key), the account's public identity key with the signature of the paper over it, a backup of the account's keys that we cannot open (it is sealed on your device to the key, so whoever holds the paper can open it, and the paper is what protects it), and when it was made and last refreshed, until you turn the key off or replace it, or the account is deleted, renamed or recovered. For a recovery of the account whose emailed code and second factor were proved: the username, the times it started and ends, hashes of the page's token and of the cancel code, which kind of second factor was shown and who approved it, for 30 days after it ends. A request before it was proved, and the codes mailed for it, are in memory only and go when the server restarts.
• Reports: whatever you put in a bug report or a feature request, with the page and the browser it was sent from, which is written for staff to read.
• Sign-in records: the network address and browser or app of each sign-in, for 30 days, and the log of failed and admin panel sign-ins, for 90 days, and, for seven days, the network address a wrong passphrase for an account's synced keystore was tried from and how many were tried, which is what lets the server slow a stranger down without slowing the person.
• Staff records: the audit trail of what administrators and moderators did, for 365 days; where moderators are asked for a reason when they remove a message, the audit trail holds the reason they typed, in the clear, beside their name and the conversation, for the same window; the notes staff write about an account and the reasons they gave for a suspension or an address ban, until staff remove them or the account is deleted; and the server log of connections and errors, for as long as the host keeps its logs.
• Organization records, where an administrator has set them up: the directory of units and who belongs to them, roles, clearances, on-call schedules and retention rules, and, where sign-in goes through the organization's identity provider, the provider's identifier, email address and groups for each person, for as long as the organization keeps them.
• Payments and orders, if you bought a plan or a hosted deployment: when, how much and for which account, and for a deployment the company, the contact email and the plan. The card number goes to the payment provider and never to this server.

What cannot be handed over is the content of any message or file sent in a conversation, the audio or video of a call, and your passphrase or any key that opens them. We do not have them: this server holds no key that opens any of it, so there is nothing readable to produce, and an order for what exists cannot change that.

Yeetfind keeps nothing about a person to hand over: it keeps no search, no account, no cookie and no address beside a search. A search is read in memory to be answered, so whoever controls that machine can read one while it is answered, and none is kept afterward.

A record that has been deleted, or that a retention window has removed, can still sit in this server's backups. They hold the same records and the server's own settings, which include the credentials it uses for services such as outgoing mail, and they are encrypted to keys that the people who run the server hold, so an order that reaches those people reaches the backups. A retention rule an administrator has set for a room or an account replaces the window above for it, and a legal hold pauses deletion for the records it covers. A demand can reach all of these, and none of them holds the content of a message, a file or a call.

A demand can reach only what exists, and it cannot reach readable content that this server never held. What nobody can know in advance is whether a court could order a service to change how it works from now on; where the law allows, we will tell you if that ever happens.

8. Why We Hold It

Everything above is held to run the Service you asked for — to deliver your messages, keep your account yours and let you sign in from more than one device — and to keep the Service safe: rate limits, suspensions and the staff audit trail exist so abuse can be stopped and so what staff do is on record. We do not profile you and make no automated decisions about you.

9. Your Rights and Choices

You can see and change your profile, your devices and your second factors from your settings, sign out any device, and delete the account outright. Where the law where you live gives you rights to access, correct, export or erase personal data, or to object to its use, you can exercise them by contacting us; we will answer within the time the law allows. You may also complain to the data-protection authority where you live.

10. Security

Beyond the encryption itself: connections are TLS-only, passphrases never leave the device, second factors and passkeys are available and can be required, wrong guesses at a passphrase or a code are slowed for the one who makes them (a person who proves who they are is not refused for what anyone else does), and staff actions are audited. No system is perfect; if you find a problem, the application's documentation says how to report it.

11. Children

The Service is not directed at children under 13, and we do not knowingly hold data about them. If you believe a child has created an account, contact us and it will be removed.

12. Changes to This Policy

The current version is always the one at https://yeetline.com/privacy. A material change will be announced through the Service before it takes effect.

This page is generated by the software from this deployment's settings, so what it promises is what the server does. It is a starting point, not legal advice: the operator should have it reviewed by counsel before relying on it.