Un canale è la strada che collega una persona a Metnos. La chat web e Telegram hanno interfacce diverse, ma consegnano le richieste allo stesso runtime: cambiano il mezzo e le funzioni disponibili, non le regole che governano le azioni.
Il canale si occupa del trasporto. Riconosce il mittente attraverso l'associazione già registrata, raccoglie il testo e gli eventuali allegati, chiama il runtime e restituisce la risposta. Non sceglie executor, non aggira Vaglio e non decide quali poteri concedere.
| Parte | Responsabilità |
|---|---|
| Canale | Riceve e invia messaggi; conserva gli identificatori necessari al trasporto. |
| Runtime | Comprende la richiesta, prepara il lavoro e coordina gli executor. |
| Controlli | Verificano identità, autorità, policy, collocazione e conferme richieste. |
Per esempio, «manda a Lucia su Telegram il riepilogo dell'incontro» non richiede di conoscere il numero tecnico della chat. Metnos cerca il canale Telegram associato a Lucia e, se l'azione è ammessa, consegna lì il messaggio.
Ogni richiesta viene attribuita usando i dati autenticati del canale. Il nome scritto nel testo o quello mostrato da Telegram non può assegnare un ruolo, cambiare utente o prendere possesso delle risorse altrui.
Conversazioni, dialoghi in sospeso, approvazioni e avvisi sono circoscritti all'utente riconosciuto. Anche la pressione di un pulsante viene ricontrollata: conoscere o inoltrare il codice interno di un pulsante non basta ad autorizzare l'azione collegata.
L'associazione di browser e Telegram è descritta in Associazioni e identità.
Nel browser il percorso è diretto. La pagina invia la richiesta al server HTTP, che autentica la sessione e chiama il runtime. Può ricevere una risposta JSON completa oppure un flusso di aggiornamenti progressivi mentre il turno è in corso.
La chat web non implementa il ciclo di interrogazione previsto dal
contratto Channel: HTTP usa già il suo naturale modello di
richiesta e risposta. È una differenza di trasporto, non di governo. Policy,
Vaglio, executor e separazione fra utenti rimangono gli stessi.
Le rotte e i metodi disponibili sono documentati in API HTTP.
Telegram usa un piccolo processo di servizio e la Bot API ufficiale. È Metnos ad aprire le connessioni verso Telegram: non serve pubblicare una porta del server domestico né configurare un webhook.
Il canale viene attivato durante l'installazione quando si fornisce il token del bot. Il token viene cercato, nell'ordine, fra configurazione esplicita, variabili d'ambiente, archivio cifrato delle credenziali e vecchio file di compatibilità. L'installazione normale usa l'archivio cifrato.
Il servizio Telegram è facoltativo. Sui sistemi che usano
systemd viene installato come servizio dell'utente che esegue
Metnos, parte insieme al resto dell'istanza e riparte dopo un errore.
/start e /pair fanno eccezione perché servono proprio
a creare l'associazione.L'identificatore dell'ultimo aggiornamento confermato viene salvato in modo atomico. Se la gestione o il salvataggio falliscono, non viene avanzato: al giro successivo Telegram può riconsegnare il messaggio. Questo riduce il rischio di perdere richieste durante un arresto improvviso.
| Contenuto | Comportamento |
|---|---|
| Testo | Viene inoltrato come richiesta oppure interpretato come risposta a un dialogo già aperto. |
| Foto | Vengono scaricate soltanto dopo avere riconosciuto il mittente. Gli album ravvicinati vengono raccolti in un'unica richiesta; ogni file è soggetto ai limiti previsti. |
| Posizione | Può rispondere a una richiesta di luogo oppure aggiornare la posizione dell'utente autenticato. La condivisione parte sempre dall'utente in Telegram. |
| Pulsanti | Servono per scelte, annullamenti e approvazioni. Il dato del pulsante viene accettato soltanto se corrisponde a uno stato ancora valido e allo stesso utente. |
| Contenuto non supportato | Viene confermato al trasporto senza essere trasformato arbitrariamente in una richiesta. |
Le risposte lunghe vengono divise rispettando i limiti di Telegram. La formattazione viene adattata al canale; se Telegram rifiuta il testo formattato, Metnos riprova in testo semplice. Una consegna parziale o incerta viene segnalata come tale, perché ripetere tutto potrebbe duplicare la parte già ricevuta.
Di norma la risposta torna sul canale che ha originato il turno. Una destinazione diversa deve essere dichiarata nella richiesta e autorizzata. Metnos non sposta silenziosamente una conversazione da un utente o da un canale all'altro.
Alcune attività terminano dopo che il turno iniziale è scaduto, per esempio un executor remoto rimasto in attesa del computer. In questo caso il risultato viene messo nella coda privata dell'utente e il servizio Telegram prova a consegnarlo nei cicli successivi, senza rieseguire l'azione.
Per aggiungere un trasporto basato su interrogazione, Metnos definisce un contratto Python molto piccolo:
class Channel(Protocol):
name: str
def poll(self) -> list[InboundMessage]: ...
def send(self, recipient: str, message: OutboundMessage) -> dict: ...InboundMessage conserva mittente, testo, identificatore, data e
metadati del trasporto. OutboundMessage contiene testo, eventuale
messaggio a cui rispondere e pulsanti. Gli oggetti ricevuti sono immutabili:
un messaggio già arrivato è un fatto da registrare, non uno spazio di lavoro da
modificare.
Il contratto separa la meccanica del trasporto dalla semantica della richiesta. Un nuovo adattatore può normalizzare i propri messaggi, ma deve consegnarli allo stesso runtime e rispettare le stesse verifiche d'identità.
Per capire come aprire l'interfaccia web continua con Aprire e usare Metnos. Per i dettagli del server continua con API HTTP.