Allow custom prompts through environment variables

[poculeka]

Description

This PR introduces prompt customization through environment variables mentioned in #1018.
It solves issues with local language models being incompatible with prompts hardcoded inside the application.
This feature is backward compatible - if none of new environment variables is defined, Hoarder should behave exactly as it behaved before.

Technical details

3 new optional environment variables are defined:

• TAGGING_PROMPT - tag generation for text content,
• IMAGE_PROMPT - tag generation for images,
• SUMMARIZATION_PROMPT - summarizing text.

Default prompts are moved into config.ts and they are used if corresponding environment variables were not defined.

Filling prompts with data

In current solution, content is being inflated into the prompt text using string interpolation. Since there is no string interpolation in environment variables, I introduced markers which are replaced by actual values when building a prompt. The marker values are:

• tags,
• aiTags,
• userTags,
• lang,
• customPrompts (tagging rules),
• content.

Values tags, aiTags, userTags existed before and were used in "Tagging Rules" feature.
However, I decided to change current markers from using dollar sign ($variableName) to doubled curly braces ({{ variableName }}), because dollar sign would have to be escaped when defined inside .env file (I'm not insisting on this, we can discuss other templating solutions). To keep backward compatibility, markers tags, aiTags and userTags can also be defined with dollar-sign notation.

Custom prompts through env variables vs custom prompts using tagging rules

Hoarder already allows some customization in prompts using "tagging rules" in AI settings. However, tagging rules don't change the entire prompt. But I don't think these features would be in conflict with each other - custom prompt defined through environment variable sets the prompt template for the entire Hoarder instance, while tagging rules are additional per-user settings which could be inflated into the global prompt template with {{ customPrompts }} marker. In this way they supplement each other.

[MohamedBassem]

@poculeka Hey, I really appreciate the effort you put into this PR, but unfortunately, I'm intentionally not giving the people the ability to customize the entire prompt because this give me more flexibility to change it in the future without breaking things. For example, if I want to add automatic summariziation to the tagging prompt, I wouldn't be able to do it if people have overriden my original prompt. I want to give people control only over the rules not the prompt structure itself. If I allowed you to disable some of the pre-packaged rules would that be good enough for you?
I'm again really sorry you put so much effort into that, but I'd really suggest you join us in the #development channel on discord so that we can be aligned on features before you put effort into implementing them.

[poculeka]

Hey, @MohamedBassem, no worries! I decided to open a PR, because I'm already using this code in my instance of Hoarder, so I don't feel like it's a wasted effort. Plus, this was the first time in when I did something webdev-related, so I learned something new :)

Going back to the topic - I think even if disabling some of the pre-packaged rules helped me, there would still exist other users needing deeper customization - I don't know if it's worth the effort.

Let me understand the argument about flexibility better - are you worried that if, in the future, expected response structure changes (together with the prompt), then overriden prompts will stop working? If that's the case, I'd say it is responsibility of owner of the Hoarder instance to keep prompts working with the rest of the application. And this is what I had in mind while developing this feature - the default prompt remains unchanged and it is only possible to change it through an environment variable. A regular user is not able to change anything other than tagging rules.

Additionally, both OpenAI (click) and Ollama (click) requests can be configured in such way that they adhere to supplied JSON schema (this is different than response_format: { type: "json_object" }). Structured outputs might be worth looking into, even if this PR will not be merged.

Anyway, this is a great project - keep up the good work!