User Preferences Feature

[kevinthedang]

Idea

• With new features coming out, it would be nice to allow users to have their own preferences
  • For example, if a user does not like using the @ feature then they can toggle it.
• So, basically we can implement specific preferences and create general ones and label theme as themes to reduce the complexity of changing the settings
• Another idea might be to display preferences so if they want to save their preferences to make it easy to switch between them
• Preferences will be tied to users, to create some kind of thing to work with this, might just allow the server to spin up it's own database to store it's data.
  • When a conversation dies (or time passes), data entries can be removed from the database to reduce the load on the model that ollama is running

Possible Solution

• Slash commands to set user preferences
  • Examples:
  • /set mention off (something like that, I am not sure how slash commands work yet!)
  • /set message-style embed (or normal)
  • /set stream true (or false as this is a very slow feature)
  • /set threads 8 (by default it will be 4)
  • etc ...

• It would also be nice if we could do it in bulk, but that might not be very easy or user-friendly
  • Likely the resolution for this is to provide a generic slash command to set all of these
  • /set theme coding
  • /set theme general
  • /set theme images

[kevinthedang]

Update

• Refer to #12 for skeleton structure to create slash commands
• This is the first step of however many (hopefully of 3 or 4) to allow users to have a preference

[JT2M0L3Y]

Concurrently running API and client with the npm run start command may result in the above issue with deleting and registering commands.

[kevinthedang]

Since we've added Docker to the project, start has been removed, but it can be readded back into the project for instances where people might not want to run Docker for some reason... or we just make people run the application in docker... who knows for now. Better friendly than not.

Issue above still persists even on development run. It seems like the commands are registered then deleted immediately, even if embed is registered after the deletion... odd. I will try to do some investigating when I can.

It seems like running it twice fixes the issue as it runs like this:

• Run 1: Delete the bot commands
• Run 2: Register bot commands

However, we don't want that. It should run in 1 seamless go.

[kevinthedang]

A fix for this has been implemented and will be in the next release for user preferences!