Mores, from "Social Mores", are documents that define the relationship based access control (ReBAC) for a group (or even relationships between groups). It also defines how user Karma works.
Users can be members of several roles, and interact with many processes. A Mores document defines the actions a role in a group can take. It also defines what rules and roles from other groups will be respected and how.
Mores and karma can be changed through flow-based playbooks (discussed more in the Bivouac section). Things like meta-moderation are also possible.
Rule Precedence
When evaluating a pending change to the bivouac state, the program considers:
- the "overrides", the group rules that take priority over all else
- the document's rules, made alongside the document in the current cicada state
- the "default" rules, rules a document may override
Limitations
Because the documents are mirrored to many recipients, there are limits to what can be enforced. For example, reading messages not encrypted to you can be bypassed with collusion. Or, publishing votes meant to be private. An evaluator might refuse to carry out the selected action.
Role Permissions
For example, the scope of the curator role is to apply or remove decal tags. They can
have broad allow permission on that action. However, their role doesn't necessarily give
them permission to admit/reject people from the group (a separate action).
Syntax
These documents can be defined at the group or server level, for example if the carrier of
the venue decides to allow, forbid, require, or no preference a particular attribute.
Things like rego/OPA, or cedar, or policykit were considered for syntaxes defining rules.
Permissions should also be somewhat similar to NFSv4, e.g.: list, administer, insert/create, delete, edit, append, replace, read, lock/unlock, change ownership, attribute write/read,
Karma-based rules
Rules can also be based off Karma. Karma is group-specific, though your group may add
in a rule that converts another group's karma for evaluation in specific circumstances (for
example, weighting another group's spammer karma relatively equal to your own).
Say for example you have a rule about candidates for representative, that they have to
have no more than 20 negative "troll" karma points in group from the mods if they wish
to run as a candidate.
Sliding-Window Karma
Karma documents do expire and forgive over time, though your group can define how this
happens. Perhaps a user can more quickly execute a remedy action by, for example,
issuing a public apology post renouncing their troll behavior. While they sit around, they
act as a kind of log.
This also means that positive karma slowly expires (e.g. newcomers vs super-entrenched karma folks). It's a sliding window, use it or lose it. To a certain extent, you could design rules that give a torrent-like random forgiveness to a peer (and grant them a chance to try again with something small).
Because some Mores rules can be constructed to require certain kinds of karma, it can be worth it to keep an identity around and seek forgiveness. The bar shouldn't be so high that it takes forever for new/unknown identities to contribute, but it makes sense to have a sandbox period to avoid the damage from sockpuppets.
Karma isn't exactly something you can GDPR away. When a group decides to ban you for bad behavior, they can keep around that negative rating (and pin your identity). You might ask to have the memo removed, but they're within their rights to keep your phish ID penalized until it expires.
Karma as a decreasing balance
Karma is mostly represented either by groups, or by individual users. Users may have a rule among friends that "new contacts may start out with 20 karma points, but I will deduct 1 point per each message they send me, and 5 for low quality interactions. If I want to top-off their karma, I'll do so in their phish-mores document on my site. if they don't have enough karma, don't allow them to mirror a document to me, don't waste energy storing things I don't want."
Scripted Karma Penalties
Karma might also be deducted or added by scripts to detect large numbers of HTTPS links, or invite rate limits, or constant negative voting/brigading.