Cloud Sync recently gained a Google Drive backend (network/cloud_sync/google_drive.c, Feb 2026) alongside WebDAV/S3/SMB/iCloud, and #17972 unlocked SSL-backed sync on Android. OneDrive is one of the largest consumer clouds and currently has no backend — OneDrive users are the biggest unserved group left.
Proposal: network/cloud_sync/onedrive.c, structured directly on google_drive.c:
- Microsoft identity platform device-code flow — public client, notably no client secret needed (simpler than the Google flow)
- refresh token persisted in settings, same pattern as
google_drive_refresh_token
- storage via Microsoft Graph app folder (
/me/drive/special/approot) so RetroArch only sees its own folder; simple PUT …/content uploads (save files are small; upload sessions only needed >4 MB)
- same 5-function
cloud_sync_driver_t vtable, C89, -Wall clean, house style
Questions before any code is written:
- Is this a backend the team wants?
- Who registers/owns the (free) Azure app
client_id for official builds? A fork can use a personal registration for development, but production should be libretro-owned, like the Google credentials.
- Any preference on app-folder scope (
Files.ReadWrite.AppFolder) vs. broader drive access?
I can have the implementation contributed and tested on Android + Windows desktop. Transparency note: the implementation would be developed with AI assistance (Claude), with human review and on-device testing — flagging this up front; happy to discuss.
CC @warmenhoven (author of the webdav/gdrive/s3 backends and the Android TLS work). Related: #6875 (native cloud saving bounty). While testing the gdrive backend I also filed #19244 (folder-creation race) — happy to help verify fixes there too.
Cloud Sync recently gained a Google Drive backend (
network/cloud_sync/google_drive.c, Feb 2026) alongside WebDAV/S3/SMB/iCloud, and #17972 unlocked SSL-backed sync on Android. OneDrive is one of the largest consumer clouds and currently has no backend — OneDrive users are the biggest unserved group left.Proposal:
network/cloud_sync/onedrive.c, structured directly ongoogle_drive.c:google_drive_refresh_token/me/drive/special/approot) so RetroArch only sees its own folder; simplePUT …/contentuploads (save files are small; upload sessions only needed >4 MB)cloud_sync_driver_tvtable, C89,-Wallclean, house styleQuestions before any code is written:
client_idfor official builds? A fork can use a personal registration for development, but production should be libretro-owned, like the Google credentials.Files.ReadWrite.AppFolder) vs. broader drive access?I can have the implementation contributed and tested on Android + Windows desktop. Transparency note: the implementation would be developed with AI assistance (Claude), with human review and on-device testing — flagging this up front; happy to discuss.
CC @warmenhoven (author of the webdav/gdrive/s3 backends and the Android TLS work). Related: #6875 (native cloud saving bounty). While testing the gdrive backend I also filed #19244 (folder-creation race) — happy to help verify fixes there too.