Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User Preferences vs Server Preferences #36

Closed
kevinthedang opened this issue Apr 3, 2024 · 8 comments · Fixed by #80
Closed

User Preferences vs Server Preferences #36

kevinthedang opened this issue Apr 3, 2024 · 8 comments · Fixed by #80
Assignees
Labels
enhancement New feature or request

Comments

@kevinthedang
Copy link
Owner

Issue

  • The current implementation of "User Preferences" works but applies on a server level, meaning it applies to everyone in that server.

Solutions

  • Create a system for distributing configurations based on someones discord username.
    • The following is an idea of how to store via json
{
  "name": "Discord Ollama Confirgurations",
  "servers": {
    "server1": {
      "toggle-chat": true
    },
    "server2": {
      "toggle-chat": false
    }
  },
  "users": {
    "user1": {
      "options": {
        "message-style": false,
        "modify-capacity": 10
      }
    },
    "user2": {
      "options": {
        "message-style": false,
        "modify-capacity": 20
      }
    },
    "user3": {
      "options": {
        "message-style": false,
        "modify-capacity": 30
      }
    }
  }
}
  • We would have to separate by servers and users for consistency if the bot was used in different servers. Is that likely? Who knows as it is not really accounted for in our scope as a Multi-Server Bot. The Bot is to be hosted by an individual for their purposes only/servers.
    • Idea 2:
{
  "name": "Discord Ollama Confirgurations",
  "servers": {
    "server_name1": {
      "toggle-chat": true,
      "users": {
        "user1": {
          "options": {
            "message-style": false,
            "modify-capacity": 10
          }
        },
        "user2": {
          "options": {
            "message-style": true,
            "modify-capacity": 20
          }
        }
      }
    },
    "server_name2": {
      "toggle-chat": false
      "users": {
        "user3": {
          "options": {
            "message-style": false,
            "modify-capacity": 30
          }
        },
        "user4": {
          "options": {
            "message-style": true,
            "modify-capacity": 40
          }
        }
      }
    }
  },
}
  • Next idea would be storing in different files in a folder in the containers as server_name.json for that servers configurations in a config/ folder.
    • Then a server will only need to look for their own config files and try to run them.
    • We could also use some more preferences... brainstorming time...
@kevinthedang kevinthedang added the enhancement New feature or request label Apr 3, 2024
@JT2M0L3Y
Copy link
Collaborator

JT2M0L3Y commented Apr 4, 2024

One idea here is to use the roles feature to issue roles for certain permissions to each user that may need one or want one. This can be an admin-level slash command.

@kevinthedang
Copy link
Owner Author

@JT2M0L3Y

Referring #13 as it should also include this because of the Redis dependency we are likely adding for performance and storage.

@kevinthedang
Copy link
Owner Author

Thoughts:

  • I just want to mention Recognize Administrator Roles #31 when implementing this as "role-based" commands have been implemented but only for admins.
  • For dynamicly understanding server roles, we can have the bot scrape the roles whenever they are edited. How do we do that? Not sure right now, but it's an idea.
  • Besides administrators? What is the point of caring about roles?
  • Instead of 1 huge json file, we can have separate json files and look for them. This idea is just following a tree structure for files rather than 1 massive file. Either way works.

@JT2M0L3Y

@JT2M0L3Y
Copy link
Collaborator

JT2M0L3Y commented Jun 6, 2024

Update:

We could store the entire contents of the aforementioned JSON file as a value in Redis and link it to a "user preferences" key.

However, this means we would be caching a new set of user preferences for the entire server and calling the entire JSON each time we update or check for a user preference.

@kevinthedang
Copy link
Owner Author

My Idea for a new approach, have a configs.json file and store everything there for now... or we create separate files to support the Redis caching we plan on doing.

My initial thoughts:

export interface UserConfiguration {
    'message-stream'?: boolean,
    'message-style'?: boolean,
    'modify-capacity': number
}

export interface ServerConfiguration {
    'toggle-chat'?: boolean,
    'channel-toggle'?: boolean
}

/**
 * Parent Configuration interface
 * 
 * @see serverOptions server settings per guild
 * @see userConfigurations user configurations (only for the user for any server)
 */
export interface Configuration {
    readonly name: string
    serverOptions: {
        [guildId: string]: ServerConfiguration
    },
    userConfigurations: {
        [username: string]: UserConfiguration
    }
}

The Redis plan would look similar, but instead of 1 file, it's just multiple files for users and servers (or 1 file for servers idk). This allows the bot to be compatible for multiple servers with their own settings and for users having their own settings.

@JT2M0L3Y

@JT2M0L3Y
Copy link
Collaborator

JT2M0L3Y commented Jul 2, 2024

I only have one concern, about the definition of each configuration.

  • Does modify-capacity require a user to set it? (there's a default capacity, if I remember correctly)
  • Should setting toggle-chat be optional?

@kevinthedang
Copy link
Owner Author

  1. No. It will always default to 5 for performance's sake.
  2. I mean we can. If you want?

@JT2M0L3Y

@kevinthedang
Copy link
Owner Author

For now I will develop them separately:

  1. User Preferences file
  2. Server Preferences file

If you have any other questions just let me know.

@JT2M0L3Y

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants