CAPTCHAFUN: Prove You’re Human and Have Fun Doing It!

The internet asks us to prove we are human with experiences that make us feel like machines.

This is a submission for the Weekend Challenge: Passion Edition.

What I Built

CAPTCHAFUN is a reusable playful-verification widget for ordinary websites. Instead of interrupting somebody with distorted text or traffic-light grids, it asks them to complete a short image puzzle and rewards success with an animated payoff.

The public demonstration shows the full boundary:

1. A visitor completes the jigsaw inside an isolated widget.
2. The backend validates the challenge rather than trusting browser state.
3. A short-lived, one-time token unlocks a simulated protected action.
4. The consuming backend accepts that token once; replay is rejected.

Demo

Video

Live demo: https://quantomancer.github.io/CAPTCHAFUN_frontend/

No account is created and no personal information is submitted in the demonstration.

Code

Public frontend: https://github.com/quantomancer/CAPTCHAFUN_frontend

The public repository intentionally contains only the browser-delivered integration and presentation layer. Backend implementation, private infrastructure, credentials, operational configuration, and subscription information are excluded.

Why Passion?

People arrive at websites with emotional momentum. They may be excited to join a community, buy a ticket, publish an idea, vote for something they love, or continue a game. A conventional CAPTCHA often interrupts that moment with a sterile chore.

I interpreted the Passion Edition prompt as a design question: can a necessary security interaction preserve the enthusiasm that brought someone to the page?

CAPTCHAFUN turns proof of humanity into a small moment of play. Its promise is simple:

Prove you're human. Have fun doing it.

How I Built It

How It Works

The host page loads a small JavaScript widget that creates an iframe. The iframe keeps the challenge UI and styles isolated, so a plain HTML site or a framework application can integrate it without adopting the Appwrite SDK.

The important security decision happens behind the interface:

• the server creates the challenge and stores its authoritative state;
• the browser submits a completion proof;
• successful completion produces a short-lived token scoped to the site and action;
• the protected backend verifies and atomically consumes the token;
• the same token cannot be used twice;
• unregistered origins and incorrect, expired, or over-attempted challenges are rejected.

The Appwrite backend uses dedicated captchafun- resources alongside another application while keeping tables, functions, storage, identifiers, and operational access separated.

Technical Execution

• reusable vanilla JavaScript loader and iframe widget;
• responsive 3 x 3 canvas jigsaw with pointer and tap interaction;
• Appwrite Functions for challenge completion and token verification;
• private Appwrite TablesDB state and private media storage;
• origin registration, action binding, expiry, attempt limits, and atomic token consumption;
• public GitHub Pages frontend that can be used by a non-Appwrite website;
• 13 focused backend and isolation tests;
• sanitized public repository with backend implementation and private infrastructure excluded.

Built During the Challenge

CAPTCHAFUN was created as a new standalone project and repository during the challenge window. The reusable widget packaging, independent demo, Appwrite verification backend, one-time-token flow, protected-action example, tests, documentation, repository security split, and deployments were produced for this entry.

The visual jigsaw interaction, Drill Sergeant image, and success video were adapted from my pre-existing FunFactory experiment. They are disclosed as prior material rather than claimed as newly invented for this weekend. The competition work is the substantial transformation of that interaction into an independently deployable, server-authoritative verification product and demonstrator.

Accessibility

The current prototype includes semantic status messages, keyboard-focusable controls, visible labels, muted-by-default success media, and a reduced-motion-aware presentation. Audio is optional and is never required to verify successfully.

A production version must provide a fully equivalent nonvisual challenge or an application-appropriate accessible bypass. Fun must not become another barrier.

Security and Product Limitations

CAPTCHAFUN demonstrates server-validated challenge completion and one-time authorization. It is not presented as a replacement for a production bot-risk engine, abuse-detection platform, device reputation service, or enterprise CAPTCHA provider.

The public frontend necessarily exposes browser-delivered code and network requests. Credentials and privileged backend configuration are never sent to the browser or stored in the public repository.

What I Learned

The interesting problem was not drawing puzzle pieces. It was defining the trust boundary around a playful interface.

A beautiful frontend callback proves nothing by itself. The protected action has to trust a server decision, the token must be scoped and short-lived, and consumption must be atomic. At the same time, stronger verification cannot justify an experience that excludes people or destroys their momentum.

The best version of CAPTCHAFUN sits between those concerns: delight in the browser, authority on the server, and honest limits everywhere.

What's Next

• add an equivalent accessible alternative;
• validate narrow mobile and assistive-technology flows more deeply;
• add several curated microgames behind the same verification contract;
• integrate production risk signals without tracking people unnecessarily;
• provide a small registration workflow for additional external sites.

CAPTCHAFUN does not merely ask whether somebody is human. It tries to respect the human enthusiasm that brought them there.