Users

A Metnos user is a stable identity associated with conversations, preferences, channels, devices, and data. The Users page keeps three concepts distinct: the user'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 changing the user's identity or merging it with another.

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 interface does not accept arbitrary keys.

In the user detail page, Site names pairs the name used in requests with a URL. For example, you can save “telepas” with https://www.telepass.com/: when you ask Metnos to open or use that site, it starts from the saved address instead of guessing it from the name. Associations are separate for each user; an explicit URL in the request takes precedence. If a request names several saved sites, Metnos asks which one to use.

If you know the URL but have not chosen a name, leave the Invocation name field empty and enter the address. Metnos suggests a name from the domain without saving anything: check or change it, then select Save association. If the site is already registered, the existing name is suggested; names remain editable and separate from URLs.

The association contains no password and grants no extra permission: credential handling, consent, and checks against the actual site remain separate.

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 web interface.
  1. Section access. User administration is separate from device management.
  2. Creation. Identity, role, and autonomy are defined explicitly for every new guest.
  3. Identity. Technical name, display name, and address remain distinct fields.
  4. Role, autonomy, and channels. The table keeps them distinct rather than reducing them to a single notion of “permission”.
  5. Detail. Provides access to operations scoped to that user.

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