Users

A Metnos user is a stable identity that owns conversations, preferences, channels, devices, and data. The Users page separates three concepts: a person's role in the instance, their granted autonomy, and the channels through which they can connect.

Role and autonomy

The host is the instance's primary identity. A guest belongs to a host and is confined to their own scope. A role is not the same thing as autonomy:

AutonomyOperational meaning
restrictedActions remain tightly constrained, and sensitive operations follow the applicable approval path.
read_onlyThe user may inspect data in their scope without introducing operational changes.
fullThe user may use capabilities admitted by their role, policy, and executors; safety prohibitions still apply.

Grant only what is needed. full is not an absolute pass: data ownership, signed executors, safety rules, and approval still apply.

Paired channels

HTTP, Telegram, and mail connect an external identity to a Metnos user. The pairing uses a temporary token and must be verified; a pending state means the flow has not finished. Removing a channel revokes that access path without merging or confusing identities.

Language is not a per-user preference. It belongs to the Metnos instance. Users of the same instance therefore share its configured language while their data, permissions, and conversations remain separate.

Profile, preferences, and devices

The detail page can update display name, address, notes, and autonomy; pair or remove channels; and list devices owned by the user. Available preferences come from a closed vocabulary: the UI does not accept arbitrary keys.

Deletion is a lifecycle operation, not merely removal of a row. Metnos stops the active administrator from deleting themselves and protects the sole host. For an eligible user, access and running work are revoked and data is removed through the defined lifecycle.

The Users screen

The real, anonymised Metnos Users screen in an Italian-language instance.
Names and addresses are anonymous examples; structure, fields, states, and actions match the real HTTP UI.
  1. Section access. User administration is separate from device management.
  2. Creation. A new guest receives an explicit identity, role, and autonomy level.
  3. Identity. Technical name, display name, and address remain distinct fields.
  4. Role, autonomy, and channels. The table keeps them from collapsing into one notion of “permission”.
  5. Detail. Opens operations scoped to that user.

All personal and timestamp values shown in the image are synthetic.