Development diary: this article is part of the RetroLab saga on Telegram Amiga. The full journey is collected in the Telegram Amiga development diary, kept aligned with the real status of the MTProto client and linked to the GitHub repository.
Bringing Telegram to Amiga in 2026 looks, at first glance, like one of those ideas born to hurt yourself with style. That’s partly true. But it’s also a very concrete experiment: taking a modern ecosystem based on HTTPS, APIs, tokens, JSON and contemporary network expectations, and making it talk to systems born in a completely different technical era.
The Telegram Amiga project does not start from the illusion of turning a classic Amiga into a smartphone. The goal is more interesting: to build a diagnostic and progressively useful client that can verify TLS/AmiSSL connections, Bot API calls, reading updates, sending messages and managing state. First you prove that the road exists; then you decide how much traffic to push through it.
On AmigaOS 3.x the first point is not the interface, but technical survival. You need libraries, a working TCP/IP stack, TLS, compatibility with real toolchains and a sane way to configure tokens and chats. Even a simple getMe call to Telegram becomes an integration test between the modern world and a historical machine. When it works, it’s not just a JSON reply: it’s the system proving it can still talk to the present.
Why start from the Bot API
Using the Bot API is not a lazy shortcut, it’s a cautious technical choice. The full Telegram client protocol is much more demanding: it requires user authentication, session handling, MTProto and a load of complexity that only makes sense to tackle after you’ve stabilised networking, TLS, parsing and command flow. The Bot API instead lets you build an incremental path: read messages, send replies, manage offsets and observe real behaviour without dumping the entire architecture on the machine’s shoulders from day one.
It’s the same principle that, in serious retrocomputing, separates enthusiasm from fluff. First the diagnostic tester. Then the client. First the log. Then the pretty screen. First you prove that the cable carries current, then you argue about the colour of the button.
AmigaOS 4, AROS and the problem of remote development
The most modern part of the project is not Telegram, it’s the workflow. To really develop on different targets you need to be able to compile, copy binaries, run tests and collect output without turning every iteration into a religious ceremony. On AmigaOS 4.x, a Pegasos II VM under QEMU reachable over the network already allows for a sane work cycle: sources on the Mac, build and test on the target.
On AROS the problem is similar but rougher. That’s where the parallel work on BebboSSH for AROS comes from: having working SSH/SFTP/SCP is not a sysadmin vanity, it’s the minimum infrastructure needed to develop without going mad. If the retro or retro-compatible system can’t be reached, automated and observed, every test becomes manual. And “manual”, when you compile often, is just entropy with nostalgia built in.
What actually changes
The value of the project is not “sending a Telegram message from an Amiga” as a circus trick. The value is proving that a historical system can still be part of a modern workflow if you build the right adapters around it. TLS, APIs, SSH, preflight scripts, configuration files and logging don’t ruin the Amiga: they let it remain a live, usable, queryable machine.
RetroLab exists exactly for this: to treat retrocomputing as an operational lab, not a display case. Old machines are not interesting because they are old. They’re interesting when they force you to really understand memory, networking, limits, toolchains and compromises. If something works there, it often means it has truly been understood.
In short
- Telegram Amiga starts out as a diagnostic tester, not as a full final client.
- The Bot API allows for an incremental path: TLS, getMe, getUpdates, sending messages and offsets.
- Remote development via SSH/SFTP is crucial for AmigaOS 4 and AROS.
- RetroLab will use these projects to show live retrocomputing, porting and the real limits of these machines.