Idea: Separate "account values" database table

[dgw]

I was thinking about adding support for trigger.account to some of my plugins, and realized that at least some IRCd implementations will likely have separate namespaces for nicknames and accounts. Since the account name is only for authentication, it doesn't necessarily correspond to any of the nicknames registered under it.

Overwriting "nick values" data by accident is undesirable behavior, and it would be very simple to add another table to the database for "account values". Such a new table would also allow plugins to store data that's only accessible to the user after authenticating to services.

Downsides are the same as other features that depend on accounts: many use-cases of this would require the network to support one of the capabilities Sopel needs to track accounts.

I'm not putting this in a milestone yet. I'll wait for @sopel-irc/rockstars to tell me why it's a dumb idea first. 😀

[half-duplex]

I like the idea, but I'm concerned that having separate "nick" and "account" tables and expecting plugin authors to always manage them correctly will be.. wishful thinking.
Could we present an abstraction that allows plugins to use accounts if available and nicks if not, and maybe auto-migrates things if a server gains account support, and recommend use of that one over account/nick? Then plugin authors don't have to care for most cases, and it's less confusing and error-prone (e.g. plugin written for account explodes when used on server without account tag support).

The one problem with this that comes to mind is if a user has one services account with multiple grouped nicks, uses the nicks as different personas, and expects plugins to remember different settings for each persona/nick.