Groups in Bivouac are loose collections of users defined in Crew documents. Group names are non-global and groups can be forked.
Groups in Bivouac are noted with a double @ sign, like @@coolhackers.alice.phish.
Groups have special meaning as they can contain roles within them, that can manage
decal tags and group decisions.
Users may apply to join a crew, or be nominated as such, and with receipt of the other party's acceptance to the role (countersigning), compliant editors will bestow on them the relevant permissions or duties (see that in Syzygy's notifications/feeds).
Membership Proof
You can enforce membership using things like OpenCollective or SSO (similar to how Fulcio works). These membership types are checked by one machine, which then signs the membership statement and it's trusted by the other machines.
Where Are Crews
Crews define their allowed and preferred venues for Cicada to sync.
Crews aren't necessarily on a particular server, but they're probably rendered to a preferred one. It's probably run by your resident nerd.
You can find a crew's location by knowing one of the friends who are in it, because their editor will keep tabs on the venue the crew is at.
Roles
Roles in Bivouac are handles prefixed to groups, like @mods@@coolhackers.alice.phish.
A role can have many permissions referenced in a group's Mores documents. Mores are
used to allow or deny changing Cicada and Bivouac states based on the privileges of the
roles.
Documents in bivouac are not typically addressed 1:1, but are encrypted for a group of people. For example, in a team decision about whether to go to the east coast or west coast conference. A rendering editor refers to the crew list (containing a list of Phish identities) to determine membership.
Succession Planning
Roles can also define succession planning, for example specifying who becomes admin if no admin logs in for a month (in a flow decision). However, groups can also be easily forked (provided the other members go along with you in a rebel flow decision).
Built-in Super-Roles
Admins of a group may create roles (or this may be initiated by a Bivouac choice template) as they see fit, but some hardcoded key roles do exist. They are:
- root - the one who renders on a particular blog (the sysadmin)
- admin - the superuser of a group
- mod - a subclass below an admin of a group (typically affecting Karma and appeals)
- curator - those who curate a tag and can approve/deny them
- facilitator - those who moderate a decision
- debater - those who can propose options for a decision
- voter - those who can make selection documents about a choice
- observer - those who can see options/debate, but not votes
- auditor - those who count votes and know who voted for what
- evaluator - those who are notified by the auditor of what action to take (and typically have API credentials to make other things happen)
- petitioner - those who can initiate a choice
- candidate - those who want to be or can be a representative
- representative - those who are delegated power from others
If a role's Mores document contains effectively those permissions or is somehow involved in those decisions in some capacity, editors should label the profile role as containing those classes of effects.