Cómo construimos OWL, la nueva arquitectura de nuestro navegador basado en ChatGPT, Atlas

Por Ken Rockot, miembro del Personal Técnico y Ben Goodger, jefe de Ingeniería, ChatGPT Atlas

La semana pasada, presentamos ChatGPT Atlas⁠, una nueva manera de navegar la web con ChatGPT a tu lado. Además de ser un completísimo navegador web, Atlas te permite echar una mirada al futuro: un mundo en el que puedes recorrer Internet de la mano de ChatGPT, para hacer preguntas, pedir sugerencias y delegarle tareas. En este artículo, abordamos uno de los aspectos de ingeniería más complejos del producto: cómo convertimos ChatGPT en un navegador que se vuelve más útil cuanto más lo usas.

Hacer de ChatGPT un verdadero copiloto para la web implicó rediseñar toda la arquitectura de un navegador y separar a Atlas del tiempo de ejecución de Chromium. Debimos idear una nueva forma de integrar Chromium, con la que pudiéramos cumplir nuestros objetivos del producto: arranque instantáneo, capacidad de respuesta incluso con más de una ventana y una base sólida destinada al uso de agentes.

El elemento natural de construcción es Chromium. Se trata de un motor web de última generación con un modelo de seguridad confiable, sólidos antecedentes de rendimiento y una compatibilidad web inigualable. Además, lo desarrolla una comunidad global que no deja de mejorarlo. Para los navegadores web de escritorio de hoy, es la opción más habitual.

Nuestro talentoso equipo de diseño se propuso objetivos muy ambiciosos, como incluir animaciones y efectos visuales sofisticados en características como el modo Agente. Para no limitarse a cambiarle la apariencia a la experiencia de usuario de código abierto de Chromium, nuestro equipo de ingenieros recurrió a los marcos nativos más modernos de nuestra interfaz de usuario (SwiftUI, AppKit y Metal). Como resultado, la interfaz de usuario de Atlas reestructura totalmente la experiencia de usuario de la aplicación.

También teníamos en mente otros objetivos relacionados con el producto, como la rapidez en el arranque y la capacidad de manejar cientos de pestañas sin afectar el rendimiento. Con Chromium tal y como viene de fábrica, no era fácil alcanzarlos, ya que muchos detalles, como la secuencia de arranque, el modelo de subprocesos y los modelos de pestañas, no se pueden modificar. Nos planteamos la posibilidad de realizar cambios sustanciales; sin embargo, decidimos mantener nuestro conjunto de parches para Chromium, lo que nos permitirá integrar rápidamente cada nueva versión. Necesitábamos encontrar una solución alternativa para integrar y administrar el tiempo de ejecución de Chromium. Era fundamental para agilizar la velocidad de desarrollo al máximo.

La prueba de fuego para nuestro esfuerzo técnico iba más allá de poder experimentar, iterar y entregar nuevas características más rápido, sino que también consistía en poder preservar un aspecto fundamental de la cultura de ingeniería de OpenAI: el lanzamiento desde el primer día. El primer día, cada nuevo ingeniero realiza y fusiona su primer cambio de código antes de terminar la tarde. Y si bien la verificación y compilación de Chromium puede tardar horas, debíamos asegurarnos de que esto fuera factible.

Nuestra respuesta ante todos estos retos fue construir una nueva capa arquitectónica a la que le dimos el nombre de OWL, que significa OpenAI’s Web Layer (Capa web de OpenAI). OWL es nada más ni nada menos que nuestra integración de Chromium, que consiste en ejecutar el proceso del navegador Chromium de forma externa al proceso principal de la aplicación Atlas.

Míralo de esta forma: Chromium provocó toda una revolución en el ámbito de los navegadores al mover las pestañas a procesos separados. Lo que estamos haciendo es profundizar en esa idea, extrayendo a Chromium del proceso principal de la aplicación y colocándolo en una capa de servicios aislada. Este cambio implica toda una serie de ventajas:

• Una aplicación más simple y moderna: Atlas se basa casi enteramente en SwiftUI y AppKit. Un solo lenguaje, una sola pila tecnológica, un solo código base limpio.
• Arranque más rápido: Chromium se inicia en segundo plano de forma asíncrona. Atlas no espera: los píxeles entran en escena casi al instante.
• Protección contra fallas y bloqueos: Chromium es un motor web potente y complejo. Si su hilo principal se cuelga, el de Atlas no lo hace. Si se bloquea, Atlas sigue funcionando.
• Menos problemas con las fusiones: como no nos basamos tanto en la interfaz de usuario de código abierto de Chromium, nuestras diferencias con respecto al original son mucho menores y más fáciles de mantener.
• Iteración más rápida: en general, los ingenieros no necesitan compilar Chromium localmente. OWL funciona internamente como un binario precompilado, así que las compilaciones de Atlas tardan minutos en lugar de horas.

De hecho, como la mayoría de los ingenieros de nuestro equipo no suele compilar Chromium desde el código fuente, el desarrollo puede ser mucho más rápido; incluso los nuevos miembros pueden fusionar cambios sencillos en su primera tarde.

En términos generales, el navegador Atlas es el cliente OWL, y el proceso del navegador Chromium es el host OWL. Ambos se comunican a través de IPC, Mojo⁠(se abre en una nueva ventana), más concretamente, el sistema de transmisión de mensajes propio de Chromium. Nosotros escribimos enlaces personalizados de Swift (e incluso TypeScript) para Mojo, así que nuestra aplicación Swift puede llamar directamente a las interfaces del lado del host.

