Public Dating Is Not a Data Breach

Likes through an API

An API that lets a participant like a public profile is doing its job

An open dating service must let a user express interest in another participant. The button on the screen sends an API request anyway. Reproducing that request with a technical client is not a magical product bypass. It is another client talking to the same server.

The real checks come next: the request must be authenticated, the actor must be active, and server limits must apply regardless of the interface. Current Mimolet reactions use an authenticated server route and are limited by plan to 60, 250, 500, or 1,200 actions per day.

So "the API can like a person" sounds alarming only until translated into plain language: "the dating service lets a user send a like." That is what the service exists to do.

Automated collection

Scraping exists everywhere. The question is cost and scale, not existence

Public pages and feeds are automated across social networks, marketplaces, search engines, messengers, and dating services. An absolute technical prohibition does not exist because automation can imitate a real user. Mature protection raises the cost through authentication, unpredictable identifiers, limits, behavioral signals, and blocking.

The historical negative offset central to the article is gone. The named feed_classic_api.php route no longer serves the product and returns 404. The current feed returns 401 without authentication. Applying that old scenario to today's architecture is not a current Mimolet analysis. It is a description of removed code.

History vs today

Old PHP files are not the current Mimolet architecture

The article repeatedly returns to the same routes and uses repetition to create a sense of scale. Three filenames are not three independent problems, and a removed entry point does not become the current API because its screenshot remains online.

This does not rewrite history: a current 404 cannot prove what happened on the test date. It proves a narrower, important point - that the cited path cannot honestly describe today's product.

Premium without sleight of hand

Liking a known profile and revealing incoming likes are different actions

The article calls the ability to like an already known user a "Premium bypass." But the subscription provides access to incoming-like mechanics: learning who liked you and using that inbox. It does not sell an exclusive right to express interest in someone already seen elsewhere.

The current free incoming-likes response does not reveal the real ID, name, or original media URL. Bulk response checks the subscription on the server. Combining "send a like" with "reveal an incoming like" creates a dramatic paragraph, not proof of a paid-feature bypass.

Sessions and bans

Multiple sessions are not session fixation, and an IP address is not a person

Session fixation is a specific attack in which a victim is forced to use an identifier already known to an attacker. Five logins from five contexts show only that multiple sessions are allowed. That is normal for phones, computers, and Telegram Web, not proof of account takeover.

The article's rigid IP-binding prescription breaks mobile networks, CGNAT, and VPN use. The current API checks blocked-user status on every authenticated request. That is the meaningful boundary. The assumption that one IP equals one person is not.