Pairing and identity

Before processing a request, Metnos needs to know who is speaking and which resources belong to them. It therefore pairs the user, channel, web session, and remote computer separately. Writing “I am Roberto” is not enough to become Roberto.

Four things not to confuse

The four pairings have different effects. Pairing Telegram does not authorise the phone to run executors. Opening chat in a new browser does not turn that computer into a remote device. Transferring a conversation does not change who owns a device.

Users, roles, and autonomy

An installation has one owner with the host role and may have several guests. Every user has a stable technical identifier, a unique name, a role, and an autonomy level.

An autonomy level is not a free pass. Every action must still pass the executor contract, policy, Vaglio, placement, and applicable confirmations. A guest with full autonomy does not become the owner or inherit other users' resources.

The language belongs to the instance and is shared by its users. Conversations, pending dialogues, channels, and devices remain separated by user.

Pairing Telegram

1. In web chat, open Settings › System › Users.
2. Create the user if needed, or open their existing record.
3. Generate the Telegram code.
4. Send it to the user through a trusted medium.
5. The user opens the Metnos Telegram bot and sends /start <code>.

The code is random, expires after one hour, and can be consumed only once. Two concurrent attempts cannot both pair with the same code. The /start command completes the pairing but does not execute a request; the next message starts a new turn.

Metnos stores the technical Telegram address alongside the user. Later messages are attributed through that pairing, not through the display name in the Telegram profile or a claim written in the message.

The technical /pair code

A lower-level flow also exists, using an Ed25519-signed code for technical channel administration. The code declares its expiry and autonomy level, normally lasts five minutes, and can be used once. To pair a user who already exists, the Settings › System › Users flow is simpler and preserves the logical identity explicitly.

Pairing a browser

1. From the user record, generate the HTTP-channel link.
2. Open that link once in the browser you want to pair.
3. Metnos consumes the code, records the browser as one of the user's addresses, and stores a signed cookie.

The pairing code expires after one hour. The cookie may last for up to 90 days and uses the browser's standard protections (HttpOnly and, over HTTPS, Secure). On every request, the server checks that the pairing still exists. If the administrator removes the HTTP channel, a cookie left in the browser is not enough to sign in.

Opening the same chat on several devices

Only one web session may write for the same user and web channel at a time. If you open chat on a second device while the first is still active, Metnos offers three choices:

The transfer is atomic and applies only to the authenticated user. The conversation belongs to the user, not the browser. When connected, the old device receives a revocation notice and can no longer send messages with its previous write authority.

Pairing a computer for remote executors

This pairing is different from browser pairing. It installs a component on the computer that can receive and perform authorised actions.

1. Open Settings › System › Devices.
2. Choose the owner and computer name, then generate the link.
3. Open the link on the target computer and install the client. The guided flow offers the appropriate installation for Windows or Linux.
4. The client creates a private Ed25519 key that never leaves the computer and registers only the public key with the server.
5. The server returns its public key, which the client stores to verify future jobs and bundles.
6. The first heartbeat makes completion of the flow visible.

The guided link normally lasts 30 minutes; the manual code lasts 10 minutes. Both are single-use. Presenting the same code again with the same key returns the same device without duplication; using a different key is rejected.

The page shows latest heartbeat and latest work request separately. The first says that the client process is communicating; the second says that the operational loop is actually polling the server. Availability requires both to be recent and is not inferred from the heartbeat alone.

For verified bundles, caching, sandboxing, and results, see Remote executors.

Revoking a pairing

Revoking one object does not silently change the others. Removing Telegram does not revoke a remote computer; revoking a computer does not close the web session. This separation makes it clear which access is being removed.

Shared guarantees

• Identity before content. A sentence cannot assign a user, role, or owner.
• Short-lived, single-use codes. Pairing is recorded atomically before the code is considered consumed.
• Verified ownership. Conversations and devices may be read or transferred only within the authorised user.
• Revocation checked on every access. A formally valid signature or cookie does not restore a removed pairing.
• Private keys remain local. A remote computer's private key is never sent to the server.
• Separate registries. Channels, sessions, and computers have distinct, observable revocation paths.

For everyday channel use, continue with Conversation channels. To understand what a paired user may authorise, see Policy and authority.