AndroidLab Dal retrocomputing all'AI, passando per Android.
Telegram su Amiga: diario di un client MTProto in C

Telegram su Amiga: diario di un client MTProto in C

by

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?

Ultimo aggiornamento, 5 settembre 2026: il progetto è arrivato alla release alpha 0.0.92. Dopo l’ingresso delle foto inline nella 0.0.9 e la rifinitura dell’invio con didascalie nella 0.0.91, questa release aggiunge anteprime dei link, frame per i video, etichette più chiare per gli allegati, messaggi lunghi senza il vecchio limite del buffer e download che riconoscono gli eseguibili dal formato reale. Questo diario resta l’indice vivo del percorso: gli articoli di release raccontano le singole tappe, mentre qui tengo insieme la direzione tecnica complessiva.

Capitolo 11: una conversazione più ricca

La 0.0.92, pubblicata il 4 settembre 2026, porta nel client contenuti che prima venivano trattati quasi come testo grezzo. Quando Telegram fornisce metadati utili, un link può mostrare sito, titolo e prima riga della descrizione. Se arriva anche una foto di anteprima, viene consegnata alla pipeline già usata per le immagini inline. Se il server sta ancora preparando i dati, Telegram Amiga aspetta invece di indovinare.

I video possono ora mostrare uno still con durata e dimensione. Il thumbnail segue la stessa pipeline delimitata delle foto, con cache su disco, pacing, rispetto dell’impostazione Inline photos e nessun download duplicato. Gli sticker senza decoder WEBP conservano la loro emoji, mentre le etichette di sistema descrivono meglio sticker, video, messaggi vocali, musica e file.

La correzione più concreta riguarda il testo lungo: il percorso di invio non è più vincolato al vecchio buffer da 512 byte e il composer avvisa quanto testo è stato effettivamente acquisito dopo un incolla troppo grande. Anche i download diventano più corretti: il bit executable viene deciso dai magic bytes, con riconoscimento degli eseguibili HUNK 68k e ELF per AmigaOS 4, MorphOS e AROS, preservando gli altri protection bit active low di Amiga.

Il pannello di login indica dove Telegram ha inviato il codice e quante cifre aspettarsi. Inoltre, i simboli senza corrispondenza Latin-1 non lasciano più uno spazio fantasma nella riga. Sono dettagli poco appariscenti, ma questo è esattamente il genere di manutenzione che trasforma una demo funzionante in un client utilizzabile.

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. La release 0.0.7 pubblica pacchetti per AmigaOS 3.x, MorphOS, AmigaOS 4.x, AROS i386 e AROS x86_64. Il quinto target entra quindi nel set completo delle release, mentre il lavoro di hardening continua a tenere conto delle differenze tra runtime, ABI e toolchain. Dirlo con precisione 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.

Capitolo 5: i file entrano nel client

La 0.0.6 è il passaggio in cui Telegram Amiga smette di trattare il testo come unico oggetto interessante. Il client riconosce i documenti nella cronologia, mostra nome e dimensione, scarica gli allegati in streaming nel cassetto downloads/ e permette di inviare file locali dalla GUI tramite il requester ASL. Il limite attuale è 10 MB, coerente con l’obiettivo di restare un client leggero e verificabile su cinque famiglie di sistema.

Il lavoro ha richiesto di portare nel core il livello TL dei documenti, i percorsi upload.saveFilePart e upload.getFile, il trasferimento a chunk e la gestione dei riferimenti al file. I buffer sono stati corretti anche per OS4, MorphOS e AROS: un trasferimento non è davvero portabile se funziona soltanto sulla macchina di sviluppo.

La nuova chat Messaggi salvati completa il quadro. Il proprio account diventa un cassetto cloud per spostare un file dal telefono all’Amiga o dall’Amiga al PC, mantenendo il trasferimento dentro Telegram invece di aggiungere un servizio parallelo. È una funzione semplice, ma trasforma il client in uno strumento che può entrare nel flusso quotidiano.

Capitolo 6: un binario, due icone e un avvio più pulito

La 0.0.6 cambia anche il modello di avvio. Il vecchio nome telegram-test lascia posto a TelegramAmiga; gli script IconX non vengono più distribuiti e due icone Workbench selezionano GUI o TUI sopra lo stesso binario. È una soluzione più pulita, ma coinvolge un punto delicato dei sistemi Amiga: interpretare gli argomenti WBStartup, aprire una console CON: quando non esiste e riagganciare correttamente i flussi standard del runtime C.

