Project Honeycomb · Data handling

How we handle your story and files

This page says, in plain words, what happens to a story from the moment you press Add to the archive: what we keep, where it goes, who can see it, how long it stays, and how to have it taken down. A technical appendix at the end has the detail for anyone who wants it.

In short

Your submission is private by default. It goes into a review queue that only the Honeycomb team can see. Nothing is published until a person on that team approves it, and then only at the visibility level you chose. You can have it removed at any time with one email. The only companies that touch it are the ones that store and serve it, and the number of them is kept as small as we can make it.

What we collect

Only what you put into the form. Every field except the title is optional.

Your account — the words you type or dictate, and/or a video or audio recording. For a video we also keep its audio track on its own, so it can be transcribed.
A photo, if you attach one. It becomes the face of your cell in the comb. If you send a video and no photo, a single frame from the video becomes the face instead, once the story is approved; it is shown at the same visibility level as the story, a moderator can hide it, and it is deleted with the story.
Your name, first and last, and how much of it to show: full name, first name and last initial, or initials only. Both are kept separately so you can change how much shows later without telling us your name again. Leave both blank to stay anonymous; your cell then shows the place, or the title, instead.
A title, a place, a year, and tags — as you wrote them.
The visibility you chose: public, community only, or strictly archived.
The moment you submitted and confirmed the account was yours to share.
A submission ID, generated for you and shown once, which is how you refer to the record later.
Your email address — only if you tick that you are open to the team contacting you. See below.

If you leave an email. It is stored on its own, apart from your story, and is never shown on the site or sent to any visitor or member. Only the moderators see it, and they use it for one thing: writing to you about the story you submitted. It is never used for marketing, never shared, and never added to a mailing list. It is deleted with your story, or on its own whenever you ask. Leave the box unticked and we have no way to write to you — and nobody who obtains the archive could either.

Nothing about your device or connection is written into the record: no IP address, no browser details, no location beyond what you type.

Where it goes, step by step

In your browser. While you write or record, everything stays on your device. Nothing is sent until you press the button.
Upload. A recording or photo goes directly from your browser into a private storage bucket at Cloudflare, over an encrypted connection, using a one-time upload link that is valid for thirty minutes and for that one file only. It does not pass through any other server on the way.
The pending queue. The written record — title, name and display choice, place, year, words, tags, visibility — is stored beside it, in a part of the bucket marked pending.
Review. A moderator on the Honeycomb team opens the queue, reads or listens, may ask for a machine transcript of a recording, corrects obvious errors, and decides. Machine transcription runs inside the same Cloudflare account that already holds the recording, so no additional company receives the audio.
Approved records move to the approved part of the bucket. Declined records are deleted at that moment, together with their files.
On the site. An approved story is served under the visibility you chose. Public: to anyone who has entered the site password. Community only: to signed-in members. Strictly archived: never leaves the server; it is kept, and not shown to anyone but moderators. Recordings and photos are served through links that expire after an hour.

Who can see it, at each step

You: Your own draft, in your browser, until you submit. After that you cannot log in to see it; the submission ID is your handle on it.
Honeycomb moderators: The six members of the Honeycomb team — Paul, Liz, Dane, James, Eavie and Allen — and no one else. They hold the moderator password and see everything in the pending queue and the archive, at every visibility level, because they are the ones deciding.
Site visitors: Approved public stories only, after entering the site password. Visitors never see the queue, declined submissions, or anything marked community-only or strictly archived.
Members: People the team has given a personal access code. They see approved public and community-only stories.
Cloudflare: Stores the files and the records, encrypted at rest with keys Cloudflare manages, and runs machine transcription when a moderator asks for it. As the storage provider it is technically able to read what it stores. See the appendix for what that means and what we are weighing.
Netlify: Runs the site itself. Like any host, it sees requests in transit — including the address they come from — and keeps its own operational logs. We do not copy any of that into your record.
Sentry: Receives a report when the site hits an error, so it can be fixed. Reports are stripped before they leave: no story content, no form contents, no address, no cookies.
Nobody else: No analytics, no advertising, no social-media embeds, no fonts or scripts loaded from anyone else. Your browser talks to projecthoneycomb.site and to the storage bucket, and to nothing else.

How long it lives

Pending: until a moderator decides. There is no automatic expiry on the queue today; the team reviews it as submissions arrive.
Declined: deleted immediately, with every file that belonged to it.
Approved: until you ask for it to be removed, or the team removes it.
Removed: deleted from storage at once. We keep no backup copies of the archive, so a deletion is final — and, to be equally honest, so would be a loss. Whether to add a backup that is itself encrypted is an open decision, noted in the appendix.
The unlock cookie that remembers you entered the site password lasts thirty days on your device and carries nothing about you.

