On this page
Telegram on an Amiga interests me as a program, not an exercise in producing a screenshot: open a conversation, reply, move a file and leave the client running while doing something else. This diary reconstructs the development of Telegram Amiga, a native MTProto client written in C, from the diagnostic experiment to Beta 0.1, now named Amigram.
Latest update, November 8, 2026: added Alpha 0.0.99 and Amigram Beta 0.1, released on November 7. Post-release work remains distinct from the available archives.
Chapter 1: constraints as a workbench
The initial question was whether an Amiga-family machine could join a real Telegram conversation without delegating everything to an intermediate service. Recreating every Telegram Desktop feature was not the goal. Verifiable foundations were: networking, login, state, text and an interaction loop that did not betray whoever had just pressed a key.
The constraints are not a nostalgic flourish. On a slow processor, a few megabytes of memory and a paletted screen, an inefficient decision becomes visible immediately. Working there forces questions about who owns a buffer, how long a repaint takes and which activity can wait. Those questions remain valid when modern hardware lets us ignore them.
Chapter 2: the probe before the client
The first tool was a diagnostic Bot API client. HTTP, TLS, JSON and polling established whether the targets’ network stacks and toolchains were usable. Before tackling the full protocol, the machine had to connect, read a response and retain progress without losing its state.
A bot is not a personal Telegram account, however. That mode did its job as a probe and remains in the repository for diagnostics; it is not the product’s final direction. Keeping that distinction clear prevents a preparatory stage from becoming the wrong promise.
Chapter 3: becoming an MTProto client
Moving to MTProto changed the nature of the project. The client must create its authentication key, serialize TL objects and handle nonces, RSA, Diffie-Hellman, AES, salts, sequences and sessions. Then come the phone number, login code and Two-Step Verification password when required.
The current version includes its cryptography and does not require MUI, ixemul or AmiSSL for normal client operation. Compressed gzip_packed responses also have an internal path through puff. This does not make the early TLS diagnostics pointless: it means the real client built a different foundation. Saving the session then makes reopening the program possible without repeating login every time.
Chapter 4: read, choose, reply
The first public alphas in June and early July turned the protocol into interaction: chat lists, history, sending text, receiving, replies, editing, deletion, read receipts and avatars. The GUI uses Intuition and GadTools, with drawing controlled by the program; the text client shares the engine without pretending to be a graphical window inside a console.
Getting one message through was not enough. What happened afterwards had to make sense: identify the sender, preserve a draft, follow a remote update and stop the chat list filling with unwanted entries on every launch. Building a client began there, not merely with a successful first handshake.
Chapter 5: files enter the conversation
With 0.0.6 on July 14, documents became client objects: names, sizes, downloads and local-file uploads. The initial implementation had a 10 MB limit, which belongs to that historical stage rather than the current client. Serialization, part-based transfers and buffers had to remain compatible across architectures.
Saved Messages made the result particularly tangible: a transfer drawer between phone, PC and Amiga without introducing another service. Today’s documented file limits are 125 MiB on 68k and 250 MiB elsewhere; content served by Telegram’s CDN remains a separate, incompletely supported case.
Chapter 6: two interfaces, shared work
Workbench launch is part of the program, not packaging to fix at the end. Icons need to open the GUI or TUI without flashing consoles or fragile script chains. Distribution evolved; today’s packages contain both clients, apart from the plain-68000 package, which contains only the text client.
A repeatable workbench was needed around them: cross-compilation, separate toolchains, virtual machines, real hardware and moving binaries to the targets. The aim is a shorter loop between changing something and observing it, without confusing successful compilation with testing on the intended system.
Chapter 7: 0.0.7, transferring is not enough
On July 24, 0.0.7 brought large transfers, progress, retries and cancellation. A slow link should be allowed to continue; a stalled one needs a way out. The GUI gained selection and clipboard operations, double-click replies and remote updates while composing; the TUI joined the file and drop workflow too.
The window still remained busy during a transfer. That boundary matters to the story: supporting files did not yet mean leaving the interface free while a file moved. The following stage grew out of this precise limitation rather than a vague desire to optimize.
Chapter 8: 0.0.8, giving control back
On July 31, 0.0.8 separated transfer work from the interactive flow. Files could advance without occupying the whole window, leaving the client able to read, draw and accept input. Downloads from multiple datacenters, drag-and-drop, local-before-online search and a list remembering removed chats arrived too.
AfA_OS exposed the real cost of compatibility: an apparently harmless graphics call could freeze a particular environment. Appropriate drawing paths, targeted repaints and care around the blitter were needed. A narrowly defined workaround is worth more than pretending the systems are identical. Review and packaging checks also became an explicit part of the release cycle.
Chapter 9: 0.0.9, a photo is a pipeline
Inline photos arrived on August 7. Downloading a JPEG is only the beginning: immediate previews, progressive decoding, screen adaptation, disk cache and a viewer must follow. Every stage has to leave room for typing, scrolling and resizing. The same image has very different costs on AGA and a modern graphics card.
Persistent preferences control inline photos, dithering and cache size. JPEG uploads, forwarding to Saved Messages or another conversation and TUI improvements joined them. This was a move from text with attachments towards richer conversations, not a promise to play every kind of media. The boundary between a preview and playback remained deliberately visible.
Chapter 10: 0.0.91, refining what exists
On August 27, 0.0.91 tidied photo sending with captions, message grouping and GUI geometry. Header avatars, more readable bubbles and badges, and a caret and counters aligned to the actual font did not change the protocol, but they changed how much effort understanding a conversation required.
Removing unnecessary work is development too: offline self-tests left distributed packages, cache handling became more explicit and startup became more considerate of slow machines. Development tests still matter; they do not necessarily need to travel inside every user binary.
Chapter 11: 0.0.92, naming the content
September 4 brought link previews and video frames when Telegram supplies the required data. Labels need to distinguish documents, voice messages, videos and stickers; thumbnails should use the existing pipeline instead of inventing a new engine for each content type. Showing a frame does not mean playing a video.
The same release addressed long text, paste handling and executable-bit detection from file contents. HUNK and ELF packages cannot be treated identically simply because both have been downloaded. Seemingly minor maintenance is what makes an arrived file usable.
Chapter 12: 0.0.93, better sending and login
On September 12, 0.0.93 added the emoji panel, PNGs sent as photos and a clearer login path when Telegram did not deliver a code as expected. File checks inspect actual data, not only the extension; errors must become readable explanations.
The cost of emoji and photos remained governed by hardware. A sensible preference for a fast machine may be heavy on a classic Amiga. Portability means respecting that difference with defaults and choices, not hiding it. A missing login code is a usability problem as well as a protocol problem.
Chapter 13: 0.0.94, ARM64 and persistence
On September 25, AROS ARM64 on Raspberry Pi became the sixth platform. Shared code now had to span another ABI, loader and pointer width. The documentation records validation on a Raspberry Pi 400, distinct from the other targets’ VM tests.
Field reports exposed something less spectacular: rewriting files through AROS’s FAT path could leave state files empty. Saving sessions, chats and preferences is part of the client’s contract. The response was centralized file-replacement handling. The same cycle brought icons optimized by Carlo Spadoni and less expensive progress-bar updates.
Chapter 14: 0.0.95, measuring the wait
On October 7, 0.0.95 tackled transfers and cryptography. More requests in flight, reordered responses and conservative recovery paths made better use of available machines and networks. The project’s published measurements report roughly 97 to 199 KB/s for Vampire downloads and 1.35 to 1.6 MB/s on real MorphOS hardware. These are documented cases, not guaranteed speeds for every system.
Cold startup shows its window before finishing work with photo datacenters. Two-Step Verification on slow 68k machines was reordered to avoid sending Telegram an expired proof: the long calculation precedes a request for a fresh challenge. The documentation records a stock A1200 login completing in 35 minutes. It remains a long wait, not advice to turn 2FA off.
Chapter 15: 0.0.96, letting the A1200 breathe
On October 11, typing was the central problem. Repainting the whole window after every key could cost about three seconds per character on a stock A1200. Updating only the composer, delaying heavy work until pauses and retaining completed work made the interface more practical. A demanding repaint measured on an emulated A1200 fell from around six to 0.9 seconds.
Avatars can be prepared while the user is idle or disabled. The window opens from the cached chat list; network waits, free memory and screen changes are handled more explicitly. A new package for the plain 68000 brought distributions to seven. Repeated tests by Paolo Arus, DaRkHoRaCe, on his A600 were the practical contribution that made that text-client lane possible.
Chapter 16: 0.0.97, being there without interrupting
October 19 brought a title counter, popups, an optional chime and an updated AppIcon. The client could stay iconified and keep following the network. Defaults avoid costly effects on slower classics: learning that a message arrived should not become the next reason typing responds badly.
The TUI gained F1-F10 chat tabs, adjustable ordering and interaction closer to the plain-68000 user’s requests. Service messages, lower memory use, photos copied from a screen-format bitmap and clearer login completed the work. A photo-containing repaint on an emulated A1200 fell to roughly 0.45 seconds after initial preparation: that is not a download-speed measurement.
Chapter 17: 0.0.98, attention and conversations
The October 28 release centres reactions and the right of individual chats to request attention. The React… grid adds or removes a reaction, respects the group’s allowed set and shows counts under messages. The TUI exposes the same feature through /react. Custom and paid reactions retain a simplified representation.
Muting a chat from another device is respected, using Telegram’s time for expiry. Groups and channels do not ring without an explicit choice; silent messages and your own messages sent elsewhere must not create noise. One chat waits half a minute between sounds, while the conversation open in front of you stays quiet.
There are global and per-chat sounds, six original IFF 8SVX samples, selection previews and a three-second playback limit. AROS follows its configured AHI output, while the built-in chime also works with Paula without AHI. The work extends beyond a visible setting: audio must follow the right route for that machine.
Transcript dates, reversible emoticon conversion, literal formatting characters and better avatar and emoji colours complete the everyday changes. Each request keeps its own T: temporary file, preventing photo and upload interference. The notes trace the AROS x86_64 crashes to the e1000 driver: the upstream fix must be checked in the installed image, not assumed everywhere. The 0.0.98 release article gathers features, requirements and every download.
Chapter 18: 0.0.99 and control over chats
Alpha 0.0.99 expanded reactions and added a filter for hiding messages in groups and channels. I improved the text client and fixed cases where menus could act on the wrong message. The Alpha 0.0.99 article covers the details.
Chapter 19: Amigram and the first beta
On 7 November 2026 Telegram Amiga became Amigram with Beta 0.1. The name and icons changed, while the MTProto client, MIT licence and multi-platform project continue. The session and data drawer can be copied from the previous version.
The beta includes the client API credentials, improves filenames for unnamed downloads and adds Shift+Enter. Seven variants are available on GitHub and Aminet. Subsequent fixes for immediate newline display and messages deleted elsewhere are not in Beta 0.1.
Today’s state, without carrying old limitations forward
Amigram Beta 0.1 handles existing accounts, sessions, chats, files, photos, previews, notifications and reactions. It is not a complete replacement for the official client: contacts, albums, media playback and some CDN downloads remain limited. The 68000 package is text-only; AROS x86_64 and ARM64 have platform-specific image and SDK requirements.
After the first beta
Beta 0.1 is released, but limitations and regressions still need testing. Contacts, albums, voice and video playback and some CDN downloads remain unsupported. Themes and translations are future goals, not guaranteed current features.
Try it and contribute
The public repository contains source code, documentation and releases. This is a non-commercial MIT-licensed project, developed with LLM agents used as tools for analysis, implementation and test preparation. Responsibility for choices and outcomes does not transfer to the tool.
The most useful contribution is a reproducible report: version, system, CPU, real or emulated environment, network stack and observed behaviour. Do not publish sessions, numbers, codes, passwords or peer caches. The authentication file is access to an account, not a harmless diagnostic attachment. This editorial revision checked public packages; it did not repeat the hardware tests documented by the project.
In short
- The journey runs from Bot API diagnostics to a native MTProto client with GUI and TUI on a shared foundation.
- Files, photos and conversations have chiefly required control of work, memory and compatibility.
- 0.0.98 brings reactions and per-chat notifications; seven packages are available on GitHub and Aminet.
- Amigram Beta 0.1 is the first beta released under the new name.
- A useful client comes from public code, repeatable tests and people reporting what does not work on their Amiga.
Not a single screenshot…?
You are absolutely right — I have just added a screenshot of the latest release GUI running on AmigaOS 4 directly into the article. Thanks for pointing that out!