Appearance
Bugs & feature requests
Three channels, depending on what you've got. Pick the right one and it gets seen faster.
| You have | Use | Identity needed |
|---|---|---|
| A bug, or a feature idea | GitHub Issues | A GitHub account |
| A bug or idea, and you want to stay anonymous | Holler | Just your tag |
| A security vulnerability | Responsible disclosure | None |
Don't file security bugs in public
If you've found something that could leak user information, deanonymize a writer, or compromise tags — do not open a public issue and do not post it to Holler. Go to responsible disclosure instead. Public disclosure of a deanonymization vector puts real people at real risk before we can fix it.
GitHub Issues
github.com/bodegga/1nky — 🔨 coming online with launch; the link 404s until then.
Best for anything reproducible, anything with a stack trace, and anything you want to be able to follow along with. Issues are public, searchable, and get linked to the commits that fix them.
Requires a GitHub account, which means it's not the anonymous channel. If your GitHub is tied to your name and your report would associate that name with using 1NKY, use Holler instead — that tradeoff is real and we'd rather you pick the safe option than the convenient one.
A good bug report has:
- What you did, in steps someone else can repeat.
- What you expected.
- What actually happened.
- Browser and OS, and whether you're on the installed app or a normal tab.
- Whether it happens on clearnet, the onion mirror, or both.
- Screenshots — scrubbed of anything identifying, please. Your bug report is a post like any other.
Please don't put in a bug report: your blackbook, the contents of any backup file, a passphrase, or a screenshot with any of those visible. There is no support scenario, ever, where we need your secret. Anyone asking for it is not us.
Holler — in-app, anonymous
📋 Ships with the feedback board in Phase 2.
Holler is the feedback board inside the app. Post to it exactly like any other board: your tag, your words, done. No email, no GitHub, no account, no extra identity of any kind beyond the tag you already have.
It rides the same rails as everything else on 1NKY, which means the same properties apply:
- Your post is signed by your tag on your device, so we know it's consistently from the same writer without knowing who that writer is.
- No IP is recorded when you post it, because none is recorded when you post anything. Same architecture, same verification.
- You can post it over the onion mirror if you don't want the CDN edge to see the connection at all.
- You can buff your holler later if you change your mind.
Why bother having a tag on it at all? So we can reply and you can see the reply, and so a conversation about a bug can go more than one round. It's a pseudonym, not an identity — the same pseudonym you already post flicks under, with nothing extra attached.
Holler is good for: "this is broken on my phone," "this word is confusing," "the feed does something weird after 30 posts," feature ideas, and telling us the docs are wrong.
Holler is bad for: anything security-sensitive (see the warning above), and anything you need a guaranteed response to.
Security vulnerabilities
Separate process, separate page, private by default: Responsible disclosure →
We also publish a machine-readable /.well-known/security.txt per RFC 9116, so scanners and researchers can find the right contact without guessing.
What we care about most: key custody, the metadata-stripping pipeline, and anything that deanonymizes a writer. Those are the reports that get dropped on and fixed first.
What happens to your report
Bugs. Reproduced, triaged, prioritized. Anything in the "leaks user information" class jumps the queue over everything else, including features. If we can't reproduce it we'll say so and ask for detail rather than closing it quietly.
Feature requests. Triaged onto the public roadmap. That page is the real backlog, not a marketing artifact — accepted ideas land in a phase or in the parking lot with a status. If we say no, we'll say why on the issue, and "no" usually means "this conflicts with a hard rule" (adding accounts, adding analytics, adding anything that collects an address) rather than "we don't like it."
Doc corrections. Treated as bugs with the same weight as code bugs. This site's whole value is that its claims are checkable; a claim that's stale or wrong is a real defect. If the docs and the code disagree, tell us which one you think is wrong.
Response times. No SLA. This is a small operation with a small number of hands. Security reports get looked at fastest; everything else gets to when it gets to. We'd rather promise nothing and answer than promise 24 hours and ghost you.