How to have it removed

With your submission ID. Email contact@projecthoneycomb.site with the ID in the subject line — for example Remove HC-2026-09-18-7K3M — and your submission will be removed. Automatic removal on receipt is being connected; until it is live, a person on the team does it, within five business days, and this page will say when that changes.

Without it. Email the same address with the name you submitted under. If you stayed anonymous, include the date, the approximate time and a short description of the account so we can find it.

What “removed” means. The written record, the recording, its separate audio track, the photo, the transcript, the tags and your email address if you left one — all deleted, whether the submission was still pending or already approved. No copy remains anywhere we control.

Changing rather than removing. The same email can change your visibility level, or how much of your name shows, without resubmitting — or withdraw your email address and leave the story in place.

What we strip, and what we never collect

Never collected: your IP address with the record, your email unless you choose to leave it, analytics or tracking of any kind, scripts from other companies. There is no account to create and no profile to build.

Hidden file metadata. Photos and recordings often carry data you cannot see — where and when they were taken, the device that made them. Our rule is that this never reaches the archive. Today the site does not read or display it; a step that strips it from every file at the moment a moderator approves it is being added, and this page will state when it is in place. Until then, a file you upload is stored as you sent it.

Technical appendix

For the person whose job it is to ask the harder questions.

Where things run

Site and API: Next.js on Netlify (static assets at the edge, server code as Netlify functions, US region).
Storage: one private Cloudflare R2 bucket. No public read on any object. Every read of a recording or photo is a signed URL valid for one hour; every upload is a signed PUT valid for thirty minutes, bound to one object key and content type. Records are JSON objects in the same bucket under submissions/ (pending) and approved/submissions/. An optional contact address is a separate object under contacts/, keyed by submission ID; the public stories endpoint never reads that prefix, only the moderator-only review queue does, and deleting a submission deletes it.
Preview environment shares the bucket under a key prefix, with its own passwords and its own fictional test data; nothing crosses.
Transcription: Cloudflare Workers AI (Whisper), called from the server with the recording that is already in R2. The draft is stored on the record as a machine transcript and is never served to a visitor; a moderator confirms or replaces it.
Tag suggestions: when a moderator asks, the story’s words go to a language model on Cloudflare Workers AI, in the same account, which suggests tags from the archive’s fixed list. Nothing is stored by that step; a moderator confirms or changes the tags.

Who is on the list

Netlify — hosting, build, functions. Sees request metadata (IP, user agent, URL) in transit and in its own logs, retained on Netlify’s schedule.
Cloudflare — R2 storage (AES-256 at rest, Cloudflare-managed keys) and Workers AI transcription. The account holder controls access keys; the storage token is scoped to this one bucket.
Sentry — error tracking, US ingest. Browser reports leave through /monitoring on our own domain, not to a Sentry address. sendDefaultPii is off and every event is scrubbed before sending: user, IP, cookies, headers, request bodies, query strings and URL signatures are removed. Tracing is sampled at ten percent.
Not present: Google Fonts (self-hosted), analytics, Arcjet (in the dependency list, not active), any database (records are objects in R2).

Access model

The site password issues a signed session cookie (HMAC-SHA256, server secret), valid thirty days, role visitor.
Members hold personal codes; only a SHA-256 hash of each code is stored, and a code can be reissued or revoked by a moderator.
Moderators hold a separate password and reach /review and every moderation endpoint; each endpoint checks the role server-side. Moderator sessions currently share the thirty-day life; a shorter life for that role is on the list.

Transport

HTTPS only, enforced by the host; Strict-Transport-Security for one year including subdomains.
Referrer-Policy: no-referrer; X-Frame-Options: DENY; camera and microphone permitted to this origin only; a Content-Security-Policy that names every origin the page may contact (this release reports violations; the next enforces).
What a network observer can still see: that a device connected to projecthoneycomb.site, when, and roughly how much data moved. Not the content.

Deletion, backup, incidents

Deletion is an immediate object delete of the record and every media key it references. R2 keeps no versions and we take no snapshots, so it is final.
There is no backup today. That protects the “gone means gone” promise and exposes the archive to loss; an encrypted backup under our own key is the option being weighed.
Secrets live in Netlify environment variables, never in the repository. Dependencies are audited before each deploy.
Anything that looks like a security problem: contact@projecthoneycomb.site, subject “Security”.

Decisions still open

Encrypting files in the browser before upload, so the storage provider holds only ciphertext — against the cost of running transcription and moderation on hardware we operate ourselves.
Where the metadata strip runs: at approval on the server (simpler; the raw file waits in the pending area until then) or in the browser before upload (better; harder).
An expiry on the pending queue.