En esta página
Telegram en un Amiga me interesa como programa, no como ejercicio para conseguir una captura: abrir una conversación, responder, mover un archivo y dejar el cliente funcionando mientras se hace otra cosa. Este diario reconstruye el desarrollo de Telegram Amiga, cliente MTProto nativo escrito en C, desde el experimento diagnóstico hasta la Alpha 0.0.98.
Última actualización, 29 de octubre de 2026: diario reescrito íntegramente a partir de la documentación pública del proyecto y de la Alpha 0.0.98, publicada el 28 de octubre. Sigue siendo experimental, pero ya no es el primer prototipo de texto. Hay siete paquetes actuales; el desarrollo posterior se distingue de lo que contienen esos archivos.
Capítulo 1: los límites como banco de trabajo
La pregunta inicial era si una máquina de la familia Amiga podía participar en una conversación real de Telegram sin delegarlo todo en un servicio intermedio. No hacía falta reproducir cada función de Telegram Desktop. Hacían falta fundamentos verificables: red, acceso, estado, texto y un ciclo de interacción que no traicionara a quien acababa de pulsar una tecla.
El límite no es un adorno nostálgico. Con un procesador lento, pocos megabytes de memoria y una pantalla con paleta, una decisión ineficiente se vuelve visible de inmediato. Trabajar ahí obliga a preguntar quién posee un búfer, cuánto tarda un redibujado y qué actividad puede esperar. Son preguntas válidas incluso cuando el hardware moderno permite ignorarlas.
Capítulo 2: primero la sonda, después el cliente
La primera herramienta fue un cliente diagnóstico para la Bot API. HTTP, TLS, JSON y polling permitían comprobar si las pilas de red y las herramientas de compilación eran utilizables. Antes de abordar el protocolo completo había que saber si la máquina podía conectarse, leer una respuesta y conservar el progreso sin perder su estado.
Un bot no es una cuenta personal de Telegram. Ese modo cumplió su tarea como sonda y sigue en el repositorio para diagnóstico; no representa la dirección final del producto. Mantener clara la diferencia evita convertir una fase preparatoria en una promesa equivocada.
Capítulo 3: convertirse en un cliente MTProto
El paso a MTProto cambia la naturaleza del proyecto. El cliente debe crear su clave de autenticación, serializar objetos TL y gestionar nonces, RSA, Diffie-Hellman, AES, salts, secuencias y sesiones. Después llegan el número de teléfono, el código de acceso y la contraseña de verificación en dos pasos cuando se requiere.
La versión actual incorpora su criptografía y no necesita MUI, ixemul ni AmiSSL para el funcionamiento normal del cliente. Las respuestas comprimidas gzip_packed también tienen una ruta interna mediante puff. Eso no resta valor al diagnóstico TLS inicial: significa que el cliente real construyó una base distinta. Guardar la sesión permite después reabrir el programa sin repetir el acceso cada vez.
Capítulo 4: leer, elegir, responder
Las primeras alphas públicas de junio y principios de julio convirtieron el protocolo en interacción: lista de chats, historial, envío y recepción de texto, respuestas, edición, borrado, confirmaciones de lectura y avatares. La GUI usa Intuition y GadTools, con dibujo controlado por el programa; el cliente de texto comparte el motor sin fingir que es una ventana gráfica dentro de una consola.
No bastaba con conseguir que llegara un mensaje. Había que hacer comprensible lo que sucedía después: identificar al remitente, conservar un borrador, seguir una actualización remota y evitar que la lista volviera a llenarse de chats no deseados en cada inicio. Construir el cliente comenzó ahí, no solo con el éxito del primer intercambio de claves.
Capítulo 5: los archivos entran en la conversación
Con la 0.0.6, el 14 de julio, los documentos se convierten en objetos del cliente: nombre, tamaño, descarga y envío de archivos locales. La primera implementación tenía un límite de 10 MB, que pertenece a esa etapa histórica y no al cliente actual. Serialización, transferencias por partes y búferes debían seguir siendo compatibles entre arquitecturas.
Mensajes guardados hace especialmente tangible el resultado: una carpeta de intercambio entre teléfono, PC y Amiga sin introducir otro servicio. Los límites documentados actuales son 125 MiB en 68k y 250 MiB en las demás plataformas; el contenido servido por la CDN de Telegram sigue siendo un caso aparte y no completamente cubierto.
Capítulo 6: dos interfaces, trabajo compartido
El inicio desde Workbench forma parte del programa, no es un envoltorio para resolver al final. Los iconos deben abrir la GUI o la TUI sin consolas parpadeantes ni cadenas frágiles de scripts. La distribución ha evolucionado; los paquetes actuales incluyen ambos clientes, salvo el del 68000 básico, que contiene únicamente el de texto.
Alrededor hacía falta un banco de trabajo repetible: compilación cruzada, herramientas separadas, máquinas virtuales, hardware real y traslado de binarios a los sistemas de destino. El objetivo es acortar el ciclo entre cambiar algo y observarlo, sin confundir una compilación correcta con una prueba en el sistema al que va destinada.
Capítulo 7: 0.0.7, transferir no basta
El 24 de julio la 0.0.7 incorporó transferencias grandes, progreso, reintentos y cancelación. Una conexión lenta debe poder continuar; una bloqueada necesita una salida. La GUI añadió selección y portapapeles, respuestas con doble clic y actualizaciones remotas mientras se escribe; la TUI entró también en el flujo de archivos y elementos arrastrados.
La ventana todavía permanecía ocupada durante la transferencia. Ese límite importa en el relato: admitir archivos aún no significaba dejar libre la interfaz mientras viajaban. La etapa siguiente nació de esa limitación concreta, no de un deseo genérico de optimizar.
Capítulo 8: 0.0.8, devolver el control
El 31 de julio la 0.0.8 separó las transferencias del flujo interactivo. El archivo podía avanzar sin ocupar toda la ventana y el cliente podía seguir leyendo, dibujando y aceptando entrada. Llegaron descargas desde varios centros de datos, arrastrar y soltar, búsqueda local antes de la búsqueda en línea y una lista que recordaba los chats retirados.
AfA_OS dejó claro el coste real de la compatibilidad: una llamada gráfica aparentemente inocua podía congelar un entorno concreto. Hacían falta rutas de dibujo adecuadas, redibujados parciales y atención al blitter. Una solución alternativa bien delimitada vale más que fingir que los sistemas son iguales. La revisión y las comprobaciones del empaquetado se convirtieron también en parte explícita del ciclo de publicación.
Capítulo 9: 0.0.9, una foto es una cadena de trabajo
El 7 de agosto llegaron las fotos integradas en la conversación. Descargar un JPEG es solo el principio: hacen falta vista previa inmediata, decodificación progresiva, adaptación a la pantalla, caché en disco y visor. Cada fase debe dejar espacio a la escritura, el desplazamiento y el cambio de tamaño. La misma imagen tiene costes muy distintos en AGA y en una tarjeta gráfica moderna.
Las preferencias persistentes controlan las fotos integradas, el tramado y el tamaño de la caché. Se añadieron envío de JPEG, reenvío a Mensajes guardados u otra conversación y mejoras de la TUI. Fue el paso del texto con adjuntos a conversaciones más ricas, no la promesa de reproducir cualquier medio. El límite entre vista previa y reproducción siguió siendo deliberadamente visible.
Capítulo 10: 0.0.91, pulir lo que existe
El 27 de agosto la 0.0.91 ordenó el envío de fotos con descripción, la agrupación de mensajes y la geometría de la GUI. Avatar en la cabecera, burbujas e indicadores más legibles y cursor y contadores alineados con la fuente real no cambiaban el protocolo, pero sí el esfuerzo necesario para comprender una conversación.
Eliminar trabajo innecesario también es desarrollo: las pruebas offline salieron de los paquetes distribuidos, la gestión de la caché se hizo más explícita y el inicio respetó mejor las máquinas lentas. Las pruebas de desarrollo siguen siendo importantes; no tienen por qué viajar dentro de cada binario destinado al usuario.
Capítulo 11: 0.0.92, nombrar los contenidos
El 4 de septiembre llegaron las vistas previas de enlaces y los fotogramas de vídeo, cuando Telegram proporciona los datos necesarios. Las etiquetas deben distinguir documentos, notas de voz, vídeos y stickers; una miniatura debe aprovechar la cadena existente en lugar de inventar un motor para cada contenido. Mostrar un fotograma no significa reproducir un vídeo.
La misma versión abordó textos largos, pegado y detección del bit de ejecución a partir del contenido del archivo. Los paquetes HUNK y ELF no se pueden tratar igual solo porque ambos se hayan descargado. Ese mantenimiento aparentemente menor es lo que permite utilizar realmente el archivo recibido.
Capítulo 12: 0.0.93, enviar y acceder mejor
El 12 de septiembre la 0.0.93 añadió el panel emoji, las PNG enviadas como fotos y una ruta de acceso más clara cuando Telegram no entregaba el código como se esperaba. Las comprobaciones inspeccionan los datos reales del archivo, no solo su extensión; los errores deben convertirse en explicaciones legibles.
El coste de emoji y fotos siguió dependiendo del hardware. Una preferencia sensata para una máquina rápida puede resultar pesada en un Amiga clásico. La portabilidad consiste en respetar esa diferencia con valores iniciales y opciones, no en ocultarla. Un código de acceso que no llega también es un problema de usabilidad, además de protocolo.
Capítulo 13: 0.0.94, ARM64 y persistencia
El 25 de septiembre AROS ARM64 en Raspberry Pi se convirtió en la sexta plataforma. El código compartido tenía que atravesar otra ABI, otro cargador y distintas anchuras de puntero. La documentación registra validación en Raspberry Pi 400, diferenciada de las pruebas en máquinas virtuales de otros destinos.
Los informes de campo mostraron un problema menos espectacular: la reescritura por la ruta FAT de AROS podía dejar vacíos los archivos de estado. Guardar sesión, chats y preferencias forma parte del contrato del cliente. La respuesta fue centralizar la sustitución de archivos. En el mismo ciclo llegaron los iconos optimizados por Carlo Spadoni y actualizaciones menos costosas de la barra de progreso.
Capítulo 14: 0.0.95, medir la espera
El 7 de octubre la 0.0.95 abordó transferencias y criptografía. Más solicitudes simultáneas, respuestas reordenadas y rutas conservadoras de recuperación aprovecharon mejor las máquinas y redes disponibles. Las medidas publicadas por el proyecto sitúan las descargas de Vampire entre unos 97 y 199 KB/s, y las de MorphOS real entre 1,35 y 1,6 MB/s. Son casos documentados, no velocidades garantizadas para cualquier sistema.
El primer inicio muestra la ventana antes de completar el trabajo con los centros de datos de las fotos. La verificación en dos pasos en 68k lentos se reorganizó para no entregar una prueba caducada: el cálculo largo precede a la petición de un desafío nuevo. La documentación registra un acceso en A1200 sin acelerar completado en 35 minutos. Sigue siendo una espera larga, no una invitación a desactivar la 2FA.
Capítulo 15: 0.0.96, dejar respirar al A1200
El 11 de octubre el problema central era la escritura. Redibujar toda la ventana tras cada tecla podía costar unos tres segundos por carácter en un A1200 sin acelerar. Actualizar solo el campo de escritura, aplazar el trabajo pesado hasta las pausas y conservar lo ya calculado hizo la interfaz más práctica. Un redibujado exigente medido en A1200 emulado bajó de unos seis a 0,9 segundos.
Los avatares pueden prepararse durante la inactividad o desactivarse. La ventana abre desde la lista de chats en caché; esperas de red, memoria libre y cambios de pantalla se gestionan más explícitamente. Un paquete para el 68000 básico elevó las distribuciones a siete. Las pruebas repetidas de Paolo Arus, DaRkHoRaCe, en su A600 fueron la aportación concreta que hizo posible esa vía textual.
Capítulo 16: 0.0.97, estar sin interrumpir
El 19 de octubre llegaron el contador del título, avisos emergentes, sonido opcional y AppIcon actualizado. El cliente podía seguir la red mientras estaba iconificado. Los valores iniciales evitan efectos costosos en los clásicos lentos: enterarse de un mensaje no debe convertirse en el siguiente motivo por el que el teclado responde mal.
La TUI recibió pestañas de chat en F1-F10, orden modificable y una interacción más cercana a las peticiones del usuario del 68000. Mensajes de servicio, menos memoria, fotos copiadas desde un bitmap del formato de pantalla y un acceso más comprensible completaron el trabajo. Un redibujado con foto en A1200 emulado bajó a unos 0,45 segundos tras la preparación inicial: no es una medida de velocidad de descarga.
Capítulo 17: 0.0.98, atención y conversaciones
La versión del 28 de octubre se centra en las reacciones y en el derecho de cada chat a reclamar atención. La cuadrícula React… añade o retira una reacción, respeta las permitidas por el grupo y muestra contadores bajo los mensajes. La TUI ofrece la misma función mediante /react. Las reacciones personalizadas y de pago conservan una representación simplificada.
Se respeta el silenciamiento decidido desde otro dispositivo y se usa la hora de Telegram para su vencimiento. Grupos y canales no suenan sin una elección explícita; mensajes silenciosos y mensajes propios enviados desde fuera no deben producir ruido. Un chat espera medio minuto entre avisos sonoros, mientras la conversación abierta delante del usuario permanece tranquila.
Hay sonidos globales y por chat, seis muestras originales IFF 8SVX, vista previa de la selección y un máximo de tres segundos de reproducción. AROS sigue la salida AHI configurada, mientras el aviso integrado también funciona con Paula sin AHI. El trabajo no termina en la opción visible: el audio debe seguir la ruta correcta para esa máquina.
Fechas en el historial, conversión reversible de emoticonos, caracteres de formato literales y mejores colores de avatares y emoji completan los cambios cotidianos. Cada solicitud conserva su temporal en T:, evitando interferencias entre fotos y envíos. Las notas atribuyen los fallos AROS x86_64 al controlador e1000: hay que comprobar la corrección upstream en la imagen instalada, no darla por presente en todas. La ficha de la 0.0.98 reúne funciones, requisitos y todas las descargas.
El estado actual, sin arrastrar límites antiguos
El cliente gestiona cuentas existentes, sesión guardada, chats, historial, texto, respuestas, edición, archivos, fotos, vistas previas, notificaciones y reacciones. Estas últimas ya no son una promesa, aunque una entrada del README todavía las mantiene en la antigua lista de funciones pendientes: para la 0.0.98, el changelog, las notas y la implementación del tag establecen qué se publicó.
No sustituye por completo al cliente oficial. Siguen pendientes la gestión completa de contactos, álbumes, reproducción multimedia y parte de las descargas CDN. La TUI del 68000 no es una GUI para A500; AROS x86_64 necesita un sistema compatible con su SDK; ARM64 significa imágenes nativas AROS para Raspberry Pi compatibles, no un binario para cualquier Linux ARM.
Hacia la beta, sin superar las pruebas
La hoja de ruta prepara la 0.1 como primera beta y primer lanzamiento llamado Amigram. Antes hacen falta un ciclo tranquilo, atención a las regresiones y una revisión del cliente. La numeración de dos componentes deberá coincidir con el version cookie de Amiga. AmiUpdate en OS4, credenciales API integradas con opción de sustitución y otros pasos de transición son objetivos descritos, no funciones atribuibles a la 0.0.98.
La planificación en main continúa después del tag: la petición de ocultar localmente un mensaje concreto de grupo es trabajo posterior, no una función publicada con esta alpha. Los temas y las traducciones mediante locale.library están previstos después de la beta. No hay una fecha que prometer en lugar de pruebas.
Probarlo y contribuir
El repositorio público contiene código, documentación y versiones publicadas. Es un proyecto no comercial con licencia MIT, desarrollado también con agentes LLM utilizados como herramientas de análisis, implementación y preparación de pruebas. La responsabilidad de las decisiones y resultados no pasa a la herramienta.
La contribución más útil es un informe reproducible: versión, sistema, CPU, entorno real o emulado, pila de red y comportamiento observado. No publiques sesiones, números, códigos, contraseñas ni cachés de contactos. El archivo de autenticación da acceso a la cuenta, no es un adjunto diagnóstico inocuo. Esta revisión editorial ha comprobado paquetes públicos; no ha repetido las pruebas de hardware documentadas por el proyecto.
En breve
- El recorrido va del diagnóstico Bot API a un cliente MTProto nativo con GUI y TUI sobre una base compartida.
- Archivos, fotos y conversaciones han requerido sobre todo control del trabajo, memoria y compatibilidad.
- La 0.0.98 incorpora reacciones y notificaciones por chat; hay siete paquetes en GitHub y Aminet.
- Amigram y la beta 0.1 pertenecen a la planificación, no a la versión descargable hoy.
- Un cliente útil nace del código público, las pruebas repetibles y las personas que explican qué no funciona en su Amiga.