Reporting a bug or a request

Report at the foot of the rail is the whole of it. It files what you write with the people who run this deployment, and it is the same button for "this is broken" and for "it would be better if".

What to press

Report opens a short form: whether it is a bug or a request, a few words of title, and what happened or what you want. Attach up to four pictures if a picture says it faster — a screenshot of the thing going wrong is worth a paragraph of describing it. Send, and you are done; you need no address, no login anywhere else, and no account beyond the one you are already using.

On a deployment Yeetline runs for an organization, Report is how the people who run it get hold of Yeetline support, and is there only for them — its admins and moderators, and anyone the organization gives the issues permission. What they send goes to Yeetline, the service that runs the deployment, and the staff page where it is kept is called Yeetline support. The form says so before it is sent. Everyone else tells one of them, and Settings → Help says so where the button would be.

A report carries three things of its own, and only these three: what kind of page you were on (a room, a thread, Saved Messages, and whether the screen is a phone's or a desk's), which release of the app it was made on — the server writes that down itself — and your browser's own description of itself. Never a message, never a room's name, never anybody's name but yours.

What to put in it

The three things that turn a report into a fix:

1. What you did, in the order you did it.
2. What happened — the exact words of any error, if there was one.
3. What you expected instead.

If it only happens sometimes, say when. If it started recently, say what changed. "The composer eats the first character after I switch rooms with Ctrl+K" is a report somebody can act on; "typing is broken" is not.

What happens next

You get a "thank you", and the report goes into the list the staff of this deployment work through — they are told it arrived wherever they are. That is the last you hear of it automatically: there is no ticket to check back on from here, so if a report needs a conversation, the staff of this deployment will start one with you in the app.

On a deployment Yeetline runs, the report is Yeetline support's to work instead. It waits a few minutes for the service's agent to collect it, and the Yeetline support page says whether it has gone and where Yeetline has got to with it — in progress, resolved. Everything added to it there goes to Yeetline too: every comment, and every picture. Yeetline's answer comes back to the report's thread, marked as Yeetline's, and to whoever sent it — in the app, and by email. Nobody else on the deployment is alerted or written to about a report, and nobody there sets its status or hands it to somebody: that is Yeetline's side of it. Withdraw takes a report back, at Yeetline too. A report Yeetline turned down, or one made before reports went to Yeetline, can carry nothing more; the page says to write to the support address on the Subscription page instead.

Two limits worth knowing. A handful of reports an hour per account is the ceiling, so a stuck Send button cannot become a hundred of them. And an operator can switch app reporting off entirely, in which case the button is gone and Settings → Help says so in its place — tell somebody in a room instead, and they can enter it for you.

What not to send

Never put a passphrase, a recovery code or anything you would not want read into a report. A report is the one thing you hand this server unsealed: your messages are encrypted to their recipients and the server cannot open them, but a report has to be readable by whoever fixes it, and a picture attached to one is readable the same way. The dialog says so before you pick a picture. If a report needs to quote a message, quote the part that matters rather than the thread.

On a deployment Yeetline runs, a report is handed to Yeetline, and read there by the people Yeetline gives its reports to — its words, every comment on it, and its pictures too. A screenshot can show a conversation as you see it, decrypted on your screen, so look at one before you attach it and crop it to the part that matters. (Pictures attached before this release stay on the deployment, as the dialog said then; Yeetline was only told that there were some.)

Something dangerous rather than broken

Somebody behaving badly is a different matter: block them from their own menu, and tell a moderator, who is working from your account of it because they cannot read your conversations either. Staying safe walks through blocking, safety numbers, and what to give a moderator so they can act.

If you have found a security hole — a way to read what you should not, or to act as somebody else — this server publishes where to send it at /.well-known/security.txt. Send it there rather than to a room.

Last changed 2026-10-06