Progress update: it exists, and the interesting part isn’t the security
I said I’d build a prototype over the weekend. Here’s what exists — and while it started as a spam defense, the thing I most want to compare notes on now is using Internet Identity as ordinary community-operations infrastructure.
What it does
One page, one form. You pick why you’re here — join, send a proposal, book a paid consultation, or submit a PR listing — write a few lines, and sign in with Internet Identity at the moment you submit, not before. The application lands in a canister. An admin reviews it from a browser panel. If you’re approved, a one-time Discord invite appears on the page you applied from: nothing is emailed or DMed, so there’s no link in transit to phish or forward. (It’s fetched with an update call, not a query — query responses aren’t certified, and this is the one link a user will actually click.)
For the paid lanes the canister holds an ICRC-2 deposit and returns it on approval, on rejection, or automatically via timer if nobody reviews it in time. The only path where you lose it is an explicit spam judgement, and the count and total are published.
Why Internet Identity and not a normal form. A Google Form would have taken an afternoon. But then I’m collecting email addresses — which are free to generate, so the spam problem just moves one step back — and I’m holding personal data I don’t want to hold. II gives me the inverse: nothing stored, nothing to leak, no address to burn through, and the same identifier doubles as the refund destination once money is involved. The applicant proves they are a persistent identity without telling me who they are. For a community intake desk that’s a better trade than any form service I could buy, and I don’t think it’s a use of II I’ve seen written up anywhere.
One decision I’d repeat: the admin panel can’t move money. Review, invites, and reversals are gated on an Internet Identity admin roster. Withdrawals, prices, and adding admins need the controller identity, which only lives in dfx. A compromised browser session can admit the wrong person; it can’t take the treasury.
Not on mainnet yet — 59/59 locally, including an upgrade test. Free lanes go first; paid lanes stay switched off until someone reviews the money paths.
What I got wrong
I said the main risk was update calls draining cycles. That was the easy part (inspect + an O(1) counter). Three things turned out to be worse: an atomicity bug in the refund path that let confiscate and refund both succeed on the same deposit, a sybil attack that could lock everyone out of the free lane, and the fact that a Discord bot token can’t safely live in a canister at all. All three are dealt with — happy to expand on any of them in replies.
My question
Has anyone built a plain form around Internet Identity — an application form, an intake desk, anything like that? Not a wallet, not a dapp login. Every II example I can find is one of those two, and I’d like to compare notes with someone who used it for the boring operational side of running a community: did people bounce at the II screen, and did you keep it?
For context, since it’ll be obvious anyway: I run the community, I’m not a systems programmer, and this was built with heavy AI assistance. A year ago it would have been a spec handed to someone else, or more likely a Google Form.