Shared API service/key name board

Community Proposals
#1

I’m not really sure if this one has to be implemented, but that’s an idea that could help Cog Creator if they’re using the Shared API key of Red.

Also, it’s preferable to add it in cogs.red when it will be finished. I explain why after some explanation.

So basically, this board will get the name and the used key (Or client ID, secret or things like that) that a cog will use. Like, if the cog use youtube to get api_key, then it will show something like this :
X cogs is using **youtube** for getting **api_key**, and so on.

It can be useful if a Cog Creator need to make a cog and will use an API, I’m thinking to KSoft.Si, it can be confusing between CC (Cog Creator), because some could ask users to register they’re API key with the name ksoft and another CC could tell to register his API key with the ksoftsi name, so the user will register 2 time his keys for the same thing.

With this board, CC will know who already use a possible service name, and make his cog using the same service’s name.
It will be added in the info.json of the cog.
That’s to avoid trouble of users and also Cog Creator.

So as I said upper, it should be added only to cogs.red, because this website already use a system like that, with tags, and it should be easier than doing it here, manually I suppose.
That’s everything for me, I let you all decide of that.

If I was unclear, not comprehensible, or things like that, the contact is the solution.

#2

Hi! This is already a thing in Red. Check out the documentation for it here https://red-discordbot.readthedocs.io/en/stable/framework_apikeys.html .

#3

I will expand upon this after discussion in DM. QA will enforce cog creators declare if an API service is paid and the cogs have some way of explaining how to setup the API.

Utilizing the shared API service is not enforced but the documentation on how to use it suggests how it should be done.

There needs to be some consistency between cog creators when using shared API keys between cogs. To help make this easier service should be all lowercase and the key names should match the naming convetion of the API being accessed.

It’s up to the cog creator to ensure they’re following the documented guidelines for naming convention of keys but it’s not going to be enforced. A cog creator may ensure no other cog is utilizing the same key by naming whatever they want. The tools are there to make end users lives easier by supplying one key and using it on multiple cogs but it is not required.

The tags system will be added to cogs.red when it’s ready but that is still up to the cog creator to add the tags they want included in their info.json file.