talk: el chat P2P de 1983 que una VPN ha resucitado

Antes de internet, las personas ya podían chatear. Es un tema que siempre me ha llamado la atención: ¿cómo era posible? De pequeño ya había oído hablar de un comando llamado talk, y lo más impresionante es que a día de hoy lo puedes seguir usando, sin registros y desde la terminal, incluso en entornos laborales donde trabajo sobre una VPN. No está muerto: es que poca gente conoce su potencial.

Este artículo es para saciar mi curiosidad al respecto, y si alguien aprende algo por el camino: mejor que mejor. Si viviste la época de talk y detectas alguna incoherencia, por favor escríbeme en privado para que pueda arreglarlo, ya que encontrar información ha sido complejo.

¿Cómo se chateaba en la época?

La forma en que se chateaba en los 80 no se parece a la experiencia que tenemos hoy.

Dos personas compartían la misma pantalla y podían verse escribir. No sé si eres consciente de lo que eso significa: en tiempo real, letra a letra, cada uno veía cómo el otro escribía, borraba y dudaba. No era un chat de enviar y esperar, sino una pantalla viva partida en dos.

Aquí puedes ver cómo se simula la conversación con dos contenedores de Docker.

Todo empezaba averiguando si la otra persona estaba disponible. Para ello contabas con el comando finger, que te decía si el usuario estaba conectado y qué estaba haciendo. Si te interesa, tengo otro artículo sobre qué era finger y cómo funcionaba.

Entonces, si estaba disponible, ejecutabas el comando talk en la terminal, seguido del usuario y el host con el que querías hablar.

Por ejemplo:

talk ana@library

A ana le aparecería un mensaje en su terminal avisándole de que alguien quería hablar con ella. Si aceptaba, la pantalla se dividía en dos y empezaba la conversación.

Estabas limitado a hablar con una sola persona a la vez, y necesitabas una cuenta en el mismo sistema que la otra persona, o en sistemas que se vieran entre sí: lo que hoy llamarías hablar en LAN, una comunicación P2P sin servidores centrales.

Tampoco había historial de la conversación, ni forma de enviar archivos, ni autenticación ni cifrado (cualquiera que viese el tráfico podía leerlo). Era un chat muy básico, pero funcional.

Lo más curioso es que todavía hoy puedes seguir haciendo esto, y funciona. El cliente talk viene de fábrica en macOS y en la mayoría de sistemas Unix. En Debian o Ubuntu lo instalas con apt install talk talkd. Su demonio, ntalkd, también está ahí.

Origen

Todo empezó con dos personas que querían hablarse a través de una máquina que compartían.

En 1965 el CTSS del MIT tenía un comando WRITE para mandar una línea a otro usuario conectado, y sistemas como Multics, PLATO o NLS ofrecían mecanismos parecidos.

En los años 70, Unix lo heredó y lo pulió. Copiabas líneas de texto directamente en la terminal de otro usuario. Y para decidir si querías que te interrumpieran o no, estaba mesg (de message), del 3 de noviembre de 1971, atribuido a Dennis Ritchie y Ken Thompson. Un mesg n y cerrabas la puerta; un mesg y y la abrías. También existía wall (write all), que gritaba un mensaje a todas las terminales a la vez. Todo bastante precario a nuestros ojos, pero moldeado a su época.

El salto llegó en 1983 con 4.2BSD. Ahí apareció talk tal como lo he descrito: pantalla partida, escritura simultánea y, lo más importante, capaz de conectar a dos personas en máquinas distintas a través de la red. Ya no se trataba de hablar con quien compartía tu ordenador, sino con cualquiera en una máquina conectada. El mérito se atribuye a Kipp Hickman, Clem Cole y Peter Moore.

El protocolo

Que dos desconocidos en máquinas diferentes acaben con la pantalla enlazada tiene su ingeniería. No hay servidor central donde ambos se registren, lo cual obliga a orquestar un baile de peticiones. Necesitas un intermediario en cada una: el demonio talkd (o ntalkd).

Piensa en talkd como el recepcionista de tu máquina, con dos tareas: guarda las invitaciones que dejas y avisa a tus usuarios cuando alguien de fuera quiere hablar con ellos:

• La negociación (encontrarse y llamar al timbre) va por UDP.
• La conversación en sí, el chorro de letras, va por una conexión TCP directa entre los dos clientes.

Para negociar, los clientes y los demonios se mandan mensajes de control:

• LEAVE_INVITE (dejo una invitación)
• LOOK_UP (busco una invitación)
• DELETE (la borro)
• ANNOUNCE (avisa a esa persona). Con esas cuatro piezas se arma todo.

La conversación entre Bob y Ana se ve así:

