Members and moderation

The platform decides who belongs to a chat space. The relay only enforces it: a key that is not on the roster cannot connect. Every change on this page goes through a workflow, and the console's Chat → Members section (Membros) is a front end for the same workflows.

Who becomes a member

People are admitted lazily. An end user with a seat does not appear on the relay until they open the chat, so unused seats cost nothing on the relay.

Invite people

A person needs an account in the identity app before they can open its chat. The console's Invite tab (Convidar) takes a list of emails and, for each one, runs two workflows:

1. identity.end-user.create with identity_app_uuid and email, skipped when the person already exists in the app;
2. identity.end-user.invite with identity_app_uuid and end_user_uuid (or email), which mails them their access to the app.

When they sign in and open the chat page, they are admitted. From the API:

start_workflow("identity.end-user.create", {"identity_app_uuid": "<app>", "email": "person@example.com"})
start_workflow("identity.end-user.invite", {"identity_app_uuid": "<app>", "end_user_uuid": "<from create>"})

Seats still apply. If the app has no free end-user seat, the person cannot sign in until you add seats. See Billing and seats.

Look at the roster

data.buzz.member.list (org members, read-only) lists every member of a space with:

data.buzz.member.directory is the view the chat page itself uses: active people and actors with display names and roles, and for actors how to reach them. It returns no platform ids and no emails. End users can call it only for their own app's space, and only after they have opened the chat.

Roles

buzz.member.set-role with space_uuid, member_uuid and role (admin or member) promotes or demotes a member on the relay. A relay admin can manage channels on the relay. Channel roles (owner, admin, member, guest) are set per channel; see Channels.

Display names

Other members see a person's display name. It is resolved on the server and is never derived from an email address:

1. a name the person chose, or an admin set;
2. otherwise a name from their profile, when one exists;
3. otherwise a neutral fallback such as Member 1a2b (in the space's locale).

A name is 1 to 64 characters, has no control characters and no @, and is not the person's email local-part.

Moderation

All of these are signed with the space's owner key on the relay, refuse agents, and (except suspend, remove, role and rotate) are for organization admins.

Bans and timeouts show up in data.buzz.member.list under moderation.

Removing someone

Disabling an end user in the identity app, or taking away their seat, does not remove them from the relay on the spot. It happens the next time the space is reconciled.

Maintenance

The console's Maintenance tab (Manutenção) holds the repair workflows.

The console's Activity tab (Atividade) shows the actor ledger, covered in Actors in chat.

Ask your AI assistant

Invite ana@example.com and bruno@example.com to my identity app "<app name>" so they can use its chat. Show me the identity.end-user.create and identity.end-user.invite calls before starting them.

List the members of my chat space who are suspended, banned or timed out, with the reason code for each.

Time out the member named "<name>" in my chat space for one hour with the reason "spam". Find their member_uuid with data.buzz.member.list and confirm with me first.

Run buzz.member.reconcile on my chat space as a dry run and explain what it would change.

For AI agents