La biblioteca cliente OWL ofrece una API pública de Swift sencilla, que abstrae varios conceptos clave expuestos por la capa de servicio del host.

• Sesión: configura y controla el host a nivel global.
• Perfil: administra el estado del navegador para un perfil de usuario específico.
• WebView: controla e incrusta contenidos web individuales (como renderización, eventos de entrada, navegación, zoom, etc.).
• WebContentRenderer: reenvía los eventos de entrada al proceso de renderizado de Chromium y recibe información del renderizador.
• LayerHost/Client: intercambia información de composición gráfica entre la interfaz de usuario y Chromium.

Además, hay toda una gama de puntos finales de servicio pensada para administrar características de alto nivel, como marcadores, descargas, extensiones y autocompletar.

Los WebViews, que comparten un espacio de presentación exclusivo en la aplicación cliente, se intercambian dentro y fuera de un contenedor de composición compartido. Por ejemplo, una ventana del navegador suele tener un único contenedor compartido visible y, cuando se selecciona una pestaña en la barra de pestañas, el WebView de esa pestaña se intercambia en el contenedor. En Chromium, este contenedor corresponde a un gfx::AcceleratedWidget que, a su vez, está respaldado por un CALayer. Nosotros exponemos al cliente el ID de contexto de esa capa y un NSView lo integra usando la API privada CALayerHost.

Los casos especiales, como los menús desplegables o los selectores de color que Chromium presenta en widgets emergentes independientes, utilizan el mismo enfoque. No tienen un content::WebContents, pero sí cuentan con un content::RenderWidgetHostView con su propio gfx::AcceleratedWidget, por lo que se aplica el mismo modelo de renderización delegada.Internamente, OWL mantiene la geometría de la vista sincronizada con Chromium, para que el compositor de la GPU pueda actualizarse adecuadamente y producir siempre capas con el tamaño y la escala correctos para el dispositivo.También reutilizamos esta técnica para proyectar en Atlas de forma selectiva elementos de la interfaz de usuario nativa de Chromium (Views UI), lo que además permite iniciar rápidamente características como las solicitudes de permiso sin tener que crear sustitutos desde cero en SwiftUI. Esta técnica se basa en gran medida en la infraestructura existente de Chromium para aplicaciones web que se pueden instalar en macOS.Eventos de entrada: interpretación y reenvíoLa interfaz de usuario de Chromium traduce los eventos de la plataforma (como los NSEvents de macOS) al modelo WebInputEvent de Blink para luego reenviarlos a los renderizadores. Pero como OWL ejecuta Chromium mediante un proceso oculto, nosotros nos encargamos de hacer la traducción correspondiente dentro de la biblioteca cliente Swift y reenviamos los eventos ya traducidos a Chromium.A partir de ese momento, siguen el mismo ciclo de vida que los eventos de entrada reales para el contenido web. Esto significa que cada vez que una página no maneja un evento, este se regresa al cliente. Cuando esto ocurre, volvemos a sintetizar un NSEvent y le damos al resto de la aplicación la oportunidad de controlar la entrada.Modo Agente: casos especialesLa característica de navegación autónoma de Atlas implica una serie de desafíos únicos para nuestro enfoque de la renderización, el reenvío de eventos de entrada y el almacenamiento de datos.Nuestro modelo de uso de computadoras espera una única imagen de la pantalla como entrada. Sin embargo, algunos elementos de la interfaz de usuario, como los menús desplegables , se representan en ventanas separadas, fuera de los límites de la pestaña. En el modo Agente, volvemos a componer esas ventanas emergentes en la imagen de la página principal siguiendo las coordenadas correctas, de modo que el modelo vea el contexto completo en un solo fotograma.

Y en el caso de la entrada, aplicamos el mismo principio: los eventos que genera el agente se envían directamente al renderizador y nunca pasan por la capa privilegiada del navegador. Esto preserva los límites del entorno aislado incluso cuando se automatiza el control. Por ejemplo, no queremos que esta clase de eventos sintetice atajos de teclado que lleven al navegador a ejecutar tareas que no estén relacionadas con el contenido web que aparece en pantalla.

También es posible navegar mediante agentes en un contexto eventual “sin inicio de sesión”. De este modo, en lugar de compartir el perfil incógnito del usuario, que podría filtrar información, utilizamos la infraestructura StoragePartition de Chromium, que genera almacenes aislados en memoria. Así, cada sesión del agente comienza desde cero y, cuando finaliza, se eliminan todas las cookies y los datos del sitio. Es más, es posible ejecutar varias sesiones de agente “sin inicio de sesión”, cada una en su propia pestaña del navegador y totalmente aisladas unas de otras.

Nada de esto sería posible sin el aporte de la comunidad global de Chromium y su increíble trabajo en la construcción de los cimientos de la web moderna. OWL aprovecha esos cimientos y aplica un enfoque novedoso: separa el motor de la aplicación, combina una plataforma web de primer nivel con marcos nativos modernos y ofrece una arquitectura más rápida y flexible.

Al replantearnos la forma en que un navegador incorpora a Chromium, lo que hicimos fue abrir las puertas a nuevos tipos de experiencias: inicios más fluidos, una interfaz de usuario más completa, una integración más estrecha con el resto del sistema operativo y un bucle de desarrollo que avanza a la velocidad de las ideas. Si estos son los desafíos que te gustan, echa un vistazo a nuestras vacantes para trabajar en Atlas como ingeniero de Software, Atlas⁠, ingeniero de Software, iOS,⁠ y muchos puestos más⁠.

Prueba Atlas en chatgpt.com/atlas⁠⁠(se abre en una nueva ventana).