Skip to main content

fake.dating

2025-06-14 · by admin

fake.dating is a dating-app simulator where every profile is a character played by an AI. Browse, match and chat as you would on a real app — except the person on the other side is a large language model with a personality of its own.

Where it comes from

Dating apps are a frustrating experience. Filters decide who you are allowed to see, ghosting is routine, catfishing is common enough to have a name, and the whole thing runs on a kind of hopeful attrition. To take part you have to commodify yourself into a limited set of checkboxes and dropdowns — height, job, star sign, a few pills of interests — and, in the same motion, waive any meaningful rights to your data. Every conversation you have there belongs to the platform.

The apps themselves behave like someone playing power games: information withheld, access rationed, attention doled out on a schedule designed to keep you coming back. And underneath it sits a mismatch of incentives that cannot be overstated. A dating app makes its money from people who are still looking. Every time it does its job and creates a real match, it loses two customers. The product is not the match; the product is the search, and the search is what it is built to prolong.

Characters with quirks

Each character is built from a taxonomy of traits — interests, personality, sexuality, star sign, relationship goals and more — that shape how they talk. What makes them feel like people rather than chatbots is a layer of behavioural traits borrowed from the language of pathology. Traits turn out to be an easy way to influence how a model behaves. We all carry them at times — distractibility, a need for reassurance, a flash of grandiosity — and what separates a quirk from a condition is scale and intensity, not kind. Because so much has been written about these patterns online, a model already knows what they look like in conversation and can operationalise them in its replies: dial one up and a character zones out mid-chat, forgets what you told them, then fixates on the one topic that catches them. The effect is deliberately subtle: a texture in how someone replies, not a diagnosis announced in the chat. Per-character direction lets you steer the rest, and chat runs on whichever model you point it at: Grok, Claude, Featherless, or any OpenAI-compatible endpoint.

Faces

Profile photos are AI-generated with a consistent face across every shot, characters send a selfie when asked for one, and short video clips can be generated from a profile photo. A character editor handles the rest: profiles, traits and direction, photo and video libraries, and a user profile that generates your own photos too.

Voice, and pictures on request

Every character has a voice. Tap play on any reply, or switch on auto-play, and it is read aloud in a voice picked to fit the character's gender and accent — ElevenLabs by default, with Grok's voices as a fallback and OpenAI's available if you add a key. It works the other way too: hold the mic button and speak, and the recording is transcribed and answered — and because you spoke, the reply comes back as audio, pre-generated so the conversation stays in one medium. Speech in, speech out; the transcript is kept quietly for the model's memory while the chat shows the audio bubbles.

Pictures work the same way, inside the conversation rather than from a menu. The model watches the text for a request — "send me a pic", "what are you wearing", "show me the view" — and only then adds an image directive to its reply, a short description of what to generate. That description is rendered with the character's reference face and arrives in the chat as a selfie, so asking to see something feels like asking a person, not pressing a button.

Making characters

Characters are made, not just browsed. The editor gives you the whole recipe — traits, pathology, direction, photos and videos. The more interesting route starts from an image: upload a base photo as the character's reference portrait and every picture generated afterwards keeps that face — the profile shots, the selfies sent in chat, the video clips. A face you drew, a face you generated elsewhere, or your own: the character is built around it. Characters made in the editor can be published to the shared roster, so anyone using the app can match with them and talk to them — though publishing is switched off for now, for the reasons below.

Unashamed objectification

Dating apps reduce people to a card of attributes and a swipe, and then pretend they don't. fake.dating drops the pretence. You choose a character's nationality, eye colour, height, body shape and, yes, breast size from pill selectors; those attributes go straight into the image prompts; and you accept or reject a face in a second, exactly as the real apps train you to. The difference is that nobody here is a person — every profile is generated, so the mechanics can be laid bare without anyone being on the receiving end. It is a simulator of the thing, with the thing's honesty turned up.

Age-gated, without handing over your face

