Development diary: this article is part of the RetroLab saga on Telegram Amiga. The whole story is collected in the Telegram Amiga development diary, kept in sync with the real status of the MTProto client and linked to the GitHub repository.
The first article on Telegram Amiga described a cautious choice: start from the Bot API, build a diagnostic client, verify network, TLS, JSON, polling, offsets and controlled message sending. It was the sensible way to figure out whether an Amiga-like machine could still talk to a modern service without turning every HTTPS request into a seance with the TCP/IP stack.
That phase doesn’t disappear, but it changes role. In the telegram-amiga repository the main direction is now MTProto: not just a bot helper or an HTTP call tester anymore, but a pre-alpha prototype of a text client able to use a real Telegram account, save a session, list dialogs, read history and send messages to selected peers. Put less politely: we’ve moved from “Telegram answers from far away” to “this machine is trying to behave like a client”.
The shift is substantial because MTProto is not a convenient API you consume with an HTTPS request and a JSON response. Here you get into cryptographic bootstrap, TL serialization, TCP transport, RSA, Diffie–Hellman, AES-IGE, handling of auth_key, server_salt, seq_no, message IDs and local files that must never end up in screenshots, packages or repositories. On a modern system that’s already a field full of traps. On AmigaOS 3.x, MorphOS, AmigaOS 4.x and AROS it turns into a real technical lab, with the sober charm of things that can break in twelve different ways before they even print a useful line.
From Bot API to MTProto
The Bot API stays in the project for a concrete reason: it is still useful for diagnostics, HTTPS preflight, getMe, getUpdates, controlled sending and state tests. But the updated README is very blunt: the main line is MTProto, aiming at a lightweight text Telegram client for Amiga-like systems.
The difference is not just in the label. With the Bot API you talk as a bot, with a token and HTTP calls. With MTProto you enter the protocol used by Telegram clients: login with phone number and code, optional 2FA, session saved in telegram-auth.bin, local peer cache in telegram-peers.txt, commands to query dialogs and history, and an interactive chat mode that prints me: lines and peer lines instead of dumping the whole protocol diagnostics on the user.
In the non-destructive local tests run before publication, the fast MTProto test suite passes: DC mapping, message IDs, auth, TL, envelope, encrypted framing, transport, login scaffolding, probes, crypto and session state all report ok. The older self-tests for the Bot API / text part are still green as well. This matters because the move to MTProto must not burn the previous bridge: if the Bot API diagnostics regresses, the lab loses one of its measuring instruments.
The core: auth key, RSA_PAD, AES-IGE and DH
The interesting part is not “we’ve added login”. The interesting part is how you get there. The MTProto code today covers the construction of req_pq_multi, parsing of resPQ with nonce validation, factoring of pq, selection of the RSA fingerprint from a known list, Telegram’s production RSA public material, serialization of p_q_inner_data_dc and req_DH_params, RSA_PAD with AES-256-IGE, parsing of server_DH_params_ok, decryption of server_DH_inner_data, validation of prime / g and completion with set_client_DH_params.
From there you derive auth_key_id and server_salt, then move on to framing encrypted messages with MTProto 2.0. The project also includes supervised probes that reach an encrypted ping/pong after temporary key creation. It’s not “everyday use” yet, but it’s the piece that separates a real client from a cosmetic shortcut. If you don’t control this phase, you’re just painting a Telegram window over a black hole.
The repository also shows a cautious choice: authorization files are saved only when the platform can provide secure randomness, and the inspection commands do not print keys, session IDs or account identities. In local checks, telegram-auth.bin validates correctly, with an auth key present, coherent key ID, server salt present, session present and sequence state saved. These details are not photogenic, but they are exactly what keeps the project from turning into a fragile demo.
Dialogs, peer cache and interactive chat
The second turn is functional. MTProto account mode today includes an interactive login wizard, 2FA password support when Telegram asks for it, protection against mismatched saved data centers, read-only smoke tests, dialog listing, peer extraction and caching, reading of text history and sending text to a selected user peer.
The telegram-peers.txt cache is not bureaucratic noise: it’s how a text environment, maybe on an Amiga console, avoids asking the user every time to remember IDs and access hashes. Dialogs are read with messages.getDialogs, history with dedicated commands, and sending goes through messages.sendMessage. The mtproto-chat mode adds the minimum ergonomic layer: peer selection, immediate reading, auto-read while waiting for keyboard input, commands like /read, /watch, /peer, /peers and /quit.
There is even a small portability lesson hidden in gzip_packed responses: where zlib is not available, the project can fall back to the embedded puff implementation. It’s not glamorous, but on historical and Amiga-like targets these compromises are exactly what makes the difference between “it compiles on my Mac” and “it can actually be tried on several systems”.
AmigaOS 3, MorphOS, AmigaOS 4 and AROS
The most important editorial point for RetroLab is that this effort doesn’t stay trapped in a local binary. The README lists public pre-alpha packages for AmigaOS 3.x, MorphOS, AmigaOS 4.x, AROS i386 ABIv0 TLS and AROS x86_64 offline. Packages include platform READMEs, USER_RUNBOOK.md, MTProto notes and helper scripts; they do not include tokens, API credentials, auth files, phone codes, passwords or peer caches.
This point needs to be clear: it doesn’t mean Telegram Amiga is already a replacement for Telegram Desktop, and the project says so explicitly. It still lacks a complete update loop, robust session handling for daily use, mature support for groups/channels, edit/delete/reactions, media, contacts and a polished UI. But the realistic target is finally higher than “a tester that calls an API”: a reliable text client, first for messages, then eventually for whatever the platforms will allow without turning everything into punitive archaeology.
What really changes
The MTProto shift changes the nature of the project. The Bot API proved that Amiga-like systems could traverse TLS, speak HTTP and handle a Telegram stream mediated by a bot. MTProto instead forces you to solve the client problem: user identity, cryptographic bootstrap, persistent state, consistent data center, dialogs, peers, history and message sending. That’s an architectural difference, not just another menu item.
For AndroidLab RetroLab this is the point: living retrocomputing is not about running modern software “because it looks cool”. It’s about taking real limits, real toolchains, real TCP/IP, real TLS, real crypto and building a verifiable path. If Telegram Amiga manages to become a usable text client, it won’t be because of nostalgia. It will be because every piece of the protocol has been made small enough, portable enough and observable enough to survive outside the comfort zone of modern platforms.
TL;DR
- Telegram Amiga is no longer centered only on the Bot API: the main direction is a pre-alpha MTProto text client.
- MTProto bootstrap includes RSA_PAD, AES-IGE, Diffie–Hellman, auth key, server salt and MTProto 2.0 encrypted framing.
- Account mode supports a login wizard, 2FA, saved session, dialogs, peer cache, history,
sendMessageand interactive chat. - Packages cover AmigaOS 3.x, MorphOS, AmigaOS 4.x, AROS i386 ABIv0 TLS and AROS x86_64 offline.
- It is still a pre-alpha: the value lies in the verifiable technical direction, not in a promise of a full Telegram replacement ready for tomorrow morning.