sequenceDiagram
    participant A as talk de Ana
    participant DA as talkd de Ana (UDP)
    participant DB as talkd de Bob (UDP)
    participant B as talk de Bob
    A->>DB: LOOK_UP (¿Bob ya me ha invitado?)
    DB->>A: NOT_HERE (todavía no)
    A->>DA: LEAVE_INVITE (escucho en este puerto TCP)
    A->>DB: ANNOUNCE (avisa a Bob)
    DB->>B: "talk: conexión pedida por ana@host. Responde con: talk ana@host"
    B->>DA: LOOK_UP (¿dónde escucha Ana?)
    DA->>B: dirección TCP de Ana
    B->>A: conexión TCP directa
    Note over A,B: A partir de aquí, texto en vivo por TCP

Paso a paso:

1. El talk de Ana pregunta primero (LOOK_UP) al talkd de Bob si Bob ya la había invitado, por si ambos se llaman a la vez. Como no hay nada (NOT_HERE), continúa.
2. El talk de Ana deja una invitación en su propio talkd, apuntando el puerto TCP donde va a escuchar.
3. El talk de Ana manda un ANNOUNCE al talkd de Bob. Ese demonio escribe en la terminal de Bob el famoso aviso: "talk: connection requested by ana@host".
4. Bob teclea talk ana@host. Su cliente pregunta (LOOK_UP) al talkd de Ana dónde está escuchando.
5. El talkd de Ana devuelve su dirección TCP. Bob se conecta directamente a Ana, y empieza la conversación.

Todo el intercambio de puertos viaja dentro de esos mensajes de control. La dirección donde escucha cada cliente se mete en un campo del mensaje (addr) y se pasa de mano en mano.

Pocas soluciones más elegantes se han visto en la historia de la informática.

ntalk para unirlos a todos

El mensaje de control llevaba la dirección de red metida en una estructura de C que se enviaba tal cual estaba en memoria. Y resulta que no todas las máquinas guardan los bytes en el mismo orden, lo que se llama endianness.

Un endianness es la forma en que un ordenador almacena los bytes de un número. Un little-endian guarda el byte menos significativo primero, y un big-endian lo hace al revés. Por ejemplo, el número 0x12345678 se guarda así:

• Little-endian: 78 56 34 12
• Big-endian: 12 34 56 78

Esto impedía hablar entre máquinas de fabricantes distintos. Un talk entre dos máquinas del mismo tipo funcionaba sin problemas. Pero entre una little-endian y una big-endian, cada una leía la dirección de la otra como ¡un montón de bytes sin sentido! talk dependía del orden de los bytes.

En definitiva, solo hablabas con gente que tuviera tu misma arquitectura. ¡Y tú querías hablar con todo el mundo!

La solución fue ntalk, la versión nueva del protocolo. Añadió un campo de versión y ordenó bien los bytes para que dos arquitecturas cualesquiera se entendieran. Para no romper lo viejo, cada versión se quedó en su puerto:

• El talk original (a veces llamado otalk): puerto UDP 517.
• El nuevo ntalk: puerto UDP 518.

Ello provocó otros problemas, como clientes hablando 518 contra un demonio que solo entendía 517, o al revés. Eran típicos los cuelgues eternos con checking for invitation on caller's machine, o el your party is using an incompatible version of the talk program.

Salieron variantes para tapar agujeros. ytalk, de Britt Yenne, fue el primero en permitir más de dos personas a la vez (grupos) y en hablar entre arquitecturas distintas. utalk se saltó el TCP y mandaba hasta la conversación por UDP.

Cada uno resolvía una carencia del original, dando un paso hacia adelante.

Entonces, cuando te hablen de talk, posiblemente se refieran a ntalk, que es lo que la mayoría de sistemas Unix modernos traen.

Por cierto, ni siquiera hay un RFC de talk. Es folclore de Unix, no una especificación bendecida.

Por qué no sobrevivió al internet moderno

talk fue diseñado para un internet que ya no existe: uno donde cada máquina tenía una dirección IP pública, un nombre, y confiaba en las demás. En cuanto ese mundo cambió, el protocolo se quedó sin suelo bajo los pies.

Los problemas, uno a uno:

• Solo de dos en dos. El talk de base conecta exactamente a dos personas. Ni grupos, ni salas.
• NAT lo mata. El protocolo entrega al otro una IP y un puerto concretos y espera que te conectes directamente a esa dirección. Detrás de un router doméstico, esa dirección no lleva a ninguna parte.
• El cortafuegos lo bloquea. Necesita UDP 517/518 entrante y, encima, conexiones TCP entrantes a puertos altos en los dos extremos. Cualquier firewall razonable lo corta.
• Cero seguridad. Texto plano, sin cifrado y sin autenticación. Tu identidad era, literalmente, el nombre de usuario que ibas escribiendo en el paquete.
• No hay historial. Si te desconectas, la conversación se pierde. No hay registro de lo que se dijo.
• No hay apodos. Solo cuentas Unix. Si no tienes una cuenta en la máquina de tu amigo, no puedes hablar con él.
• No hay servidores. No hay un punto central donde registrarse, ni donde dejar mensajes si no estás conectado. Si tu amigo no está en su máquina, no hay forma de avisarle.

