Indice della guida
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, 20 ottobre 2026: la Alpha 0.0.97, uscita il 19 ottobre, aggiunge notifiche e popup, schede chat nella TUI, foto più rapide sugli Amiga classici e meno uso di memoria. Il capitolo 16 racconta questa tappa. Il diario gemello è disponibile in inglese.
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
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 si è concretizzata: la 0.0.92 ha portato link preview, sticker e video con frame; la 0.0.93 ha aggiunto emoji, PNG e un percorso alternativo di login; la 0.0.94 ha allargato il supporto ad AROS ARM64 e consolidato la persistenza. La 0.0.95, raccontata nel capitolo seguente, affronta i tempi morti dei trasferimenti e dell’avvio. La 0.1.0 resta una beta senza nuove feature: prima serviranno un ciclo tranquillo, nessun freeze noto, una revisione avversariale e testi aggiornati.
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 12: emoji, PNG e un login più onesto
La 0.0.93, pubblicata il 12 settembre 2026, è la release in cui Telegram Amiga comincia a occuparsi con più decisione di ciò che parte dal client. Il picker delle emoji si apre dal menu con Amiga+E o dal pulsante smiley, mostra 109 caratteri, conserva i recenti e funziona con mouse, tastiera ed ESC. Nella GUI le emoji vengono disegnate come immagini da 16 pixel, mentre la TUI conserva la rappresentazione testuale; l’invio usa comunque il carattere Unicode reale.
La scelta non è solo estetica. Le emoji sono abilitate separatamente dalle foto inline e il default tiene conto dei limiti dell’hardware: AGA/ECS/OCS nativi e 68k sotto il 68040 partono con la funzione spenta, mentre 68040+ e RTG possono sostenerla. È un esempio piccolo ma significativo del modo in cui una funzione moderna deve essere mediata da soglie concrete quando il client vive su piattaforme così diverse.
Le PNG ora possono seguire il percorso delle foto, con menu, drag-and-drop, TUI /photo e didascalie. Il controllo legge la struttura reale del file fino a IEND, rifiuta i file troncati e limita dimensioni e proporzioni prima dell’upload. L’errore del server viene trasformato in una spiegazione leggibile, non in un generico fallimento.
Il login gestisce meglio il caso in cui il codice non arrivi nel percorso previsto: dopo l’attesa, la schermata propone normalmente l’SMS e la TUI accetta S. La diagnostica registra il percorso e l’attesa, mentre la gestione dei nuovi codici corregge il caso en-US rispetto a en. Anche l’aggiornamento delle anteprime è più completo: quando i metadati arrivano dopo l’invio, la chat aperta viene aggiornata e la preview entra nella cache della trascrizione.
Questa tappa aggiunge anche una lezione di manutenzione: il supporto non è uniforme solo perché il codice è comune. Emoji, PNG, popup MorphOS, font, puntatori e login hanno tutti bisogno di percorsi specifici. La portabilità non significa fingere che le macchine siano uguali; significa costruire una base comune abbastanza disciplinata da rispettare le loro differenze.
Capitolo 13: alpha 0.0.94, sei piattaforme e il filesystem che non perdona
La 0.0.94 è una release di portabilità nel senso più concreto del termine. AROS ARM64 non viene aggiunto come riga cosmetica nella tabella: il pacchetto è costruito dallo stesso commit degli altri target e viene provato su Raspberry Pi 400 con login, chat, history, foto, documenti e download. Il progetto ora parla davvero a sei macchine diverse, non a cinque build più una promessa.
Il caso più istruttivo è arrivato dal filesystem FAT di AROS. Una riscrittura in-place poteva dichiarare successo e lasciare un file vuoto: login salvato, lista chat, seed casuale, avatar e geometria della finestra diventavano fragili proprio nel momento in cui l’utente riavviava il client. La soluzione è stata centralizzare la sostituzione dei file: eliminare, ricreare, scrivere e sincronizzare mentre il file è ancora aperto. È una decisione poco spettacolare, ma la persistenza è parte del client quanto il protocollo MTProto.
La stessa attenzione al comportamento reale ha corretto l’aggiornamento dei download. Prima ogni percentuale ridisegnava la finestra intera, facendo lampeggiare le foto inline su Vampire. Ora il progresso copia soltanto la striscia di stato dal buffer off-screen, restituendo circa 260 millisecondi per ogni parte da 32 KiB. Anche l’ARM loader riceve il suo fix: -fno-common evita i simboli che il loader ELF rilocabile rifiuta, mentre i self-test GUI condividono il modello fuori dallo stack e passano su AROS ARM.
Intorno al codice arrivano le icone di Carlo Spadoni per ogni piattaforma e per il drawer, la preview immediata quando Telegram possiede già i metadati e il fallback Latin Extended-A per non lasciare buchi nei nomi internazionali. È manutenzione, ma è proprio questa manutenzione a trasformare un port in un programma che può restare acceso e salvare il proprio stato.
Il release ARM64 su GitHub e il pacchetto AROS Archives rendono verificabile il nuovo target. La pagina di release bilingue raccoglie anche i link Aminet per AmigaOS 3, AmigaOS 4, MorphOS, AROS i386 e AROS x86_64. La 0.0.95 è ora disponibile per tutti e sei i target supportati.
Capitolo 14: alpha 0.0.95, meno attesa nei trasferimenti
La 0.0.95 è la release di velocità anticipata dal capitolo precedente. Il client manda più parti di download e upload in parallelo: nel test TUI su Vampire il download passa da 97 a 191 KB/s e l’upload da 112 a 213 KB/s. Su un MorphOS reale un download da 4 MB arriva a 1,35-1,6 MB/s e l’upload di un file da 4 MB tocca 530-590 KB/s, contro circa 210 KB/s con una parte alla volta. Sono misure di test, non valori garantiti per ogni rete o configurazione.
Il parallelismo cambia anche il modo di gestire le risposte: i download possono arrivare fuori ordine e vengono riordinati prima di essere scritti; per l’upload il client ricorda le parti non confermate e, se qualcosa devia dal previsto, riparte in modo conservativo dalla prima parte ancora da inviare. Ogni file di test caricato è stato riscaricato e confrontato con l’originale.
La prima apertura migliora senza nascondere il costo: su un 68030 a 14 MHz il test con WinUAE mostra la finestra dopo circa 14 secondi invece di 89. Lo scambio della chiave per le foto di un altro datacenter prosegue dopo l’apertura e una volta sola per datacenter. Arriva anche l’opzione Full-size photos, spenta di default, per visualizzare copie più grandi e salvare l’originale Telegram; sui 68k richiede più tempo e alcuni megabyte di memoria, quindi resta una scelta consapevole.
Il client TUI può inoltre leggere comandi da script o input rediretto, utile per prove ripetibili. La scheda della release 0.0.95 raccoglie i risultati e i download per tutte le piattaforme; la versione inglese è disponibile in parallelo.
Capitolo 15: alpha 0.0.96, far respirare l’A1200
La 0.0.96 è nata da una prova su A1200 stock: ogni lettera impiegava circa tre secondi ad apparire, perché il client ridisegnava tutta la finestra dopo ogni tasto. Da 0.0.8 il solo campo di testo veniva aggiornato su AfA OS, ma non sugli altri sistemi. Ora si copia sullo schermo solo la striscia dell’input finché la sua altezza non cambia. Se un ridisegno completo costa più di 300 ms, messaggi e avvisi di digitazione attendono una pausa di due secondi; le macchine veloci continuano ad aggiornarli subito.
Per non riconsegnare la tastiera al ridisegno dopo una pausa troppo breve, l’attesa si adatta alla durata dell’ultimo aggiornamento, fino a dieci secondi. La misura e l’impaginazione dei testi sono state riviste: in una chat impegnativa su A1200 emulato ciclo per ciclo, un ridisegno è passato da circa sei a 0,9 secondi. L’altezza dei messaggi viene conservata con una chiave che tiene conto di testo, larghezza, font ed emoji; nel caso documentato dal changelog, si evitano migliaia di misurazioni ripetute. Un avviso «sta scrivendo» ridisegna soltanto l’intestazione della chat.
Il menu contestuale aggiorna il proprio riquadro, non la finestra intera. Gli avatar appaiono prima come iniziali e si preparano nei momenti di inattività: sotto il 68040 vengono elaborati nella dimensione 20×20 della lista, con decodifica JPEG ridotta. Il risultato si conserva in avatars/*.rgb per l’avvio successivo. La nuova opzione Settings > Show avatars può eliminare del tutto download ed elaborazione delle immagini profilo, lasciando le iniziali. Sugli schermi AGA con 32 o 64 colori, una nuova assegnazione delle penne evita che le emoji gialle diventino marroni.
Anche l’attesa della rete è diventata visibile e interrompibile. La finestra si apre subito sulla lista chat in cache con «Connecting to Telegram…»; un errore viene spiegato nella barra di stato, e le chat nascoste restano tali anche offline. Su AmigaOS 3 e 4 l’apertura della connessione ha un limite di 15 secondi; le attese di rete avanzano a intervalli di un secondo e, dopo due, la chiusura della finestra può interromperle. Dopo perdite ripetute, la riprova si allunga progressivamente da cinque secondi a un minuto. Prima di iniziare un download in RAM: si controlla la memoria libera, evitando il vecchio fallimento a trasferimento quasi concluso; se il volume si riempie, GUI e client testuale indicano i KB già scritti.
Il cambio di modalità o colori del Workbench non deve più restare bloccato dalla finestra del client: questa si chiude all’avviso del sistema e si riapre mantenendo connessione e chat. Su AmigaOS 3 serve screennotify.library in LIBS:; OS4 e AROS usano Intuition, MorphOS la propria libreria. Al ritorno, campo di scrittura, testo non inviato e scroll riflettono lo stato reale. Sono stati corretti anche il salvataggio della finestra alla dimensione minima, l’allineamento del testo di login, la spaziatura delle bolle, i colori delle superfici su Workbench OS4 a 16 bit e l’ora dei messaggi sulle macchine prive di orologio a batteria.
Una cartella dati copiata tra macchine diverse ora conserva come auto le preferenze per foto inline ed emoji uguali al default della macchina: un A1200 non eredita più per errore la scelta pesante di un sistema veloce. La GUI si chiude con Amiga+Q o con il gadget, non con una semplice Q o con un ESC digitato dopo aver annullato l’input.
Infine, le distribuzioni diventano sette. Il nuovo archivio per il 68000 semplice contiene il solo client testuale, pensato per circa 2 MB di Fast RAM libera; il primo login si fa su una macchina più veloce o in emulazione, poi si trasferiscono autenticazione e dati. Anche AROS aarch64 per Raspberry Pi 4, 400 e 5 è su Aminet. I dettagli, i limiti e i link ai sette pacchetti sono nell’articolo completo sulla 0.0.96 e nel changelog.
Capitolo 16: alpha 0.0.97, esserci senza interrompere
La 0.0.97, pubblicata il 19 ottobre 2026, affronta un passaggio meno appariscente di una nuova funzione multimediale: poter lasciare Telegram Amiga aperto mentre si fa altro. La 0.0.96 aveva tolto molto lavoro inutile alla digitazione sul classico A1200. Ora la domanda è come far sapere che è arrivato un messaggio senza imporre di tenere la chat davanti, senza rubare il focus e senza introdurre dipendenze diverse per ogni sistema.
Un popup del client, non sette integrazioni diverse
La soluzione comprende conteggio nel titolo, popup disegnato dal programma e un breve suono opzionale tramite AHI o il chip audio Amiga. Il popup rimane dieci secondi, adatta il carattere allo schermo e diventa un ingresso diretto alla conversazione solo quando lo si clicca. Iconificare non deve più significare smettere di ricevere: con le notifiche attive il client continua a leggere la rete, aggiorna il numero sull’AppIcon e può avvisare sul Workbench. Se si sceglie Off, torna invece al vecchio comportamento di riposo.
Anche qui il classico non viene trattato come una macchina veloce rimpicciolita. Sotto il 68040 o senza scheda grafica il default è il solo conteggio, mentre le configurazioni adatte mostrano l’anteprima del testo. Una scelta esplicita resta memorizzata. La distinzione evita di pagare per un effetto grafico che su una macchina lenta potrebbe diventare esso stesso un’interruzione.
Una barra IRC chiesta da chi usa il 68000
Il client testuale aggiunge la barra delle chat sotto la prima riga: F1-F10 hanno finalmente una destinazione visibile, con posizione stabile, chat attiva evidenziata e stella per le novità. La richiesta nasce dalle prove sul 68000 e richiama i client IRC. Il comando /move permette di scegliere quali conversazioni tenere sotto i primi tasti; anche la GUI rispetta quell’ordine. La versione compatta lascia spazio ai messaggi sulle console strette.
Il resto è rifinitura concreta: avvio con tre righe di aiuto, prompt che nomina la chat, proprie righe indicate con You, comandi quotidiani per primi e messaggi esterni alla lista contati senza sommergere il testo di righe anonime. Il ringraziamento a Paolo Arus (DaRkHoRaCe) non è una formula: le prove ripetute sull’A600 hanno reso possibile il pacchetto per il 68000, che continua a contenere soltanto la TUI.
Non ridisegnare quello che esiste già
Le foto sugli schermi fino a 256 colori venivano ricostruite con moltissime operazioni a ogni ridisegno. Preparare invece una bitmap nel formato dello schermo permette di ricopiarla con il blitter finché dimensioni, qualità o schermo non cambiano. La misura documentata sull’A1200 stock emulato passa da 2,7-3 secondi a circa 0,45 per una chat con una foto, dopo il costo iniziale di preparazione. Non è una misura del trasferimento di rete e non è un nuovo test eseguito per aggiornare questo diario.
La stessa attenzione al lavoro evitabile porta il caricamento della TUI 68000 da 1,53 a 1,32 MB e riduce di circa 500 KB la GUI AmigaOS 3. Condividere buffer mai contemporanei costa meno che chiedere all’utente altra memoria. Il pacchetto 68000 mantiene comunque l’indicazione pratica di circa 2 MB di Fast RAM libera e un primo login preparato su una macchina più veloce. Le moltiplicazioni grandi richieste dalle potenze crittografiche calano di circa il 17%, senza spacciare quel dato per una riduzione garantita dell’intero accesso.
Le informazioni che prima sparivano
I messaggi di servizio ora rendono leggibili ingressi, uscite e cambiamenti dei gruppi senza generare notifiche. Le bozze non fermano più l’elenco delle chat; gli orari dei messaggi inviati e le seconde spunte vengono completati dagli aggiornamenti corretti. Ctrl-C chiude davvero finestra e processo; AROS può interrompere anche una connessione senza risposta. Il login distingue codice scaduto, numero errato e attesa imposta da Telegram. Cirillico e greco vengono traslitterati, senza pretendere che questo equivalga a un renderer Unicode completo.
Restano problemi dichiarati, fra cui il raro crash non riprodotto della VM AROS x86_64 e il lampeggio del menu contestuale MorphOS su schermo proprio. Sono distinti dal fix delle foto MorphOS e non vengono cancellati dal racconto della release. La 0.1 beta resta un obiettivo successivo. Tutti i dettagli e i sette download sono nell’articolo completo sulla Alpha 0.0.97; i pacchetti GitHub sono stati controllati per SHA-256 e integrità ZIP e Aminet riporta la stessa versione per tutte le piattaforme.
In breve
- Telegram Amiga è un client 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, AROS x86_64 e AROS ARM64.
- Il fallback
puffpergzip_packedmostra 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 ha portato link preview, sticker e frame video; la 0.0.93 ha aggiunto emoji, PNG e un login alternativo; la 0.0.94 ha esteso il supporto ad AROS ARM64 e consolidato la persistenza; la 0.0.95 accelera download e upload, migliora l’avvio e introduce la scelta per le foto a dimensione piena.
- La 0.0.96 rende più rapida la digitazione e aggiunge il pacchetto TUI per il 68000; la 0.0.97 porta notifiche e popup, schede chat nella TUI, meno memoria e foto più rapide da ridisegnare sui classici. I pacchetti sono sette.
- 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.