Telegram Amiga nasce da una domanda semplice e un po’ testarda: si può costruire un client Telegram testuale, reale, su sistemi Amiga-like nel 2026, senza ridurlo a una demo da screenshot?
La risposta, almeno oggi, non è ancora “sostituisce Telegram Desktop”. Sarebbe marketing, e il retrocomputing serio non ha bisogno di fumo scenico. La risposta più onesta è più interessante: il progetto è diventato una pre-alpha MTProto capace di fare login con un account Telegram, salvare lo stato locale, leggere dialoghi e history, inviare testo e funzionare come laboratorio portabile tra AmigaOS 3.x, MorphOS, AmigaOS 4.x e AROS.
Per me il punto non è la nostalgia. È il limite come banco di prova. Quando provi a portare rete, TLS, serializzazione binaria, crittografia e stato persistente su macchine nate in un’altra epoca, sei costretto a capire davvero cosa sta succedendo. E questo, paradossalmente, rende più lucido anche quando torni sui sistemi moderni, dove spesso la complessità viene solo nascosta sotto strati più comodi.
Capitolo 1: partire da un client diagnostico
Il primo passo è stato volutamente prudente: non MTProto, non login utente, non sessione completa. Prima ho costruito un client diagnostico basato sulla Bot API, raccontato nell’articolo Telegram su Amiga nel 2026: perché partire da un client diagnostico.
Quella fase serviva a misurare il terreno. HTTPS funzionava davvero? Lo stack TCP/IP dei target reggeva? OpenSSL o AmiSSL erano collegabili in modo pratico? La parte HTTP, JSON, polling, offset e invio controllato di messaggi poteva sopravvivere fuori dal comfort di una macchina moderna?
La Bot API, in quel momento, era una sonda. Non il prodotto finale. Consentiva di verificare rete, TLS e ciclo di sviluppo senza infilarsi subito nella parte più delicata del protocollo Telegram. In altre parole: prima si controlla se il ponte regge, poi ci si fa passare sopra il camion.
Nel repository Telegram Amiga questa fase resta ancora disponibile come modalità di fallback e diagnostica, proprio perché continua a essere utile per controllare rete, TLS e comportamento dei target.
Capitolo 2: la svolta MTProto
Il salto vero è arrivato quando il progetto ha smesso di ragionare solo come “bot helper” e ha iniziato a comportarsi da client Telegram. Ne ho scritto nel secondo capitolo, Telegram Amiga diventa MTProto: la svolta da Bot API a client reale.
MTProto cambia completamente il peso tecnico del progetto. Non basta più chiamare un endpoint HTTPS e leggere JSON. Bisogna creare una auth-key, serializzare oggetti TL, gestire nonce, fingerprint RSA, Diffie-Hellman, AES-IGE, server salt, message id, sequenze, data center e sessione locale. Poi arrivano login telefono/codice, eventuale password 2FA, cache dei peer, history e invio messaggi.
Questa è la differenza tra “Telegram risponde a una richiesta” e “questa macchina prova a essere un client”. È una differenza architetturale, non una spunta in più nel README.
Il codice MTProto nel repository è il cuore tecnico del progetto: auth-key, TL serialization, login, peer cache e chat mode sono lì, non raccontati come promessa astratta.
Capitolo 3: l’infrastruttura di contorno
Quando il target è Amiga-like, il codice da solo non basta. Serve anche un modo sano per sviluppare, copiare binari, lanciare test e leggere output senza trasformare ogni giro in una liturgia manuale. Qui entra in gioco il lavoro raccontato in BebboSSH su AROS: quando SSH trasforma il retrocomputing in laboratorio reale.
AROS, in particolare, è una corsia preziosa perché permette test rapidi in ambienti virtualizzati o hosted, ma resta abbastanza vicino alla sensibilità Amiga da mettere in evidenza problemi veri di portabilità. Con BebboSSH posso usare SSH, SCP e SFTP come infrastruttura di sviluppo: compilare o preparare da Mac, spostare il binario sul target, eseguirlo, osservare l’output, ripetere.
La cross-compilazione Docker su Mac, le toolchain GCC per piattaforma, QEMU, hardware reale e SSH non sono accessori decorativi. Sono il banco da lavoro. Senza quello, un client MTProto su Amiga rischia di diventare un esperimento eroico ma poco ripetibile. Con quello, diventa un progetto che si può misurare.
Anche qui il riferimento resta il repository Telegram Amiga, perché la parte editoriale ha senso solo se rimanda a un progetto verificabile, con sorgenti, documentazione e release.
Capitolo 4: dove siamo oggi
Lo stato attuale del codice è una pre-alpha pubblica, ma già molto più concreta del prototipo testuale di fine maggio. La linea principale è MTProto account mode: il client può creare la auth-key, guidare il login con numero di telefono e codice Telegram, gestire il controllo della password 2FA quando Telegram la richiede e salvare lo stato in telegram-auth.bin.
Dopo il login, il client può elencare dialoghi e peer in telegram-peers.txt, leggere la history testuale di utenti, gruppi e canali/supergruppi, e inviare testo a utenti, gruppi e canali quando l’account ha i permessi necessari. Non è ancora un client “ricco”, ma il percorso essenziale leggere-scegliere-rispondere esiste.
La modalità chat interattiva aggiunge il minimo di ergonomia che serve per usare il progetto come client testuale: righe con il nome del peer, lettura automatica mentre si attende input da tastiera e comandi /read, /watch, /peer, /peers e /quit. Sono cose piccole, ma su una console Amiga fanno la differenza tra diagnostica grezza e uso comprensibile.
C’è poi un dettaglio tecnico che racconta bene la filosofia del progetto: le risposte MTProto gzip_packed. Sui target dove zlib non è una scelta pratica, Telegram Amiga può usare il fallback embedded puff. Non è una feature da titolo, ma è il tipo di decisione che distingue il port serio dal “compila sul mio computer e tanti auguri”.
Il supporto TLS passa da OpenSSL o AmiSSL secondo il target. I pacchetti pre-alpha pubblici coprono AmigaOS 3.x, MorphOS, AmigaOS 4.x e AROS i386; AROS x86_64 resta congelato come corsia diagnostica, perché al momento il runtime standard non è ancora abbastanza stabile da meritare la stessa fiducia degli altri target. Dirlo non indebolisce il progetto: lo rende verificabile.
Le release pre-alpha su GitHub includono pacchetti per tester e materiali di supporto, ma non includono file locali sensibili. Auth-key, token, numeri, codici, password, peer cache e screenshot che li mostrano non devono finire online. Qui la sicurezza non è una nota legale in fondo: è parte del design.
Lo stato descritto in questo capitolo deriva dal README e dai sorgenti pubblici, che restano il punto più aggiornato per capire cosa funziona davvero e cosa è ancora in lavorazione.
Cosa manca e dove va il progetto
Il prossimo fuoco vero è il full update loop basato su updates e differences di Telegram. È il passaggio che trasforma il client da “leggo e invio quando interrogo” a “resto allineato allo stato reale della conversazione”. Senza quello, Telegram Amiga è già utile come laboratorio e pre-alpha testuale; con quello, inizia a somigliare davvero a un client reattivo.
Dopo l’update loop vengono session management più robusto, gestione più ampia di gruppi e canali, media download/upload, eventuale UI più comoda e validazione reale su più combinazioni di hardware e sistema operativo. La priorità, però, resta corretta: prima un client testuale solido, poi il resto. Nel retrocomputing, aggiungere interfaccia sopra fondamenta fragili è solo un modo elegante per sprecare weekend.
Provarlo e contribuire
Il repository è pubblico su GitHub: github.com/kaffeine1/telegram-amiga. Da lì si accede al codice, alla documentazione MTProto, alle note di piattaforma e alle release pre-alpha.
Il contributo più utile, in questa fase, non è “aggiungiamo tutto Telegram”. È testare con metodo: target preciso, versione del pacchetto, sistema operativo, rete, TLS usato, comando lanciato, output non sensibile e comportamento osservato. I test su hardware reale valgono oro, soprattutto quando distinguono un problema del client da un limite dello stack di rete, della toolchain o dell’ambiente.
Regola di sicurezza semplice: non pubblicare mai telegram-auth.bin, token, numeri di telefono, codici, password, cache dei peer o log che li contengono. Se uno screenshot dimostra il funzionamento ma rivela materiale di login, non è una prova: è una piccola bomba lasciata sul tavolo.
In breve
- Telegram Amiga è una pre-alpha MTProto in C per sistemi Amiga-like, non solo un esperimento Bot API.
- Il progetto supporta login Telegram, auth-key, 2FA quando richiesta, stato salvato, dialoghi, history, invio testo e chat mode interattiva.
- Il lavoro copre AmigaOS 3.x, MorphOS, AmigaOS 4.x e AROS i386; AROS x86_64 resta una corsia diagnostica congelata.
- Il fallback
puffpergzip_packedmostra il tipo di compromesso tecnico necessario per portare MTProto su target storici. - La roadmap punta all’update loop completo, poi session management, gruppi/canali avanzati, media e UI.
- Il repository GitHub e le release pubbliche sono il punto di partenza per tester e contributori.