Y olvídate de enviar archivos, videollamadas o emojis.

Por otro lado, en 1988 Jarkko Oikarinen creó IRC, que resolvía muchos de estos problemas: sin depender de una máquina concreta y sin los quebraderos de compatibilidad. Rápidamente relegó a talk a un rincón de la historia.

VPN, una nueva esperanza

El protocolo funciona perfectamente, lo que lo rompe es la red que lo rodea: NAT, cortafuegos, falta de direcciones alcanzables... problemas de quién puede alcanzar a quién.

¿Y qué hace exactamente una VPN de malla moderna? WireGuard, Tailscale o ZeroTier te montan una red privada donde cada máquina vuelve a tener una dirección estable y alcanzable por todas las demás, con un extra que nunca tuvo: ¡el túnel va cifrado!

Sobre esa red superpuesta, ntalkd en el UDP 518 y la conexión TCP de vuelta funcionan otra vez exactamente como en 1983. La IP que el demonio le pasa al otro ahora sí es routable. El NAT y el cortafuegos quedan por debajo del túnel. talk no se entera de que han pasado cuarenta años.

Ahora solo falta encontrar a un amigo lo suficientemente curioso o geek. Enciende una VPN, arranca ntalkd y hazle un talk. Vas a redescubrir lo raro y bonito que es ver a alguien escribir en directo desde la terminal.

NeoTalk

Otro enfoque: ¿y si adaptamos la idea a un entorno moderno, con un lenguaje como Python? Hice un prototipo rápido para ver si era posible, y lo es. Puedes verlo en este repositorio.

Mantiene los puntos críticos: la negociación va por UDP y la conversación por una conexión TCP directa entre los dos clientes, igual que en 1983. Pero le quita las espinas:

• Interfaz gráfica con la lista de quién está conectado y la conversación en burbujas.
• Cifrado de extremo a extremo (X25519 + AES-GCM). La privacidad ya no depende de la red, aunque encaja de maravilla con una VPN.
• Alias en vez de cuentas Unix. Te pones el nombre que quieras; no necesitas cuenta en la máquina del otro.
• Escritura por mensajes. Con un indicador de "está escribiendo…", pero sin exponer cada tecla como hacía el original.
• Descubrimiento automático en la red local y por VPN (WireGuard, Tailscale…), anunciándose por unicast o marcando la dirección directamente.

Al final solo es un chat P2P sobre IP muy básico. No pretende competir con nada, pero es una prueba de concepto para comprobar que la idea de talk sigue siendo buenísima después de casi medio siglo.

Apuntes finales

Espero que hayas disfrutado este viaje por la historia de talk. Sigue siendo increíble que continúe instalado por defecto en muchos sistemas y siga siendo funcional en ciertos entornos.

Es otro ejemplo de cómo la tecnología puede ser increíblemente ingeniosa y, al mismo tiempo, frágil frente a los cambios del entorno. Pero no por ello está muerto: tenemos herramientas para seguir haciéndolo funcionar si te interesa.

Fuentes

Cada dato de este artículo procede de estas referencias:

• talk (software) en Wikipedia. Historia, la llegada en 4.2BSD, ntalk, ytalk y utalk.
• Página de manual de talk(1) (FreeBSD) y la de talkd(8). El comportamiento de la pantalla partida y el demonio.
• Manual de referencia de BSD (title.urm), que atribuye talk(1) a Clem Cole, Kipp Hickman y Peter Moore.
• protocols/talkd.h, la cabecera de BSD con las estructuras CTL_MSG y CTL_RESPONSE, los tipos de mensaje y los códigos de respuesta.
• The talk protocol, notas de Henning Schulzrinne sobre el rendezvous, los mensajes de control y la dependencia del orden de bytes.
• Building Internet Firewalls (O'Reilly). La separación UDP para negociar, TCP para conversar, y los puertos 517 y 518.
• mesg y wall en Wikipedia, para la familia previa de comandos.
• The IBM 7094 and CTSS, de Tom Van Vleck, sobre el comando WRITE de CTSS en 1965.
• Jarkko Oikarinen en Wikipedia y su propio relato sobre el nacimiento de IRC en 1988.
• draft-hunter-talk-00, el borrador (caducado) de la IETF que documenta el protocolo talk.
• Tailscale y su comparativa con ZeroTier, para el modelo de red superpuesta y direccionable que revive talk.