provide a mechanism for verifying multiple affiliations

[JRHaigh]

This is to address the reason for wanting dual-cloaks in a different manner, and to extend it to an arbitrary number of current group affiliations. This is to allow, for example, users to verify that someone is a staff member or other trusted representative of a project or organisation, even if that person is affiliated with multiple groups.
    In this issue report, I'll use the term ‘cloak’ to refer to that item which a user can use to prove to other network users that they are currently affiliated with a particular group. The mechanism is not necessarily related to the existing hostname cloaking system where only 1 cloak (aka. vhost) is allowed at a particular time, but it probably makes sense to be related to that somehow.
    The overall operation is as follows:

• For cloaks to be added to an account, both the user and the group manager must agree to the issuance. That could be in the form of ‘group manager **offer**s and user **accept**s’ or ‘user **request**s and group manager **grant**s’.
• For cloaks to be removed from an account, either the user can return a cloak or a group manager can revoke it. In either case, the other party is notified; the user is notified that the cloak has been revoked, or the group manager/contact is notified that the cloak has been returned.
• Network staff should be relieved from the burden of being involved with third-party cloak issuance and removal. I.e. all except for those related to the network itself. However, notifications of affiliation changes may be desirable.
• All cloaks that a user has must be publicly visible/accessible up until removal, probably by querying NickServ with the info command, and maybe other ways too. They are not to be used to arbitrarily hide or show affiliations at will. Either the user is affiliated or they are not. If the user removes a cloak but then wants it back then they have to rerequest it from a group manager.

[errietta]

Fuchs commented in #136

As a operator or user when talking to someone on freenode, i would like to be able to check that they do have a recognised affiliation with a group without having to rely on cloaks.

Sample use case: a person might be affiliated with various groups, but only wears the cloak of one. I need to know whether that user is also affiliated with a different project.

Further reading: discussion in #freenode-gms, 2016/02/15, 22:15 UTC

[JRHaigh]

I wrote this not realising that GMS doesn't currently have an IRC interface (like what Atheme services does in the form of NickServ, ChanServ, MemoServ, etc.). The suggested PRIVMSG command words are only relevant in the context of such an interface, see #138.

[JRHaigh]

“The mechanism is not necessarily related to the existing hostname cloaking system where only 1 cloak (aka. vhost) is allowed at a particular time, but it probably makes sense to be related to that somehow.”

Having multiple cloaks associated with an account would actually solve the problem of what to do about the vhost if a group wants to immediately revoke an affiliation cloak.
    If the set of affiliation cloaks is put into an order, i.e. listed, then this cloak list can be used as a fallback stack. The first item in the list is the primary cloak, which always corresponds to the vhost. As such, it has the same limitations as the vhost, that the user cannot reorder it without staff permission. However, they may reorder the cloaks below the primary however they wish.
    If a group manager revokes an affiliation cloak that was used as the primary then the vhost would automatically change to the cloak that was previously the second element of the list. Likewise, if the user returns the cloak that they have as their primary then, again, the vhost would automatically fall-back to the second element. Network staff may be notified of the vhost change.
    When a new affiliation cloak is added, the user should have a choice as to whether it be the primary or not. If there was an IRC interface, this could be in the form of a numeric argument to the accept or request commands, where positive numbers count from the start of the list, 1 being the primary, and negative numbers count back from the end of the list, -1 being the last position. Whether network staff must approve new cloaks depends on the group's flags, see #124.

[JRHaigh]

The meaning of an ‘unaffiliated’ cloak in the context of multiple cloaks would have to be considered if that were to be used. You cannot easily prove that you are not affiliated with any organisation anyway, so what exactly is the point of it?
    Should it be renamed to something that doesn't imply that there can't be other affiliation cloaks in the list (e.g. ‘miscellaneous’)? I.e., even people who have multiple cloaks can keep their miscellaneous cloak, which they may still prefer as their primary if they are only loosely involved in the various groups that they have cloaks from.

[JRHaigh]

I like this idea of miscellaneous affiliation. :-) Particularly in a world where it is not feasible to prove if someone is unaffiliated, or even properly define what ‘unaffiliated’ actually means.