Repository for Supibot commands

commands repo.txt

1. Repo will be new, and separate from anything that concerns the `supibot-sql` repo 
  - (idea: supibot-sql is just a version control for whatever the main instance does)
2. Implement a method into `sb.Command` to "install" a new command from a description object
3. sb.Command.install will also handle duplicates - will update instead of failing (like now)
4. Repo command definitions will be in `.js` syntax as IIFEs that return a description object
5. Each command definition should be prefaced by an author/ownership comment
6. Think about some sort of authorship/source signature hash, not necessarily as a part of the definitiion but rather as a separate file or a list of hashsums in the root dir

3. sb.Command.install will also handle duplicates - will update instead of failing (like now)

IMO this should be a flag to not accidentally override a command.

each command could also have the source it was downloaded from in the table, making it easy to group

the problem I have with this is the data type, or rather uniqueness of the table's column values
let's say commands have sources Alice and Bob, would the Source column be a unique VARCHAR? or an ENUM?
ENUM seems to be out of question since we don't want to force people to update their tables on the go
a unique column would work alright I suppose

I would think of the source as the Github repository (username/repo_name) or even path to the command (username/repo_name/commands/command.js).

1. sb.Command.install will also handle duplicates - will update instead of failing (like now)

IMO this should be a flag to not accidentally override a command.

the best approach would imo probably to have flags for both

• installable commands (to separate commands that should not be installed remotely)
• overwritable commands (which along with the install flag would update themselves as needed)

I would think of the source as the Github repository (username/repo_name) or even path to the command (username/repo_name/commands/command.js).

does this mean there would always have to be two copies of a command? one in the "aggregate" repo and one in each author's repo?
i feel like custom version control repos shouldn't be connected to this repo