aipocalypse - speak up before it's too late

Back to boards

How it works

Who can read and post?

Anyone can read. Posting requires verification. The planned eligibility policy is based on credible public evidence of current work at selected AI organizations, supported by professional context and curator review. Suggestions and corrections are welcome.

This unpublished test currently accepts any X account and randomly assigns an employer and its associated tags from the provisional eligibility list. Test tags are not evidence of someone's actual employment.

What happens when I verify?

You sign in with X and return here with a credential stored in your browser. Verification does not submit your draft. Choose any tags you want to disclose, then press Submit. All credentials expire together at common 90-day calendar boundaries. Your verification status shows the next expiry date.

After verification, you can revoke Aipocalypse's access in X app settings. Your posting credential keeps working; renewal or recovery will ask you to authorize again. Revocation removes ongoing access, not records of the verification.

Does signing in reveal who wrote my posts?

The enrollment service learns which X account you verify. When posting, your browser instead produces a zero-knowledge proof of membership without sending that account or your private credential. Readers see your message, posting ID and any tags you select.

Who do I need to trust?

Why should I trust your cryptography?

The design uses published BBS signature protocols, implemented through a pinned, patched version of ZKryptium. The browser checks a fixed issuer key, tag vocabulary and common expiry schedule. It generates posting proofs locally instead of sending your credential to the posting API. Blind issuance and scoped pseudonyms follow published protocol specifications. The implementation is checked against protocol test vectors and application-level regression tests.

Reviews identified and fixed a way for a malicious enrollment operator to mark users through custom tag text. Tags now use fixed numeric IDs with locally defined labels and validated combinations. Integration reviews also found recovery and archive-consistency defects; their fixes have recorded regression tests.

Automated tests cover proof verification, duplicate enrollment, recovery, browser flows and storage failures. The application has not received an independent professional cryptographic audit. The review status records the remaining assurance work. Treat this testing version accordingly if being identified would put you at risk.

When does my posting ID change?

Before submitting, check "Posting as" beside Submit: it shows the same ID readers will see. "New thread, new ID" marks the default when starting a thread. Saved IDs also show their private nickname. Posts sharing an ID can be combined to infer more about you from their tags and text.

By default, your posts in the same thread share a posting ID. The "ID for this thread" option keeps that ID when you reload or return later in this browser. A different thread gets a different ID. If you start a thread, your replies keep the opening post's ID.

Click "Roll new ID" to change the ID for your next post and subsequent replies in this thread. Earlier posts keep their original IDs. Rolling from a saved ID switches back to a thread-specific ID without deleting the saved one. An ID is not a count of unique people: one person can use several.

Can I keep an ID across threads?

Yes. Click "+ New saved ID" and select it from the dropdown whenever you want to use it. You can optionally give it a private nickname. All IDs have equal status; saved IDs can be used as long-term identities or for a few posts. Reusing an ID makes those posts publicly linkable across threads and boards. Nicknames are never published.

What do the tags disclose?

After verification, you can select from the tags assigned to your credential, or disclose none. A specific employer replaces its broader organization category in your selection. Domain tags are selected independently. Your choices can differ on every post and do not determine your posting ID.

What if I reload, change browsers or lose my data?

Credentials and ID choices are stored locally in this browser. Reloading keeps them. An encrypted browser backup preserves your credential, thread ID choices, saved IDs, nicknames and drafts. Alternatively, save the recovery secret in a password manager: entering it in a new browser and verifying the same X account recovers the original credential, but not local nicknames, drafts or rolled ID choices. Verification alone cannot recover a lost secret. Another signup cannot create a second credential for the same account in the same epoch.

Why can posting take a moment?

Your browser loads a small credential engine and prepares the proof locally. The progress indicator shows the current operation. If acceptance is uncertain, use "Check pending post" to retry the original request with its original ID.

Will the history survive an outage?

Public history is replicated to independent storage providers so reading and restoration can survive the write server disappearing. Replication follows acceptance, so a sudden failure before replication finishes can lose recent accepted posts. Independent copies improve recovery; they do not make the service takedown-proof.

Technology stack