Il percorso è stato verificato e la TUI è nuovamente utilizzabile dalla propria icona Workbench. Il cambiamento resta comunque interessante dal punto di vista tecnico: il core MTProto, la GUI, la TUI e il trasferimento file condividono ora un pacchetto più ordinato, ma restano componenti separati abbastanza da poter essere diagnosticati e migliorati senza confondere un problema di avvio con un problema di protocollo.

Il diff tra alpha 0.0.6 e alpha 0.0.7 mostra il cambio di scala: non solo file sharing, ma anche trasferimenti ritentabili e cancellabili, selezione e clipboard, aggiornamenti live, TUI con drop, ricerca UTF-8 e correzioni di portabilità sui buffer e sulle risorse di piattaforma.

Capitolo 7: quando il file diventa trasporto

La 0.0.7 è la prima release in cui il file sharing smette di essere soltanto una funzione aggiunta al client e diventa un problema di trasporto vero. Upload e download usano chunk dimensionati per il target, ritentano le parti perse, riconnettono un socket incastrato e distinguono un link lento da un link morto. Un test da 152 MB su PowerPC ha dato una misura concreta del salto, molto più utile di un generico “supporto ai file grandi”.

Il percorso resta deliberatamente onesto: il trasferimento blocca ancora la finestra, i file su altri data center o sulla CDN di Telegram non sono ancora coperti e i limiti dipendono dalla piattaforma. Ma ora il codice espone chiaramente i suoi confini: 125 MiB su 68k, 250 MiB sugli altri target, 32 KiB di chunk su m68k e 64 KiB altrove.

La stessa release chiude il cerchio sull’interazione. La GUI ha un vero menu Edit con selezione tramite mouse o Shift+frecce, reply con doppio clic e aggiornamenti remoti mentre si scrive; la TUI può inviare e scaricare file e ricevere drop dal Workbench. In parallelo, l’hardening per A1222, MorphOS, AROS x86_64 e le Classic API ricorda che la portabilità non è una casella da spuntare: è una collezione di dettagli che devono continuare a funzionare insieme.

Capitolo 8: trasferimenti 2.0 e topologia Telegram

La 0.0.8 cambia il significato pratico del file sharing. Nella 0.0.7 il client sapeva già trasferire documenti grandi in streaming, ritentare i chunk e annullare un’operazione; la finestra però restava occupata fino alla fine. Ora il trasferimento avanza un chunk per giro di event loop e restituisce il controllo a input, disegno e ricezione messaggi. Posso cambiare chat, continuare a scrivere e lasciare che il file proceda senza trasformare l’interfaccia in una porta chiusa.

La separazione architetturale è importante: upload e download usano una seconda sessione MTProto dedicata, mentre la sessione della chat resta responsabile del flusso interattivo. I download possono mandare avanti la richiesta del chunk successivo mentre il precedente arriva; se la pipeline non è affidabile sul percorso concreto, il client torna al trasferimento sincrono già verificato. Non è ottimizzazione per il gusto dell’ottimizzazione: è un modo per migliorare la latenza senza sacrificare il fallback.

La stessa release porta il client oltre il presupposto implicito “tutto vive nello stesso data center”. Documenti e avatar fotografici su DC esterni vengono scaricati con chiavi per-DC, handshake iniziale, cache locale e gestione di FILE_MIGRATE. È un passaggio tecnico meno visibile di una nuova icona, ma più vicino alla realtà del servizio Telegram: la rete non è un cavo unico tra Amiga e server, è una topologia che il client deve seguire.

Nel frattempo la sidebar diventa più rispettosa del lavoro dell’utente. Filtra mentre si digita, cerca prima nei dialoghi propri, può ritrovare una chat rimossa dalla lista e forza un reload paginato quando la lista iniziale è incompleta. Le chat nascoste restano nascoste attraverso riavvii e reload, mentre l’archivio viene escluso dalla lista principale. La curation locale non è un lusso: è ciò che impedisce a una lista Telegram ampia di diventare rumore.

AfA_OS e il costo reale della compatibilità

