Updates ✨

• Added SQLite storage backend as an alternative to YAML for better performance on large servers.
• Introduced /lmbmigrate command to safely move mail data between YAML and SQLite storage backends.
• Added new storage.yml configuration file for backend selection.

Fixes 🛠️

• Improved mail querying performance and scalability for servers with large mail volumes.
• Enhanced error handling and validation throughout the storage system.

Changes 🔄

• Redesigned storage layer with repository pattern for cleaner code architecture and future expandability.
• Enhanced command alias system with support for multiple aliases from configuration.
• Centralized mail logic to reduce code duplication and improve maintainability.

Notes 📌

• Existing YAML installations continue working unchanged—SQLite is opt-in via the new storage.yml file.
• SQLite is recommended for servers with high mail volumes (1000+ mails) due to better query performance and scalability.
• Migration between backends requires empty target storage to prevent data loss—always backup before switching.
• All existing GUI configurations and features work identically with both storage backends.
• Use the /lmbmigrate command to transfer data between storage types—automatic import has been removed for safety.

Storage Configuration Example

# storage.yml - New configuration file
storage:
  type: sqlite  # or yaml

Migration Command Usage

/lmbmigrate yaml sqlite    # Move from YAML to SQLite
/lmbmigrate sqlite yaml    # Move from SQLite to YAML