identity/username/

identity/username/conflicts.yml holds the rules that settle two accounts wanting one username, and identity/username/messages.yml what players see when it happens. Usernames and conflicts explains when a conflict comes up and what the default rules do.

conflicts.ymlCopy Anchor Link

outcomes:
  rename-holder:
    pattern: "{username}_{provider}"
    tooLong: SHORTEN
    taken: NUMBER
    holderOnline: KEEP_PLAYING
  rename-arriving:
    pattern: "{username}_{provider}"
    tooLong: SHORTEN
    taken: NUMBER
  refuse: {}
providers: {}
rules:
  - arriving: { guarantees: [OWNED_USERNAME] }
    holder: { guarantees: [] }
    trigger: FIRST_JOIN
    outcome: rename-holder
  - arriving: { guarantees: [OWNED_USERNAME] }
    holder: { guarantees: [] }
    trigger: PROVIDER_RENAME
    outcome: rename-arriving
  - arriving: { guarantees: [] }
    outcome: refuse
  - outcome: refuse

Which rule appliesCopy Anchor Link

Of the rules that apply to a conflict, the most specific one wins:

1. a rule naming provider ids on more sides beats one naming fewer;
2. then a rule naming guarantees on more sides beats one naming fewer;
3. then a rule that also names a trigger or arrivedVia beats one that does not.

Among equally specific rules, the first one in the list wins. When two equally specific rules can apply to the same conflict but settle it differently, the console warns on start and on reload, because the second one never applies there. When no rule applies, the arriving player is refused.

rules[].arriving and rules[].holderCopy Anchor Link

What the rule asks of the joining player's provider and of the holder's provider. Leave a side out to accept any.

outcome:
  id: rename-holder
  with:
    holderOnline: KICK_HOLDER

outcomes and providersCopy Anchor Link

An outcome's settings come from three places, each stating only what it changes:

1. the rule's with, which wins;
2. providers.<provider>.<outcome>, for the provider of the account the outcome renames: the holder's for rename-holder, the joining player's for the others;
3. outcomes.<outcome>, which Identica writes with the outcome's defaults.

providers:
  credential:
    rename-holder:
      pattern: "{username}_offline"

Names made without a ruleCopy Anchor Link

Identica uses the rename-holder settings in two cases no rule decides:

• Two accounts of the same provider with OWNED_USERNAME want one name, so the holder's name is outdated: the holder was renamed at the provider and has not joined since. The current owner gets the name, and the holder a name made with rename-holder's settings for its provider. On the holder's next join, the provider's new name for it goes through the rules as a PROVIDER_RENAME.
• Another player on this proxy still plays under the account's username, such as a holder renamed while online who has not left yet. The player plays this session under a name made with rename-holder's settings for the player's provider.

messages.ymlCopy Anchor Link

The messages apply to every scenario.

pipeline:
  policy:
    taken:
      - "<red>{username} is taken, please join with another name.</red>"
    holderReplaced:
      - "<yellow>The owner of {username} has joined. Join again to play as {renamed}.</yellow>"