Il primo articolo su Telegram Amiga raccontava una scelta prudente: partire dalla Bot API, costruire un client diagnostico, verificare rete, TLS, JSON, polling, offset e invio controllato di messaggi. Era il modo sensato per capire se una macchina Amiga-like potesse ancora parlare con un servizio moderno senza trasformare ogni richiesta HTTPS in una seduta spiritica con lo stack TCP/IP.
Quella fase non sparisce, ma cambia ruolo. Nel repository telegram-amiga la direzione principale e ormai MTProto: non piu solo un bot helper o un tester di chiamate HTTP, ma un prototipo pre-alpha di client testuale capace di usare un account Telegram reale, salvare una sessione, elencare dialoghi, leggere history e inviare messaggi verso peer selezionati. Detto in modo meno educato: si e passati dal “Telegram risponde da lontano” al “questa macchina prova a comportarsi da client”.
Il cambio e sostanziale perche MTProto non e una API comoda da consumare con una richiesta HTTPS e un JSON in risposta. Qui entrano in gioco bootstrap crittografico, serializzazione TL, trasporto TCP, RSA, Diffie-Hellman, AES-IGE, gestione di auth_key, server_salt, seq_no, message id e file locali che non devono finire in screenshot, pacchetti o repository. Su un sistema moderno e gia un terreno pieno di trappole. Su AmigaOS 3.x, MorphOS, AmigaOS 4.x e AROS diventa un laboratorio tecnico vero, con il fascino sobrio delle cose che possono rompersi in dodici modi diversi prima ancora di stampare una riga utile.
Da Bot API a MTProto
La Bot API resta nel progetto per una ragione concreta: e ancora utile per diagnostica, preflight HTTPS, getMe, getUpdates, invio controllato e test di stato. Ma il README aggiornato e molto netto: la linea principale e MTProto, con l’obiettivo di un client Telegram testuale e leggero per sistemi Amiga-like.
La differenza non e solo nominale. Con la Bot API si parla come bot, con token e chiamate HTTP. Con MTProto si entra nel protocollo dei client Telegram: login con numero e codice, eventuale 2FA, sessione salvata in telegram-auth.bin, cache locale dei peer in telegram-peers.txt, comandi per interrogare dialoghi e history, e una modalita chat interattiva che stampa righe me: e righe del peer selezionato invece di scaricare addosso all’utente tutta la diagnostica del protocollo.
Nei test locali non distruttivi eseguiti prima della pubblicazione, la suite MTProto veloce passa: DC mapping, message id, auth, TL, envelope, encrypted framing, transport, login scaffolding, probe, crypto e session state risultano tutti ok. Anche i self-test storici della parte Bot API/testo restano verdi. Questo e importante perche il passaggio a MTProto non deve bruciare il ponte precedente: se la diagnostica Bot API regredisce, il laboratorio perde uno dei suoi strumenti di misura.
Il cuore: auth key, RSA_PAD, AES-IGE e DH
La parte interessante non e “abbiamo aggiunto login”. La parte interessante e come ci si arriva. Il codice MTProto oggi copre la costruzione di req_pq_multi, parsing di resPQ con validazione del nonce, fattorizzazione di pq, selezione della fingerprint RSA da una lista nota, materiale pubblico RSA di produzione Telegram, serializzazione di p_q_inner_data_dc e req_DH_params, RSA_PAD con AES-256-IGE, parsing di server_DH_params_ok, decifratura di server_DH_inner_data, validazione di prime/g e completamento con set_client_DH_params.
Da li vengono derivati auth_key_id e server_salt, poi si passa al framing dei messaggi cifrati MTProto 2.0. Il progetto include anche probe supervisionati che arrivano fino a un ping/pong cifrato dopo la creazione temporanea della chiave. Non e ancora “uso quotidiano”, ma e la parte che separa un client reale da una scorciatoia cosmetica. Se non governi questa fase, stai solo dipingendo una finestra Telegram sopra un buco nero.
Il repository mostra anche una scelta di prudenza: i file di autorizzazione vengono salvati solo quando la piattaforma puo fornire random sicuro, e i comandi di ispezione non stampano chiavi, session id o identita account. Nel controllo locale, telegram-auth.bin risulta valido, con auth key presente, key id coerente, server salt presente, sessione presente e stato di sequenza salvato. Sono dettagli poco fotogenici, ma sono esattamente quelli che evitano al progetto di diventare una demo fragile.
Dialoghi, peer cache e chat interattiva
La seconda svolta e funzionale. MTProto account mode oggi include login wizard interattivo, supporto alla password 2FA quando Telegram la richiede, protezione contro mismatch del data center salvato, smoke test read-only, elenco dialoghi, estrazione e cache dei peer, lettura della history testuale e invio di testo a un peer utente selezionato.
La cache telegram-peers.txt non e un dettaglio burocratico: e il modo con cui un ambiente testuale, magari su una console Amiga, evita di chiedere ogni volta all’utente di ricordare identificativi e access hash. I dialoghi vengono letti con messages.getDialogs, la history con comandi dedicati, e l’invio passa da messages.sendMessage. La modalita mtproto-chat aggiunge il pezzo ergonomico minimo: scelta del peer, lettura immediata, auto-read mentre si aspetta input da tastiera, comandi /read, /watch, /peer, /peers e /quit.
C’e perfino una piccola lezione di portabilita dentro le risposte gzip_packed: dove zlib non e disponibile, il progetto puo usare il fallback embedded puff. Non e glamour, ma su target storici e Amiga-like sono proprio questi compromessi a fare la differenza tra “compila sul mio Mac” e “puo essere provato davvero su piu sistemi”.
AmigaOS 3, MorphOS, AmigaOS 4 e AROS
La parte editoriale piu importante, per RetroLab, e che lo sforzo non resta chiuso nel binario locale. Il README elenca pacchetti pre-alpha pubblici per AmigaOS 3.x, MorphOS, AmigaOS 4.x, AROS i386 ABIv0 TLS e AROS x86_64 offline. I package includono README di piattaforma, USER_RUNBOOK.md, note MTProto e script helper; non includono token, API credentials, auth file, phone code, password o peer cache.
Questo punto va capito bene: non significa che Telegram Amiga sia gia un sostituto di Telegram Desktop, e infatti il progetto lo dice esplicitamente. Mancano ancora update loop completo, gestione sessione robusta per uso quotidiano, supporto maturo per gruppi/canali, edit/delete/reaction, media, contatti e una UI rifinita. Ma il target realistico e finalmente piu alto del “tester che chiama una API”: un client testuale affidabile, prima per messaggi, poi eventualmente per cio che le piattaforme permetteranno senza trasformare il tutto in archeologia punitiva.
Cosa cambia davvero
La svolta MTProto cambia la natura del progetto. La Bot API dimostrava che Amiga-like poteva attraversare TLS, parlare HTTP e gestire un flusso Telegram mediato da un bot. MTProto invece obbliga a risolvere il problema da client: identita utente, bootstrap crittografico, stato persistente, data center coerente, dialoghi, peer, history e invio messaggi. E una differenza architetturale, non una feature in piu nel menu.
Per AndroidLab RetroLab questo e il punto: il retrocomputing vivo non consiste nel far girare software moderno “perche fa scena”. Consiste nel prendere limiti veri, toolchain vere, TCP/IP reali, TLS reale, crittografia reale e costruire un percorso verificabile. Se Telegram Amiga riuscira a diventare un client testuale usabile, non sara per nostalgia. Sara perche ogni pezzo del protocollo e stato reso abbastanza piccolo, portabile e osservabile da sopravvivere anche fuori dal comfort delle piattaforme moderne.
In breve
- Telegram Amiga non e piu centrato solo sulla Bot API: la direzione principale e un client MTProto testuale pre-alpha.
- Il bootstrap MTProto include RSA_PAD, AES-IGE, Diffie-Hellman, auth key, server salt e framing cifrato MTProto 2.0.
- Account mode supporta login wizard, 2FA, sessione salvata, dialoghi, peer cache, history,
sendMessagee chat interattiva. - I pacchetti coprono AmigaOS 3.x, MorphOS, AmigaOS 4.x, AROS i386 ABIv0 TLS e AROS x86_64 offline.
- Resta una pre-alpha: il valore e nella direzione tecnica verificabile, non nella promessa di un Telegram completo da usare domani mattina.