desired state / parsing of generated scripts or separate config about privacy.sexy HOT 1 OPEN

Thank you for nice comment at the end and good suggestions.

This is one of the most desired features, see #59. And we're slowly getting there.

However you suggest some new and great ideas that were never bourght of before:

1. What's new section. I'm not sure how the implementation will look like though. I see two potential solutions:

   • User metadata. privacy.sexy in that case needs to store all IDs (ID feature will be released in next release #262). Along with hashes of codes+revert codes. This can be stored in user metadata and once the file is imported, it can be compared to the new hashes. This way we can detect the changes. But it will miss newly added categories/scripts , we need to either write ALL existing IDs as metadata. This will bloat user metadata.
   • privacy.sexy internal data. Privacy.sexy internally stores hashes for scripts and the list of scripts in its previous versions. It checks the version field in user data (say an old version, 0.13.2) and compares that version against to current version to figure out the diff (changed scripts and newly added scripts). This will require some CI/CD to generate this data on each release. This sounds better.

2. Provide revert code along with the script. This can be commented out as you say, or a completely different file can be provided. A dialog is shown once the user clicks on "Download", we can show "Download revert script" on that screen. And for the desktop application, it already stores scripts you run, and it can automatically generate and store their revert scripts.

It would be very nice to have two different issues for these so we can track them, discuss separately and get actually implemented. I believe the main suggestion is duplicate of #59.

from privacy.sexy.