AndroidLab From retrocomputing to AI, through Android.
Telegram Amiga 0.0.8: Transfers Without Blocking

Telegram Amiga 0.0.8: Transfers Without Blocking

by

Telegram Amiga alpha 0.0.8 was released on July 31, 2026 for AmigaOS 3.x, AmigaOS 4.x, MorphOS, AROS i386 and AROS x86_64. It is the project’s most substantial release so far: file transfer moves from a reliable but intrusive feature to a workflow that remains usable while you keep chatting.

The practical difference is easy to see: during an upload or download you can now type, switch conversations and receive messages. Under that apparently ordinary behaviour are a dedicated second MTProto file session, pipelined chunks, automatic fallback to the synchronous path, event-loop-sized work units and a long series of fixes across the GUI, multi-DC handling, packaging and AmiKit/AfA_OS systems.

The project remains a native MTProto client written in C, with an Intuition/GadTools GUI and a TUI sharing the same engine. It is not Telegram Desktop recompiled and it is not a web wrapper: it is code attempting to bring chat, search, files and session state to five Amiga-family platforms with very different ABIs, runtimes and limits.

Transfers 2.0: the GUI is no longer held hostage

The central change is the non-blocking transfer model. In 0.0.7 file sharing had already become robust, with streaming, live percentage, retries and cancellation, but the window remained busy until the operation finished. Alpha 0.0.8 separates transfer work from the GUI’s rhythm: one chunk is advanced per event-loop turn, then the client returns to input, drawing and message handling.

This is more than a cosmetic improvement. An Amiga client that continues to process events while disk and network are working is much less like a blocking demo and much more like an everyday tool. You can switch chats without stopping the transfer, follow a conversation and let the operation continue. Esc or the close gadget cancel the transfer; a second close quits the program.

A second MTProto session and pipelined chunks

Uploads and downloads now use a dedicated second MTProto session. The live chat connection is no longer shared as a pipe for both messages and files, reducing the coupling between the interactive stream and the heavier transfer path.

For downloads, the next chunk request can be sent while the current chunk is still arriving. This simple pipeline matters on slow or distant routes: the round-trip time is no longer paid in full between every chunk. If the pipeline hits trouble, the client automatically falls back to the proven synchronous path and retries the chunk instead of turning an optimisation into a new single point of failure.

The status line now shows average speed next to the percentage. Writes use larger buffers, reducing disk touches; on an Amiga with slow storage or on a 030 this is not merely theoretical. While a transfer is running, heavy live polling is throttled, while the light update drain keeps the conversation alive.

Multi-DC: files and avatars are no longer blurry forever

Telegram may store a document or profile photo on a datacenter different from the main session. Alpha 0.0.8 adds the path for downloading documents hosted on another DC, with a per-DC key, initial handshake and local cache in data/telegram-auth-dc.bin. FILE_MIGRATE is handled during a transfer as well.

The same infrastructure is used for profile photos on foreign DCs: they no longer remain blurred previews simply because the original file lives elsewhere. This is not the loudest item in the feature list, but it is exactly the sort of detail that separates a client that “can talk to Telegram” from one that handles the service’s topology.

Some files served by Telegram’s CDN remain outside the supported path, especially certain large public-channel downloads. The updated README does not hide this behind a vague promise: multi-DC support is here, CDN-served files are still a declared limitation.

More useful local search and user-curated chats

The sidebar search now filters dialogs as you type. It searches your own dialogs first, so it can find a chat removed from the list; online search remains available for discovering peers that are not already present. A private chat or group without a public username can therefore be brought back without confusing “removed from my list” with “does not exist”.

Online search can also browse the complete dialog list from an empty box. The Reload chat list menu item forces a new paginated fetch when needed: useful for older accounts, larger lists and cases where an early bootstrap left only a handful of dialogs. Later startups no longer refetch the complete list unnecessarily.

Local curation is respected: removed chats stay hidden across reloads and restarts until the user reopens them through search; archived chats are filtered from the main list. This is not full Telegram archive management yet, but it is much more predictable for users who treat the sidebar as a workspace rather than a raw dump of their account.

Drag-and-drop, download drawer and clickable URLs

The GUI accepts a file dragged from Workbench directly onto the open chat window. The filename is shown as soon as the drop arrives, so the user does not have to wait for the upload to finish to know which file was accepted. The path shares the normal transfer pump, progress reporting and cancellation.

Download destinations are no longer hard-coded. The Download drawer… item in the Telegram menu opens a standard requester and remembers the chosen drawer. The default remains downloads, but a RAM: drawer can be selected for a quick test or a system with slow storage. The preference is saved in data/telegram-downloads.txt, which can also be edited by hand.

URLs in messages are detected and drawn in blue. A click opens the link through the platform’s configured mechanism; on systems without a browser path it is copied to the clipboard instead. Short addresses are now clickable too, while underscores and backticks no longer corrupt the drawn URL or leave the rest of the bubble italicised.

AfA_OS, resize and the first-paint problem