Il lavoro su AfA_OS 4.8 è stato un promemoria molto concreto. La GUI usa un buffer off-screen per evitare il flicker, ma Text() su un RastPort senza layer può congelare il sistema nel primo paint. La 0.0.8 identifica AfA e usa BltTemplate() con le stesse metriche bitmap impiegate dal layout e dal caret; la digitazione ridisegna soltanto la striscia del composer. Gli altri sistemi continuano sul percorso nativo.

La correzione specifica ha costretto a mettere ordine anche nella parte comune: resize accorpato, attesa del blitter prima del rilascio del buffer, ridisegno mirato e refresh finale del frame Intuition. Durante la stessa indagine è stato separato un problema esterno: icon.library 51.4.533 di alcune installazioni AmiKit può corrompere SysBase con Directory Opus e causare crash anche a Telegram spento. Un bug del client e una libreria di sistema difettosa non sono la stessa cosa; diagnosticarli come se lo fossero avrebbe prodotto solo altro fumo.

Dal trasferimento alla disciplina di progetto

La 0.0.8 contiene anche molte correzioni minute: URL brevi cliccabili, popup dimensionati dal font reale, right-click fuori finestra, paste con CR/LF, testi UTF-8 lunghi, percentuali oltre 41 MiB, timeout che sopravvivono a un clock spostato indietro e reconnect puliti davanti a risultati RPC vecchi. Sono dettagli, ma la stabilità di un client nasce dalla somma dei dettagli che smettono di sorprendere l’utente.

Il packaging ora controlla l’architettura contenuta negli archivi, mentre AmigaOS 4 usa le API native per porte e IO request. Il CHANGELOG è incluso nei pacchetti, la data 31.07.2026 è coerente con la versione 0.0.8 e il README non promette più come “futuro” ciò che la release ha già risolto. Anche la documentazione è parte del software: se dice una cosa diversa dal binario, il sistema ha due comportamenti concorrenti.

Capitolo 9: le foto inline entrano nel client

Telegram Amiga GUI in esecuzione su AmigaOS 4
Telegram Amiga GUI in esecuzione su AmigaOS 4. Screenshot reale del progetto, inserito come documentazione dello stato attuale.

La 0.0.9 è la release più impegnativa del progetto finora. Ogni foto che entra in una bolla della GUI attraversa sei fasi: stripped thumbnail, fetch bounded, decode progressivo a tre passaggi, dithering su palette, cache canonica RGB888 e redisplay, senza bloccare la GUI, su CPU dal 68020 a 14 MHz fino a PowerPC G4 e x86_64, su schermi dall’AGA 16 colori all’RTG true color.

Il thumbnail stripped incorporato nel messaggio Telegram dà un’anteprima sfocata istantanea. Poi, nei cicli di idle, il client scarica un JPEG bounded e lo decodifica in tre passaggi di qualità: 1/8, 1/4, dettaglio finale. Input, scroll e resize hanno priorità. Il risultato finale viene tenuto in una cache canonica RGB888 versione su disco, così riaprendo una chat già vista le foto si caricano dalla cache senza decodificare di nuovo il JPEG.

Il decode non usa più stime fisse di CPU: ogni fase misura il tempo reale di esecuzione, con budget indipendenti per JPEG decode, cache read e photo replay. Il decode segue il viewport visibile, e la cache canonica LRU a 4/6 slot non sfratta le foto attive. Su AmigaOS 3 RTG i pixel RGB888 vanno direttamente al driver cybergraphics; su AGA e non-RTG resta il pen-grid renderer con dithering ordinato. MorphOS è passato al pen-grid collaudato dopo che il percorso RGB888 produceva foto grigie su alcuni driver.

Il viewer foto a dimensione fissa si apre cliccando una foto (anche l’etichetta [Photo] se le foto inline sono disattivate). Il tasto S salva, il menu contestuale offre Save photo as..., e il salvataggio chiede conferma prima di sovrascrivere. I file JPEG possono essere inviati come foto native dalla GUI, dal Workbench drop o dal comando TUI /photo; sopra 10 MiB vengono inviati come documenti.

Il menu Telegram ha ora una sezione Settings con preferenze persistenti: download drawer, toggle foto inline, Photo dithering (Full, Light, Off) e Photo cache limit (10, 50, 200 MiB o Unlimited). Su AmigaOS 3 il valore di primo avvio delle foto inline viene scelto dallo schermo e dalla CPU: disattivato senza RTG o sotto 68040, con rilevamento automatico degli upgrade hardware.

