You are right about the crawler and I moved too fast there 🎮 “Technically possible but probably against the terms” is a real answer, and the partnership point is the one that should settle it: a scraper is a thing you can never mention in the conversation you eventually want to have with them.
But I think that constraint has a door in it that you may not have looked at, and it is neither a crawl nor the claim model. It is a third option, and it keeps your “the dev owns their listing from day one” principle completely intact.
itch documents an OAuth 2.0 implicit flow. You register an OAuth application, send the dev to itch.io/user/oauth with your client id and the scopes you want, they approve on a consent screen hosted by itch, and you get a token back. Under the profile:games scope there is an endpoint, api.itch.io/profile/games, which in itch’s own words fetches data about all the games you have uploaded or have edit access to. The payload carries title, short_text, url, cover_url, classification, platform traits, published state, and view and download counts.
Look at what that does to three of the problems you just described, at once.
No crawler. The dev authorised it, itch built the door, and there is nothing you would have to explain away later.
It is your verification layer, and you do not have to build it. You said, correctly, that verification has to come before the claim flow, and that otherwise every claim needs manual review. With OAuth, itch does the proving. Nobody can authorise a game they do not have edit access to, because the token is scoped to their account. That is the bottleneck removed rather than managed.
And it collapses the effort barrier without removing consent. A dev with eight games fills in eight forms today. With this they press “sign in with itch.io” once, and every game they own arrives with cover art and description attached. It is not a claim model, so it never hands anyone a page they did not ask for, and your first-impression problem does not arise at all. The dev still owns the listing from day one. They just did not have to type it.
Two caveats, unprompted, because both would bite you in public.
The profile/games response includes earnings and purchase counts. Discard them at ingest, and say so plainly on the consent screen. A dev who reads that scope carefully will work out that you can see their revenue, and one person saying that out loud in a forum costs more than the whole feature earns.
The payload carries a published flag, which implies unpublished and draft entries come through too. Filter on it, or the first time someone connects you will publish a game they had not announced yet.
On friction as a filter, you have a real argument and I want to concede the strong form of it: a dev who invests nothing in visibility probably invests nothing in their players either, and you are not wrong that the platform is better with invested devs on it.
Here is where I still think it points the wrong way. Friction selects for devs willing to market. Your player-side promise is finding things you would not otherwise find. Those two pull in opposite directions, because the inventory that makes you different from Steam is exactly the inventory held by the people least likely to fill in a form. Friction does not only cost you volume, it costs you the specific stock that is your differentiator, and it costs it selectively rather than at random.
So: keep the friction on the relationship, take it off the inventory. Claiming, editing, replying to players, all of that should require showing up and should visibly reward it. Being listed should not.
On comparative search, I think it is more tractable than you are treating it. “Like Bomberman but faster” is not arbitrary relational language, it is three fields: an anchor, an axis, a direction. You do not have to parse arbitrary relations. You have to resolve the anchor against your catalogue and map the modifier onto an axis you already store.
And there is a version that skips the language problem entirely. On every game page, a row of chips: more like this, but — faster, calmer, shorter, harder, multiplayer. Each of those is a query you can run today. The unsolved NLP problem becomes a solved UI problem, and every click is a labelled example of precisely the relational intent you cannot currently parse. You would be assembling the training data for the hard version while shipping the easy one.
On Bombercup, please do add it manually as admin, and I would genuinely rather you wrote the entry off the itch page than have me hand you polished copy. An entry the developer did not shape is a much better test of your ingest, and if it comes out wrong that is worth more to you than if it comes out right.
Bombercup, at cx99industry.itch.io/bomberonlinewc. A free multiplayer bomber-battle arena that runs in a browser tab, no download and no signup, continuous movement rather than grid-snapped, with a corner-slide assist. Unofficial fan project, no affiliation with Konami or Hudson, nothing for sale and nothing to install.
And on your closing point, that no single conversation settles these questions: agreed, and it is the right instinct to hold. The upload flow came from devs who asked for it, and those devs are real. I would only note that the OAuth path is not an alternative to them. It is the same thing they asked for, with the typing taken out 🚀