A significant part of the release comes from a problem that modern demos rarely expose: on AmiKit with AfA_OS 4.8, Text() may freeze when drawing into a layerless off-screen RastPort. The GUI uses a double buffer to avoid flicker; that buffer is exactly where the AfA implementation behaves differently from the classic Intuition path.

When AfA is detected, Telegram Amiga now renders bitmap text through BltTemplate(), with matching font metrics for layout and caret placement. Typing updates only the input strip instead of repainting the whole window. Other systems keep the native Text() path. The targeted fix also strengthened shared infrastructure: off-screen buffers, coalesced resize, blitter-safe release, focused composer redraw and a final Intuition frame refresh.

This is a good example of work that does not produce a flashy menu item but improves the whole client. Even on non-AfA systems, resize handling moves from a fragile sequence of rebuilds and repaints to a more orderly process: intermediate events are coalesced and the buffer is rebuilt once the final size is known.

During the investigation, a separate issue outside the client was isolated: icon.library 51.4.533, bundled with some AmiKit installations, can corrupt SysBase with Directory Opus and crash the system even when Telegram is not running. It must not be confused with the AfA GUI freeze: they are different problems. One needs a library update; the other is addressed by the 0.0.8 workaround.

GUI and text: small bugs with large consequences

The release fixes a number of cases that matter once the client stops being an occasional experiment. The right-click popup is sized from the actual labels and platform font; right-clicking outside the window no longer traps the menu bar; double-clicking a search result no longer opens a second, wrong chat after the first click has already replaced the sidebar.

Pasting a text file preserves CR and CR/LF instead of flattening everything into one paragraph, while long text containing accented characters is no longer truncated or corrupted by an undersized UTF-8 buffer. These bugs do not fit promotional screenshots, but an Italian user notices them immediately when pasting documentation.

The percentage calculation is also fixed for files above roughly 41 MiB: a 32-bit overflow could reset the displayed value to zero midway through a transfer even though the file itself was fine. A wrong number does not make the transfer less real, but it makes the interface unreliable exactly when the user needs to know how much remains.

MTProto robustness and packaging

If the system clock moves backwards just after connecting, a query budget no longer expires immediately: the budget is re-originated. A stale RPC result left on the stream after an aborted query becomes a clean soft-fail with reconnect, avoiding ambiguous state on slow bsdsocket stacks.

On AmigaOS 4, message ports and I/O requests now use the native AllocSysObject/FreeSysObject family. Packaging checks the architecture of the binary inside every archive, preventing a repeat of the 0.0.7 Aminet issue where an OS3 archive received the OS4 binary because of a case-insensitive filename collision; that package was republished as 0.0.7a, while the GitHub archives were unaffected.

The release also documents the experimental M68K_CPU=68000 option for plain 68000 builds. It is not included in the public binary packages, which remain 68020+. Every archive includes the CHANGELOG and the version check prevents distributing a file that declares a different architecture from the one it contains.

Official downloads: GitHub and Aminet

GitHub archives contain both clients, icons, IT/EN manuals, the public API file and the CHANGELOG. They do not contain Telegram sessions, personal tokens or other private files. Aminet provides the 0.0.8 packages through the five corresponding official pages.

The official GitHub repository remains the source for code, issues, documentation and current status. The full journey is collected in the Telegram Amiga development diary; the Italian version is available in the Italian diary.

What actually changes

Alpha 0.0.8 does not merely add items to a feature list. It changes the relationship between the client and the machine: a transfer no longer takes over the GUI, the file session no longer pollutes the chat session, downloads understand foreign datacenters and search respects the user’s local curation. These are architectural choices that make the program more usable even when hardware cannot offer much RAM, CPU or I/O bandwidth.

The project is still alpha and does not support inline photo rendering, reactions, full contact management or forwarding to another chat. Telegram CDN files remain a limitation. But the boundary is more interesting now: Telegram Amiga is no longer only proving that an Amiga can connect to Telegram; it is building, one difficult function at a time, a client that can stay inside the operational flow without asking the user to stop everything.

In short

  • Non-blocking transfers: keep chatting, switch conversations and receive messages during uploads and downloads.
  • A second MTProto file session, pipelined chunks, synchronous fallback, average speed, cancellation and larger write buffers.
  • Documents and avatars from foreign datacenters, with per-DC keys, handshake and FILE_MIGRATE handling.
  • Live local filtering, own-dialog search before peer search, paginated reload and persistent hidden chats.
  • Workbench drag-and-drop, configurable download drawer, clickable URLs and screen-colour-aware menus.
  • AfA_OS first-paint workaround, coalesced resize, UTF-8/paste fixes, popup fixes, percentage correction and MTProto reconnect hardening.
  • Official 0.0.8 packages for AmigaOS 3.x, AmigaOS 4.x, MorphOS, AROS i386 and AROS x86_64 on GitHub and Aminet.

Sources and materials

AUTHOR

IT specialist, developer and systems engineer with a long history across code, Linux servers, retrocomputers and e-learning platforms. On AndroidLab he brings a technical, pragmatic eye: less brochure smoke, more attention to infrastructure, usability, privacy, updates and the real consequences of manufacturers' choices.

Leave a Comment