Adult content needs a real age check, and the usual answer — upload a selfie or an ID to a verification company — is exactly the kind of data trail this project wants to avoid. So the check runs in the browser. The camera captures three angles, front, left and right, with MediaPipe face landmarks confirming a real head at each pose; then a Hugging Face age-estimation model, converted to ONNX and run on-device with transformers.js, estimates age from the frames. The model downloads once (about 85 MB, cached by the browser) and nothing leaves the machine: no image is uploaded, no face is stored. All the server records is that a check happened, when, and the outcome, against a hashed address — pruned after a year.

Shipping

Deployment is continuous and deliberately thin. A push to the deploy branch triggers DigitalOcean App Platform to build the app with the Python buildpack and roll it out on a single small instance — no servers to look after. The whole environment is described in a versioned app spec: domain, instance size, run command, and every environment variable, with the sensitive ones declared as secrets whose values live only in the DigitalOcean console, so the spec can sit in git without leaking a key. The filesystem is ephemeral, so the app re-downloads its GeoLite2 and country-block lists on every start rather than trusting anything on disk. Two switches matter day to day: a MAINTENANCE flag that takes the site down without a deploy, and the lists of countries and US states where the age gate is enforced, both plain environment variables. There is no test suite yet; that is the next thing the pipeline needs.

Bring your own models

Nothing is hard-wired to one AI company. Each kind of output — text, images, video, voice — has its own provider setting, and you supply your own API keys, pasted per provider in the settings panel. So you can run the conversation on one company's model and the pictures on another's, mixing and matching by medium and by taste.

The chat can run on xAI's Grok, Anthropic's Claude, Featherless AI, or any OpenAI-compatible endpoint — OpenAI itself included. Images come from Grok, Google's Imagen, Alibaba Cloud's Qwen, or a ComfyUI workflow you point it at. Video is Grok. Voices are ElevenLabs by default — which also does the speech-to-text for voice messages — with Grok and Alibaba's Qwen as alternatives. Grok is the default throughout, so it works out of the box; the rest is there for anyone who wants to bring their own keys and pick a favourite for each part of the experience.

Why not local models

It did not start out this way. The first version ran on local, open-weight models on an NVIDIA DGX Spark, with the intention of containerising the whole stack and deploying it as a self-contained unit — no API keys, no per-token bills, nothing leaving the box. What killed it was not the models but the policing. With an open model you own every safety decision yourself: everything a user types has to be analysed on the way in and everything the model produces on the way out, and that burden is high — in engineering, in judgement, and in latency, because each of those checks is another model call sitting in the path of every message. Frontier models arrive with that work already done. The large companies are, for all their faults, more compliant and more responsible than the smaller — often Chinese — open models, and their refusals are a feature here rather than a nuisance. It turned out cheaper and better to pay per token and inherit their guardrails than to build and run my own.

Under the hood

A Python/FastAPI app with Postgres for users, conversations and an append-only credit ledger, DigitalOcean Spaces for media, and pluggable image, video and chat providers. It includes an opt-in adults-only mode that is off by default.

The hard part is not the technology

Building a convincing fake reality turns out to be the easy half. The models are good, the pieces fit together, and a character that looks and sounds and behaves like a real person is a weekend’s work now, not a research programme. The hard half is regulation and ethics — what you are allowed to run, what you ought to run, and who answers when it goes wrong. Those are the hardest part of the whole problem, and they are hard in a way code does not solve. Moderation is where they first bite.

The same feature that lets you build a character around a face you drew lets someone upload a photo of a real person — an ex, a colleague, a stranger — and generate intimate images of them that they never agreed to and may never know exist. Nothing about the technology distinguishes the two uses; the difference is entirely one of consent, and consent is exactly the thing a model cannot see. I do not have a clean answer to where the line sits, or to what happens when these images leave the screen and land in someone's real life. Those are not questions you can defer to a filter.

Publishing, and the law

The original plan was for user-made characters to be the heart of the app: publish a character, and earn a share of the profit on every token other people spend talking to it. That incentive is where it falls down. In the UK, paying people for content of this kind puts a platform in a legal position I am not willing to occupy — and it makes the consent problem above worse, not better, by rewarding exactly the uploads that are hardest to police. I considered working around it with real identity: verified, trackable, accountable creators, so that anything published could be traced back to a person who answers for it. That is a serious undertaking of its own. For the moment, publishing is disabled: you can make characters and talk to them, but they stay yours.