Channel federation

Federation is experimental and must be enabled and configured by server operators. See the operator guide for configuration and protocol boundaries.

Organization owners enable hostname or verified-domain identity. Users choose distinct organization-unique usernames and appear as username@domain in federated channels. Private invite-only and authenticated public mirrors are supported; web-public channels are prohibited.

Single-homed channels accept sends and shared moderation at their home server. Multi-homed channels accept local sends and maintain independent mirror moderation: local removals, local user access revocation, and remote-source hiding. Hidden bodies retain sender identity and domain. Removing a hide policy does not restore previously discarded bodies.

Open participation has independent, default-off organization settings for DMs, private named groups, and authenticated public channels. DMs and group invitations also require a user inbox opt-in. Named-group creators control invitation permissions; new members do not receive old history. Every instance maintains its own domain/user block list, and users can independently block private delivery. Open servers use HTTPS discovery and Ed25519 signatures. Anonymous channel access is never enabled by these settings.

Organization and account settings expose identity setup, independent federation opt-ins, and domain blocks. Channel settings expose homing, public channel discovery, local access restrictions, and source hiding. The federated conversation dialog supports private creation, replies, history, and invitations. Adding individual identity blocks still requires the API.

Private message metadata contains conversation_origin and conversation_id. Use them for replies, the conversation detail endpoint, and the federation-conversation narrow. Membership alone does not identify a named group: separate groups can have identical participants. Message receipt checks apply to history, including for later invitees.