I'm sure you'll know by now that some time ago I did a full interview-ish effort with the dev team behind RomM. RomM - three our of five of the team gave me answers on their history of the project, emulation as a whole, self-hosting, ROMs and building what they did.
That RomM Project is an open-source, self-hosted application that's designed to organize and give you a nice, clean and pretty way to view and play your retro video game collections. Its got a clean, responsive web interface that allows users to scan their ROM libraries, then grabs the metadata from sources like IGDB, MobyGames, and Screenscraper, and playing games directly in your browser via built-in EmulatorJS support.
It supports over 400 gaming platforms (seriously), accommodates various naming conventions, multi-disk games, and custom tags. It even integrates with tools like Playnite and muOS, and upcoming features include device syncing for games, saves, and emulator settings.
I reached out to the team again about their new release for RomM - RomM 4.0.0, which also included at the same time a full Android app made by a community member. They agreed to share their thoughts and experiences putting it together with me, and while 24 or so hours ago I shared a full 'article' I wrote on this, based on these answers they gave me, I'm sharing their full answers here on Lemmy with you.
I write these little interviews, Q&As and articles with devs from all kinds of gaming, Linux and Steam Deck projects and programs. Its fun for me, and I love to help people get a peek behind the curtain, and get to know who is behind these bits of software they might know and love.
I've previous shared interviews on Lemmy with:
- The RomM Project (like I mentioned!) in general
- The solo dev behind Minigalaxy
- A PC game repacker (piracy!)
- The dev who runs a Switch piracy FreeShop
- Independent Linux & Gaming journalist, Gardiner Bryant
- The creator and dev of Lutris
- The team who make Heroic Games Launcher
- With RetroDECK
Do be warned, this is a little rough, since I intended to cherry-pick the quotes for an article, there are some general statements from one dev, then some direct answers to direct questions from another.
Regardless, I do hope you enjoy this!
With danblu3:
About the Android App:
Our main goal is to have RomM reachable from any platform, we want to be the centre piece of your retro library and an android app has always been an idea in the devs head. That said, the Android app is not something we claim (fully) an amazing user by the discord name of "MattSays" actually made the application and just dropped it into our discord one day without warning, we did have a very basic and functional version from a user called "samnwella" which did do the job, but it was clunky and I know they won't mind me saying this. MattSays dropped it and the UI was there, the functions was there, everything. It was gorgeous even from a 1.0 release. Community reaction has been positive, bugs have been raised and already squashed, and in relation to the RomM team both Zurdi and Arcane have reached out to MattSays for further discussion, it's currently being branded as the official Android connector app for RomM and as for team status for MattSays, that is up in the air. The future? It's definitely bright for the Android app, the dev is very keen and even wants to get save syncing up and running. Imagine this flow: Going into ES-DE and with the recent Android app launch update you open the RomM android app, using your controller you scroll to a game you fancy playing, press A and that's it, downloaded, you exit the app, back to es-de, scrape the game and play. No removed SD cards, no plugging into your PC, no dealing with SMB users or NFS perms, just, done. Dusted. The future is very bright for this app.
About the new 4.0.0 release:
Right. So. 4.0 4.0 from many different point of views is huge, from preservation enthusiasts, from retro nerds, from the people who just want a retro fix and the completionists, 4.0 is HUGE. Before I go on to say what 4.0 is let me explain about hash matching, I'll make this very simple and it's possible I might get something a little bit wrong here or there but the theory is correct. A hash is like a signature, and each ROM (file) has a unique signature, some people way back when began groups to dump these games in the name of preservation and put all this together into a library called .dats, these .dats files store a unique signature and this unique signature will match to a game name, it's development date, if it was ever released to retail etc etc. Two of the biggest names of these groups is NoIntro and Redump, they both specialise in different media formats but with them combined they built a "digital bible" of what game is what signature, with 4.0 we finally introduce hash matching with the help of two incredibly skilled developers. Why is hash matching better, why am I so excited?
- It's faster, much much faster. Right now when a ROM is scanned into RomM it breaks apart the file name, removes the (tags) and then sends an API call to the metadata agent of your choice with the name, even though we began to get a high success rate it relied HEAVILY on your files being named correctly.
With hash matching, ROM reads the unique signature of the file and is told near instantly what the game is and what data is needed to be scraped, without wasting time doing a fuzzy match.
- It's more accurate
The fact we can now match on hash means that you could have a game named "TLOZ: AltP.zip" which is a snes game from way back when and you named it like for ease of use, you load it into RomM and are confused why it doesn't match, you know it's the legend of zelda! But RomM does not, because of the weird name you chose, like come on? It's one of the best games, give it the full name! Anyway, with hash matching it'll look inside and see the game file, extract and work out the signature and instantly match it against the matching signature online, pulling all metadata and information it needs, without you needing to rename your whole collection.
- It's prettier - Now we have confidence in what your matching, we've made SteamgridDB a metadata agent, it was before but we left it to user decision. Now that we are confident in the matching we can pull gorgeous artwork for the matched games directly from SteamgridDB, and we still give user the choice if they want to change it.
Now that is out the way, I want to give a huge shout out to Yukine for making Playmatch and FlibbleHexEyes for making Hasheous both these technologies have been implemented in RomM and honestly they are flawless. Yukine has been a regular around discord and I'm pretty sure he began working on hash matching pretty damn quickly just for his own benefit, he then released a small tool which caught the eye of the RomM team, a few conversations later and here we are with it as a service. It's essentially a 2 in 1 service where it does the hash matching through a lighting quick database and then proxies that over to IGDB to pull the relevant metadata from their servers, all in record time compared to our API to IGDB route. Then onto FlibbleHexEyes, people who are around the self hosting scene might recognise the names, and yes he is the lead dev and creator of Gaseous, I would say a competitor but not really only because of how well we get on with him, the self hosted space is large and there is enough room for all of us, no point sniffling creativity! It's another hash matching service (we go from 0 to 2!) and it's similar in the vein of playmatch, just on its own location and maintained directly by Flibble.
Without these two amazing devs 4.0 would not be as huge as it is now. We have more news as well! In 4.0 we introduced launchbox support, this is essentially an offline database that is downloaded every day and used for matching. It does not do hash matching but it does fair better with ROM hacks on testing, it's also very good for people who want to control exactly what is coming in and out of their server as it does not need an API key and the queries are ran locally (until we go to LB to collect the art) Something that might have been missed is that we also support retro achievements! This is purely display purposes but if you have a matching hash, 9.9/10 you have a matching retro achievement and it will update your status on how your doing when it resyncs, it's a nice little QoL feature and we even show the difference between hardcore and soft core achievements. Want to help contribute? Well now it's now easier then ever with an official devcontainers RomM container, which will be explained further in the release notes but the environment is contained in the container, just pull it and start developing, no setting up extra libraries and so forth. 4.0 is huge for RomM. It's deserving of the major number and this has lit a fire under the dev team, I'm sure there will be a small hiatus between updates to let them recover but as we always keep saying. We're just getting started.
With Yukine (community member and contributor:
What changes are you making?
The main changes for RomM 4.0 besides adding new Metadata sources (like LaunchBox) is the integration of Playmatch and Hasheous I've created the Pull Request to add Playmatch Support into RomM and arcane added Hasheous support a little bit later Playmatch (and Hasheous too) is a Microservice which does Hash based matching for Roms, it incoperates DAT files from Groups such as No-Intro and Redump and keeps a database of those Roms with a mapping to external Gaming Databases such as IGDB, right now only IGDB is support but i plan to add other Gaming Databases such as Screenscraper, MobyGames, Launchbox, SteamGridDB and more
How was your experience, making these changes with RomM?
The Pull Request to RomM wasn't really all that hard, even me who doesn't usually do or write python was able to integrate it quite easily into RomM that said there was work the RomM Team did before my change was merged to ensure that the logic runs in the correct order What i mean by that is that in RomM 3.10.x it used to be so that the resolution step of Metadata was running before the calcuation of hashes When you integrate services which require you to send the hashes of files for the metadata provider resolution you usually want these hashes calculated which before wasn't possible because Matching of Metadata Provider was running before the hash calculation step After arcaneasada changed that and did some other side work the Playmatch PR was quite fast ready to be merged, i think it took less than 2 weeks to get it merged into RomM
How long has this release been 'in the works' for?
As i said above the PR itself was only ~2 weeks of work but Playmatch itself was quite a lot more work I've started Playmatch back in June 2024 (over a year ago already ) as a side Project of mine, at the time RomM was quite a bit more immature especially the Metadata Matching part, i personally have quite a big Rom collection and when only ~40% of all games got a match on IGDB i was quite annoyed because i didn't want to go through my whole collection and manually match all the unidentified games to get the nice looking metadata for them Out of annoyance i thought how i would fix that, thinking about other Projects who also use Metadata Providers i checked out how they solved it and then i also found Hasheous at the time which basically was @FlibblesHexEyes Solution to the issue. After checking it out i decided that while i know C# and i think he did a good Job i wasn't quite sure if i would've solved it this way and the database structure of it wasn't quite speaking to me (when i thought about performance and how many req/s it would likely get) so i decided that i could probably write a small microservice myself and i oriented myself at Hasheous but also at Skyhook which is a Metadata API Sonarr uses and how they solved a lot of issues with that
What can the users, both existing and new, expect from this 4.0.0 release?
Generally speaking 4.0 with Playmatch and Hasheous enabled should improve Automatic Metadata matchinig a lot. When users enable them they will be queried for each rom and if either has a metadata match in there database it will be used This makes RomM a lot less reliant on Rom Names and exact naming matches and basically kills the naming requirement completely assuming the Rom Hash is in either Playmatch and Hasheous (usually if your ROM matches the No-Intro or Redump DAT thats the case) and has a Provider match in either. Playmatch does by default automatically try to match ROMs it gets from the dat files to IGDB but sometimes that also fails when for example the ROM name is localized and on IGDB there is no Alias for that name. Playmatch also allows users to "suggest" manual mappings for No-Intro/Redump roms, if a rom was not automatically mapped due to naming issues i described before users can now use a Discord Bot to suggest a mapping to be added to Playmatch, after an Admin (currently thats me) reviews it and approves it it'll be added to playmatch and RomM can make use of it This Discord Bot is also added to the RomM Server so that users can do the suggestion there if they like to, this also helps out the whole community (so when the next person then checks playmatch for the same hash it already has a mapping!) which is generally the ideal state that the community can "maintain" a mapping database themself
Any significant difficulties? Anything you're particularly proud of with this release?
There were a lot of difficulties to be fair but thats normal Playmatch is written in Rust which is a Memory Safe Language and a very fast and performant language too. When i initially thought about how i would create Playmatch i had a few key aspects in Mind.
It needs to be fast and handle a lot of http req/s when a lot of RomM users run library scans
It should keep a low memory usage so i can run on a small VPSIt should have a good Database ORM because i dislike writing raw SQL queries in code generally My choices were between Rust, Golang and C# but i decided for Rust because the HTTP Server Actix im using has decently fast benchmarks, the language can run a http api on only a few MB ram and also the Database Driver im using (SeaORM) is great and very fast for database queries Playmatch does a lot of things automatically by now, it can automatically download & import dats and after import also automatically try to match unmatched games to IGDB for example the matching logic is also decently smart, the datting group No-Intro for example has a cloneof id relationship set in there dat file, basically if a game like Pokemon Emerald has multiple versions (different regions, Demos, Betas etc) they write it down in the dat file with an id and a clone of id field, Playmatch can make usage of that and use it for matching, if any game gets matched playmatch automatically matches the games parents and of the parent other child games as well so that if i manually match lets say No-Intros German Pokemon Platin ROM playmatch will check the database and see that other roms (Like the Italy Pokemon Platin Rom) is a clone of the same parent (The Europe or USA Pokemon Platin Rom usually) and then apply the same mapping to it as well For automatically matches this is a great benefit, like if one of the different region name is either the Direct Name or an Alias of the Game on IGDB then we can match all versions of a game This fixes the issue for localized rom naming a lot as well, if you use any Rom Manager or tool which renames your ROMs to match names from No-Intro/Redump dats this will now not make the Identify step of RomM fail because the name is localized and not like that on IGDB and also if one region gets matched now all region gets matched! this makes it less annoying to manually match as well when instead of 20 matches for all different versions (Regions, Beta, different Revisions) of Pokemon Platin you just match any of it and Playmatch does the other one fully automatically Another big issue generally is compression, RomM does not enforce any format when accepting ROM files for Platforms, users usually want to compress there roms if possible to save space zipping Roms is one way but usually the compression rate is not that good especially for newer consoles with for example encryption (which decreases compression rate by a ton) so most Homebrew Communities have developed own formats to compress ROMs a few examples are Wii / Gamecube raw format is .iso and the a common compression format is .rvz which is supported by Dolpin Emulator Wii U Raw format is .ISO but the common compression format is .wux A lot of Disc based system Emulators support .chd files which is a format the MAME team developed with a very good compression rate DAT groups such as No-Intro and Redump usually only create dat files for "RAW" or original formats so if you want to compress your roms it will not be matching to Playmatch anymore as Playmatch only holds rom data which is from a DAT group Luckly the Community already has made DAT files for a few of those formats but depending on the format and compression used these formats might have some randomness depending on what compression level and settings are used Playmatch currently has community dats for .rvz, .wux and decrypted PS3 Games
With FlibblesHexEyes - community member and contributor:
Hey! So, just to clarify I'm not part of the Romm team, though I do work closely with them.
I work on Hasheous (https://hasheous.org/), which provides hash based ROM matching to metadata providers as well as metadata proxying.
Hasheous came about from my other project called Gaseous Server (which is similar to Romm - started about the same time) where I noticed a major point of friction for users was matching their ROM files to metadata providers such as IGDB.
This led me to begin the Hasheous project where a user adding a ROM to their ROM Manager of choice (Hasheous was always designed to be client agnostic and not favour one client over another).
The idea here is that when adding a ROM, instead of the user having to manually say that file is "Choplifter", the client (Romm or Gaseous), would reach out to Hasheous and say "do you know what this file with this SHA1 hash is?" and Hasheous would respond with information about the ROM and where the client could find metadata such as summaries, and cover art.
Which led to solving a further point of friction for users which is that many metadata providers require an API key - and an often convoluted method to generate them - which led to Hasheous having the ability to proxy some metadata providers.
This allows users of Romm (and others) to have a completely friction free experience when adding ROMs to their libraries. It's this part that I'm particularly proud of.
It's taken me about a year to get Hasheous to where it is today. By far the biggest issue is that of data integrity. Hasheous relies on DAT providers (such as TOSEC and NoIntro) who all name games slightly differently. The same is also true of the metadata providers. Examples include that a DAT might name a game with a dash, which the metadata provider might use a colon. Individually these are reasonably easy to match, but at scale it gets a lot harder. So building out a community contribution method (to fix bad matches) that is abuse resistant was also a challenge.
With MattSays - community member and developer responsible for the Android app:
Yeah sure! You may want to know why I decided to make this app. I recently got into retrogaming handhelds and in particular Android retro handhelds, and I also discovered the existence of RomM. However, to my surprise there wasn't an app that could easily handle all of my rom collection without having to go to my browser and manually do all the steps required to just play my desired games. So I developed a client that could improve the usability of RomM on Android without too much hassle and shared all of this with the charming community that instantly tested it and gave me precious feedback.
And that's that!
Well, like I said, perhaps a little rougher than my regular efforts at these, but the contents in the answers really did deserve to be read through, but anyone interested. I love how passionate about gaming, self-hosting and emulation the team (and contributors) are in RomM. It makes me smile to see!
You can find more on The RomM Project with these links:
And don't forget, if you like this kind of gaming nonsense I share, you can find me on Mastodon, where I tend to post every day:

That's really kind of you! Don't expect to be inundated, it'll be a weekly thing for whoever is in the fediverse scene, loves gaming, tech and so on, and wishes to contribute articles. I think it's fun, so I'm glad you gave it a nod of approval!
Thanks :)