Abstract RGB File Persistence to KVStore

[dcorral]

This proposal discusses abstracting the RGB-related file persistence in lightning/src/rgb_utils/mod.rs to use the existing KVStoreSync trait instead of direct filesystem operations. This would allow RGB data to be stored in a database (or any KVStoreSync implementation) alongside other LDK data.

Currently, RGB-related data is persisted directly to the filesystem using std::fs operations, while other LDK data (channel monitors, channel manager, etc.) uses the KVStoreSync trait abstraction. This creates an inconsistency:

• LDK data: Uses KVStoreSync → can be backed by filesystem, database, or custom storage
• RGB data: Hardcoded to filesystem → limited to file-based storage only

For applications that want to use a database backend (e.g., SQLite via Sea-ORM) for all LDK persistence, the RGB files remain on the filesystem, requiring hybrid storage management.

Proposal

• Refactor RGB persistence functions to use KVStoreSync with RGB-specific namespaces or fallback to fs for backwards compatibility.
• Functions would change from path-based to KVStore-based or keep both for backwards compatibility.

The main question for discussion is whether this change should be backwards compatible or a clean break.

Once we agree on the approach, I can prepare and submit a PR.