L’inoltro dei messaggi è finalmente arrivato: verso Messaggi Salvati dal menu contestuale, verso un’altra chat tramite Forward to... con selettore basato sulla ricerca locale. La TUI offre /forward, /forward <id> e /forwardto. Le chat nascoste restano nella cache locale con indicatore (hidden) e tornano in sidebar all’apertura.

La TUI ora va a capo con word-wrapping su console strette. I log temporanei vivono in T: e vengono puliti. I lanci da shell portano stack minimo 1 MiB. I JPEG con didascalia mostrano entrambi. Le foto MorphOS non sono più grigie. Il fetch, decode e replay delle foto restano sospesi durante il resize. La diagnostica live opt-in identifica ogni fase senza loggare contenuti.

Capitolo 10: la rifinitura dopo le foto

La release 0.0.91 non apre un nuovo fronte multimediale: mette in ordine quello che la 0.0.9 aveva reso possibile. Il nuovo dialogo per l’invio foto è condiviso da menu, requester e Workbench drop; mostra nome e dimensione, conserva il draft fino all’avvio dell’upload e porta la didascalia sia nel percorso foto sia nel fallback documento. La TUI usa /photo <path> .

La parte visibile della GUI riceve una rifinitura coerente: un avatar accompagna il nome della chat aperta, i messaggi consecutivi dello stesso mittente vengono raggruppati e bolle, badge e pulsante per i nuovi messaggi adottano forme arrotondate. Caret, reply strip, contatori unread e iniziali degli avatar usano ora la metrica reale del font invece di una baseline stimata.

Sotto la superficie, il client segnala la perdita di una voce della cache invece di tentare fetch infiniti, lascia respirare il bootstrap della lista chat sul 68000 e rimuove i self-test offline dai pacchetti. La CI continua a controllare il codice sul build host, mentre la diagnostica di campo resta inclusa nei binari distribuiti. È ottimizzazione con una ragione, non amputazione cosmetica.

La roadmap ora è esplicita: la 0.0.92 porta link preview, sticker e video con frame; la 0.0.93 affronta emoji picker e PNG; la 0.0.94 raccoglie velocità dei trasferimenti, difetti MorphOS, foto sotto AfA_OS e 2FA sui 68k lenti. La 0.1.0 sarà una beta senza feature nuove: prima serviranno un ciclo tranquillo, nessun freeze noto, una revisione avversariale e testi aggiornati.

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, foto e chat mode interattiva.
  • Il lavoro copre AmigaOS 3.x, MorphOS, AmigaOS 4.x, AROS i386 e AROS x86_64.
  • Il fallback puff per gzip_packed mostra il tipo di compromesso tecnico necessario per portare MTProto su target storici.
  • La 0.0.7 ha introdotto trasferimenti grandi e cancellabili, editing GUI, aggiornamenti live, TUI file/drop e ricerca dei nomi accentati.
  • La 0.0.8 rende i trasferimenti non bloccanti, aggiunge multi-DC, ricerca locale, drag-and-drop, drawer configurabile e workaround AfA_OS.
  • La 0.0.9 aggiunge foto inline, viewer, invio JPEG, inoltro messaggi, cache configurabile, dithering e chat nascoste nella cache locale.
  • La 0.0.91 rifinisce l’invio foto con didascalia, la leggibilità della GUI, la cache, il percorso 68000 e il peso dei pacchetti.
  • La 0.0.92 porta link preview, sticker e frame video; la roadmap prosegue con emoji e PNG nella 0.0.93, velocità e difetti aperti nella 0.0.94, poi con il gate beta 0.1.0.
  • Restano fuori reaction, gestione completa dei contatti e alcuni file serviti dalla CDN Telegram.
  • Il repository GitHub e le release pubbliche sono il punto di partenza per tester e contributori.

Fonti e materiali

AUTORE

Informatico, sviluppatore e sistemista con una lunga storia tra codice, server Linux, retrocomputer e piattaforme e-learning. Su AndroidLab porta uno sguardo tecnico e pragmatico: meno fumo da brochure, più attenzione a infrastruttura, usabilità, privacy, aggiornamenti e conseguenze concrete delle scelte dei produttori.

Leave a Comment