[Feature] Native RetroArch Cloud Sync via WebDAV Server #2313

Is your feature request related to a problem? Please describe.

Some users enjoy their retro game collection across multiple devices (e.g., a primary PC, a handheld device like a Steam Deck, and an Android phone). While RomM already includes emulatorjs, it does not yet offer support for emulators on platforms like GameCube, Wii, 3DS, DSi, etc. As a result, we have to download the ROM and play it on a local emulator.

However, keeping save files (.srm) and save states (.state) synchronized between these devices is a manual and cumbersome process. It involves navigating to the emulator's save folder, finding the correct save file, uploading it to RomM, downloading it on the destination device, and then moving it to the correct directory. The alternative is to rely on third-party tools like Syncthing.

RomM already has a robust backend for managing user-specific assets (saves, states, screenshots), as seen in endpoints/saves.py and handler/filesystem/fs_asset_handler.py. The missing piece is a direct and automated bridge for client applications like RetroArch to use this system as a cloud backend.

Describe the solution you'd like

I propose implementing a WebDAV server endpoint within the RomM backend. This would allow RomM to act as a native cloud sync provider for RetroArch, which already has built-in WebDAV support. This would provide a seamless, integrated, and user-aware synchronization experience.

Here is how it would work from a user and technical perspective:

1. User Configuration in RetroArch:
   A user would configure their RetroArch "Cloud Sync" settings to point to their RomM instance, using their RomM credentials for authentication. The URL would be user-specific, for example:

   • Server URL: http://<romm-ip>:<port>/webdav/
   • Username: <romm_username>
   • Password: <romm_password>

2. WebDAV Endpoint in RomM:
   RomM would expose a new endpoint (e.g., /webdav/) that implements the WebDAV protocol. Authentication would be handled by RomM's existing user management system.

3. Virtual File System Abstraction:
   This is the key to making it user-friendly. While RomM internally stores assets in a structured path like ASSETS_BASE_PATH/users/{user_id}/saves/{platform_fs_slug}/{rom_id}/..., the WebDAV server should present a flattened, virtual directory structure that RetroArch expects.

   When a user connects via WebDAV, they should see a simple structure:

   /
   ├── saves/
   │   ├── Game A.srm
   │   └── Game B.srm
   ├── states/
   │   ├── Game A.state
   │   └── Game B.state
   └── ... (other RetroArch directories)
   

4. Backend Logic (Filename-to-ROM Mapping):
   When RetroArch uploads a file (e.g., PUT /webdav/myuser/saves/Super Mario 64.srm), the RomM backend would perform the following steps:

   • Authenticate the user myuser.
   • Receive the file and its virtual path (/saves/Super Mario 64.srm).
   • Perform a reverse lookup: Use the filename "Super Mario 64.srm" to find the corresponding rom_id in its database for that user. This might involve stripping tags and extensions and matching against fs_name_no_tags or name in the roms table.
   • Once the rom_id is identified, use the existing logic (similar to that in fs_asset_handler.py) to save the file to the correct internal path, associating it with the correct user_id, rom_id, and platform_id.

This solution would make RomM the central, authoritative hub for a user's entire emulation library, from management to gameplay progress, leveraging its multi-user capabilities perfectly.

Describe alternatives you've considered

• Continuing with third-party sync tools: This is the status quo. It's functional but clunky, lacks integration, and doesn't leverage RomM's user system.
• Creating a custom Cloud Sync driver for RetroArch: This would involve modifying the RetroArch C codebase to communicate with RomM's specific REST API. This is a much larger undertaking, would require constant maintenance to keep up with RetroArch updates, and is less universal than providing a standard protocol like WebDAV. Making the server (RomM) compliant with a standard is far more practical than making the client (RetroArch) aware of a custom server.

Additional context

Implementing a WebDAV server requires handling more than just GET and PUT requests. For RetroArch's sync logic (found in tasks/task_cloudsync.c) to work correctly, the server must properly implement other WebDAV methods, most importantly:

• PROPFIND: To list files and their properties (like modification time and size), which is essential for RetroArch's manifest-based diffing mechanism.
• MKCOL: To create directories (e.g., /saves/, /states/).
• DELETE: To remove files when they are deleted locally.
• MOVE: To handle renaming.