request: package rating system

[FivelSystems]

Feature Request: Portable Ratings & Metadata System

🚀 Proposal

Implement a system to allow users to rate (1-5 stars) and favorite .var packages within the application.
Crucially, this system must maintain the portability of the application and avoid cluttering the user's content library with sidecar files.

💡 Rationale

Users with large libraries need ways to organize and curate content beyond simple folder structures.

• "Which of these 50 hair packages is the good one?"
• "I want to quickly filter for my 'Favorite' scenes."
  Rating/Favoriting is a standard feature in most asset managers (e.g., XnView, Adobe Bridge) and highly requested.

🛠️ Technical Design

1. Centralized Metadata Storage

Instead of writing metadata files (e.g., .var.rating) into the user's content folders—which creates clutter—we will store all user-generated metadata in a centralized database within the application's config directory.

• Storage: A simple JSON or SQLite database stored in the user's AppData/Config profile.
• Zero Clutter: The user's AddonPackages folders remain untouched.

2. Identity Strategy: "Family-First" Rating

How do we identify a package?

• ❌ By File Hash: Not recommended. If a user rates "Tool v1.0" and then updates to "Tool v1.1", the hash changes, and the rating is lost.
• ✅ By Package Family (Creator.PackageName): Recommended.
  • Logic: Ratings are keyed to the Creator.PackageName string (e.g., AcidBubbles.Glance).
  • Benefit: Ratings persist across version updates. If a user rates a package 5 stars, that rating applies to the package "concept," regardless of the specific version installed.

3. Portability (The Challenge)

Since ratings are stored in AppData, moving just the executable/library to a new PC would normally lose them.

• Solution: Implement a "Profile Export/Import" feature.
• Workflow: Users can export a strictly defined yavam_profile.zip containing their config, themes, and this metadata database. This makes the "state" of the app portable without enforcing a portable installation on the file system level.

✅ Pros

• Clean Library: No sidecar files (no .xml, .json cluttering up AddonPackages).
• Persistent Ratings: Ratings survive package updates (v1 -> v2).
• Portable: Profile export allows carrying ratings to new machines.

⚠️ Challenges / Risks

• Creator Renames: If a creator changes their name or the package name significantly (e.g., PluginV1 -> PluginV2), the link is lost. (Acceptable edge case).
• Database Management: As the library grows to 10k+ items, the JSON lookup must remain performant, or we may need to use SQLite.

Originally requested at VaM Hub Discussion Thread