Restrict group visibility or participation to trusted instances

"As a group admin, I want to restrict visibility or participation in the group to users coming from trusted instances, so I can create a safe space within a trusted network (archipelago)."

Beyond open groups, some communities want to restrict participation to a trusted network of instances:

• Closed federation: Only actors from allowed instances can join/participate
• Trusted network: A coalition of instances that mutually trust each other's moderation
• Invite-only from trusted sources: Members can only be invited by actors from certain instances

Use cases:

• Academic research groups limited to university instances
• Regional communities (e.g., instances in a specific country/language)
• Coalition of like-minded instances with shared moderation standards
• Private support groups where trust is paramount

This can be expressed via interactionPolicy (see https://github.com/swicg/groups/issues/26):

{
  "type": "Group",
  "id": "https://example.org/groups/1",
  "interactionPolicy": {
    "canJoin": {
      "automaticApproval": [
        "https://trusted-instance.org",
        "https://ally-instance.net"
      ],
      "manualApproval": []
    },
    "canPost": {
      "automaticApproval": ["members"]
    }
  }
}

Remote moderators can update the allow-list using Update on the Group actor:

{
  "type": "Update",
  "actor": "https://remote.example/users/mod",
  "object": {
    "type": "Group",
    "id": "https://example.org/groups/1",
    "interactionPolicy": {
      "canJoin": {
        "automaticApproval": [
          "https://trusted-instance.org/actors",
          "https://new-ally.net/actors"
        ]
      }
    }
  }
}

The group's home instance:

1. Verifies the mod has permission
2. Merges or replaces the policy as appropriate
3. Federates the updated Group actor to followers

Start by reviewing the linked interactionPolicy proposal in groups issue 26 and the Group actor's Update behavior described here. Define how trusted-instance allow-lists, permission checks, policy merging or replacement, and federation of updates should work; done means the behavior is specified consistently for the listed use cases.