Telegram Amiga starts from a simple, slightly stubborn question: can you build a real, text-only Telegram client on Amiga-like systems in 2026, without turning it into a screenshot demo?
The answer, at least today, is not yet “it replaces Telegram Desktop”. That would be marketing, and serious retrocomputing doesn’t need stage smoke. The more honest answer is more interesting: the project has become a pre-alpha MTProto client that can log in with a Telegram account, save local state, read dialogs and history, send text and work as a portable lab across AmigaOS 3.x, MorphOS, AmigaOS 4.x and AROS.
For me the point isn’t nostalgia. It’s the constraint as a test bench. When you try to bring networking, TLS, binary serialization, cryptography and persistent state onto machines born in another era, you’re forced to really understand what’s going on. And that, paradoxically, makes you sharper even when you go back to modern systems, where complexity is often just buried under more comfortable layers.
Chapter 1: starting from a diagnostic client
The first step was deliberately cautious: no MTProto, no user login, no full session. I started by building a diagnostic client based on the Bot API, described in the article Telegram on Amiga in 2026: why start from a diagnostic client.
That phase was there to survey the terrain. Did HTTPS really work? Could the TCP/IP stack on the targets cope? Could OpenSSL or AmiSSL be linked in a practical way? Could the HTTP, JSON, polling, offset and controlled message sending logic survive outside the comfort zone of a modern machine?
At that point the Bot API was a probe, not the final product. It allowed me to verify networking, TLS and the development loop without diving straight into the most delicate part of the Telegram protocol. In other words: first you check whether the bridge holds, then you drive the truck across it.
In the Telegram Amiga repository this phase is still available as a fallback and diagnostic mode, precisely because it remains useful to check networking, TLS and target behaviour.
Chapter 2: the MTProto turn
The real jump came when the project stopped thinking of itself only as a “bot helper” and started behaving like a Telegram client. I wrote about it in the second chapter, Telegram Amiga becomes MTProto: the switch from Bot API to real client.
MTProto completely changes the technical weight of the project. It’s no longer enough to hit an HTTPS endpoint and read JSON. You have to create an auth-key, serialize TL objects, handle nonces, RSA fingerprint, Diffie–Hellman, AES‑IGE, server salt, message IDs, sequences, data centers and local session. Then come phone/code login, possible 2FA password, peer cache, history and sending messages.
This is the difference between “Telegram answers a request” and “this machine is trying to be a client”. It’s an architectural difference, not just another checkbox in the README.
The MTProto code in the repository is the technical core of the project: auth-key, TL serialization, login, peer cache and chat mode are there, not waved around as an abstract promise.
Chapter 3: the surrounding infrastructure
When the target is Amiga-like, code alone isn’t enough. You also need a sane way to develop, copy binaries, run tests and read output without turning every cycle into a manual ritual. That’s where the work described in BebboSSH on AROS: when SSH turns retrocomputing into a real lab comes in.
AROS in particular is a valuable fast lane because it allows quick testing in virtualized or hosted environments, while still being close enough to the Amiga mindset to expose real portability issues. With BebboSSH I can use SSH, SCP and SFTP as development infrastructure: compile or prepare on the Mac, move the binary to the target, run it, watch the output, repeat.
Docker cross-compilation on Mac, per-platform GCC toolchains, QEMU, real hardware and SSH are not decorative accessories. They’re the workbench. Without that, an MTProto client on Amiga risks turning into a heroic but barely repeatable experiment. With that, it becomes a project you can actually measure.
Here too the reference point remains the Telegram Amiga repository, because the editorial side only makes sense if it points to a verifiable project with source code, documentation and releases.
Chapter 4: where we are today
The current state of the code is a public pre-alpha, already far more concrete than the text-only prototype from late May. The main line is MTProto account mode: the client can create the auth-key, drive the login flow with phone number and Telegram code, handle 2FA password checks when Telegram requires them, and save state to telegram-auth.bin.
After login, the client can list dialogs and peers into telegram-peers.txt, read the text history of users, groups and channels/supergroups, and send text to users, groups and channels when the account has the necessary permissions. It is not yet a “rich” client, but the essential read–select–reply path is there.
The interactive chat mode adds the minimum ergonomics needed to use the project as a text-based client: lines with the peer’s name, automatic reading while waiting for keyboard input and commands like /read, /watch, /peer, /peers and /quit. These are small things, but on an Amiga console they are the difference between raw diagnostics and something a human can actually use.
There’s also a technical detail that captures the project’s philosophy well: MTProto gzip_packed replies. On targets where zlib is not a practical choice, Telegram Amiga can fall back to the embedded puff. It’s not a headline feature, but it’s the kind of decision that separates a serious port from “it compiles on my machine, good luck”.
TLS support goes through OpenSSL or AmiSSL depending on the target. The public pre-alpha packages cover AmigaOS 3.x, MorphOS, AmigaOS 4.x and AROS i386; AROS x86_64 remains frozen as a diagnostic lane, because at the moment the standard runtime is still not stable enough to deserve the same level of trust as the other targets. Saying this doesn’t weaken the project: it makes it verifiable.
The pre-alpha releases on GitHub include packages for testers and supporting material, but they do not include any sensitive local files. Auth-key, tokens, numbers, codes, passwords, peer cache and screenshots that show them must not end up online. Here security is not a legal footnote: it’s part of the design.
The state described in this chapter comes from the README and public sources, which remain the most up-to-date way to see what really works and what is still under construction.
What’s missing and where the project is going
The next real focus is the full update loop based on Telegram’s updates and differences. That’s the step that turns the client from “I read and send when I poll” into “I stay aligned with the real state of the conversation”. Without that, Telegram Amiga is already useful as a lab and text-only pre-alpha; with it, it starts to look like a genuinely reactive client.
After the update loop come more robust session management, broader handling of groups and channels, media download/upload, a possibly more comfortable UI and real validation across multiple hardware and OS combinations. The priority, however, stays where it should: first a solid text client, then everything else. In retrocomputing, layering an interface on fragile foundations is just an elegant way to waste weekends.
Trying it and contributing
The repository is public on GitHub: github.com/kaffeine1/telegram-amiga. From there you get to the code, the MTProto documentation, platform notes and pre-alpha releases.
The most useful contribution at this stage is not “let’s add all of Telegram”. It’s methodical testing: exact target, package version, operating system, network, TLS used, command run, non-sensitive output and observed behaviour. Tests on real hardware are worth gold, especially when they distinguish a client issue from a limitation of the network stack, toolchain or environment.
Simple safety rule: never publish telegram-auth.bin, tokens, phone numbers, codes, passwords, peer caches or logs that contain them. If a screenshot proves that it works but reveals login material, it’s not proof: it’s a small bomb left on the table.
In short
- Telegram Amiga is a C-based MTProto pre-alpha for Amiga-like systems, not just a Bot API experiment.
- The project supports Telegram login, auth-key, 2FA when requested, saved state, dialogs, history, text sending and an interactive chat mode.
- The work covers AmigaOS 3.x, MorphOS, AmigaOS 4.x and AROS i386; AROS x86_64 remains a frozen diagnostic lane.
- The
pufffallback forgzip_packedshows the kind of technical compromise needed to bring MTProto to historical targets. - The roadmap targets a full update loop next, then session management, advanced group/channel support, media and UI.
- The GitHub repository and public releases are the starting point for testers and contributors.