Conflicts

The conflicts configuration controls how Identica resolves provider conflicts such as username collisions.

Conflicts are configured per conflict key. Each key defines:

• a default rule
• optional ordered cases rules
• an ordered list of resolvers inside each rule

conflicts

• Takes: a map keyed by conflict key
• Affects: how Identica resolves registered conflicts before allowing or denying progress

Use this section when you want to change the resolver chain for a conflict type or define type-specific behavior for a matching rule selector.

conflicts:
  username:
    default:
      resolvers:
        - id: "format_display"
          parameters:
            format:
              pattern: "{username}*"
            target: "joiner"
    cases:
      - when:
          providers:
            - "premium"
            - "credential"
        resolvers:
          - id: "format_display"
            parameters:
              format:
                pattern: "{username}_{incomingProvider:8}"
              target: "joiner"

{
  "conflicts": {
    "username": {
      "default": {
        "resolvers": [
          {
            "id": "format_display",
            "parameters": {
              "format": {
                "pattern": "{username}*"
              },
              "target": "joiner"
            }
          }
        ]
      },
      "cases": [
        {
          "when": {
            "providers": ["premium", "credential"]
          },
          "resolvers": [
            {
              "id": "format_display",
              "parameters": {
                "format": {
                  "pattern": "{username}_{incomingProvider:8}"
                },
                "target": "joiner"
              }
            }
          ]
        }
      ]
    }
  }
}

Rule selection

When Identica resolves a conflict for a key such as username, it evaluates rules in this order:

1. matching rules from cases
2. the default rule

Inside a rule, resolvers run in list order. If a resolver returns PASS, Identica continues to the next resolver. If every resolver passes, Identica falls back to the next applicable rule. If no rule produces a result, Identica logs a warning and allows the conflict.

Rule matching is owned by the contributed conflict type for that key. Core stores the opaque when object but does not interpret it.

conflicts.[key].default

• Takes: a conflict rule object
• Affects: the fallback resolver chain for that conflict key

The default rule runs when no matching case rule produces a non-pass result.

conflicts.[key].cases

• Takes: a list of conflict rule objects
• Current default: []
• Affects: type-owned conflict resolution before the default rule runs

Each case rule is checked in list order. The contributed conflict type decides whether the rule's when object matches the current conflict context.

conflicts.[key].cases[].when

• Takes: an object
• Current default: {}
• Affects: which contexts the rule applies to, according to the contributed conflict type

The shape and meaning of when is owned by the contributed conflict type for that key.

conflicts.[key].default.force

conflicts.[key].cases[].force

• Takes: true or false
• Current default: false
• Affects: whether Identica should run a resolver even when it does not declare support for the conflict key

Leave this disabled unless you intentionally want to bypass normal resolver compatibility checks.

conflicts.[key].default.resolvers

conflicts.[key].cases[].resolvers

• Takes: a list of resolver entries
• Affects: the ordered resolver chain for the selected rule

Each resolver entry selects a resolver type and provides its configuration parameters.

conflicts.[key].default.resolvers[].id

conflicts.[key].cases[].resolvers[].id

• Takes: a string
• Affects: which registered conflict resolver is invoked

Resolver ids must match a resolver registered by a contributed conflict type or another installed module.

conflicts.[key].default.resolvers[].parameters

conflicts.[key].cases[].resolvers[].parameters

• Takes: an object
• Current default: {}
• Affects: resolver-specific behavior

The parameter structure depends on the selected resolver type. Resolver ids, parameter schemas, and type-specific when selectors should be documented by the module that contributes them.