No Servers, No Cloud, No Masters: Make P2P Apps

Durante los últimos cuatro años más o menos, hemos estado trabajando en hacer algo que funcione punto a punto, de dispositivo a dispositivo, sin infraestructura alguna. Y hemos creado una plataforma, hemos creado una aplicación y más aplicaciones sobre ella, y hemos estado probándola internamente, hemos iterado, tanto iterado, pero hemos llegado a un punto donde hemos destilado lo que necesitamos hacer a los puntos de contacto más pequeños posibles para permitir que cualquier aplicación JavaScript sea peer-to-peer y se despliegue peer-to-peer.

Así que lo que eso significa es que no necesitas servidores. Crees que los necesitas, debido al problema de disponibilidad, pero ese es un problema solucionable. No necesitas la nube. Crees que la necesitas. Se han gastado presupuestos incalculables para hacerte pensar que la necesitas. Y no necesitas maestros. Todo lo que necesitas es alguna habilidad para hacer algunas cosas de front-end y la capacidad de entrar en un paradigma diferente, una forma diferente de pensar sobre la tecnología y sobre cómo la tecnología puede interactuar.

Y tú también puedes hacer aplicaciones peer-to-peer sin infraestructura, donde los datos viven en los dispositivos de los usuarios, lo que significa que ya no puedes explotar a los usuarios por sus datos. Lo siento. Pero aunque eso crea una fuente de dinero, sin duda, no necesitas dirigir esa fuente de dinero hacia OPEX pagando por infraestructura. Así que si tomas ambos lados de la ecuación, resulta que puedes monetizar aplicaciones de diferentes maneras.

No hay un solo modelo de negocio. Así que, como digo, hemos estado refinando esto durante cuatro años. Todo el proyecto ha estado en marcha durante unos 15 años. Pero hemos estado trabajando intensamente en ello durante los últimos cuatro años.

Tether se asoció con nosotros. Tether es una stablecoin con una capitalización de más de 100 mil millones que está invirtiendo muy fuertemente en tecnología descentralizada y tecnología que empodera a los usuarios. Y realmente es solo una cuestión pragmática. Todos los demás están quitando el control y el poder a los usuarios. Queremos devolvérselo. Ese es un excelente USP.

Así que aquí está la destilación. Usa un módulo. Despliega peer-to-peer. Eso es todo. No se necesita la nube. Solo de dispositivo a dispositivo. Así que la aplicación que construimos sobre esto se llama Keat. Es como meat con una K. O key con una E-T y no una Y. O como Parakeet. O en realidad lo que hemos construido se llama Pear, y la aplicación que hemos construido se llama Keat.

Así que si dices Pear y Keat mucho, es como Pear y Keat, Pear y Keat, Pear y Keat. Cuando el pájaro de Twitter murió, nació Keat. Realmente literalmente alrededor del mismo tiempo. Somos la reencarnación del pájaro. Somos la reencarnación del pájaro. Recientemente hemos tenido un gran aumento en usuarios porque la fuente secreta que nos permite permitir que los dispositivos se conecten entre sí es algo llamado hole punching.

Entonces, lo que es hole punching es un algoritmo estadísticamente garantizado para perforar a través de políticas naturales en los routers domésticos que impiden que los usuarios se conecten entre sí. También perfora a través del firewall de China. Así que tenemos alrededor de un millón de nuevos usuarios por mes en este momento en Keat, y creciendo. Bases de usuarios realmente, realmente grandes en países donde el internet se está cerrando mucho. Y usuarios más allá de eso también.

No necesitas un número de teléfono para usar Keat Messenger. Para cualquier otra aplicación, necesitas darles tu número de teléfono. No queremos saber tu número de teléfono. No queremos saber tus datos. No queremos saber. Solo queremos que uses la aplicación y te beneficies de ella. No necesitas proporcionar un correo electrónico. Nada de eso.

Así que esto está construido usando el PAIRS stack, que significa Peer-to-Peer Embedded Application Releases stack. Si no hay nube, no hay tarifas. Si no hay nube, no hay interrupciones. Esta es una forma más robusta de construir tecnología y es una forma de construir con menor costo y es una forma de construir con diferentes incentivos.

Si ya estás en Keat, o si te gustaría obtener Keat, keat.io. Este código QR te da acceso al grupo de desarrollo de PAIRS, que no está públicamente en línea ni nada. Esto es solo para desarrolladores. Actualmente hay alrededor de 7,000 personas allí, miembros. Un grupo bastante activo. Mucha gente construyendo muchas aplicaciones diferentes en esto. Mucha experimentación, mucha investigación. Y luego a veces surgen cosas donde es como, oye, esa es una aplicación completa que has construido justo ahí. Y hay muchos en la comunidad, y más y más llegando todo el tiempo. Este código QR estará en las diapositivas en la esquina inferior, para que puedas seguir obteniendo Keat y escanearlo.

Así que aquí está el stack. Tenemos un módulo llamado PAIR Runtime. Lo instalas con NPM en, digamos, una aplicación Electron, ¿verdad? Le das una clave. En realidad, un enlace con una clave en él. Así que es como un enlace PAIR, y luego solo una cadena. Pones eso en el campo de actualización de tu package.json, y luego escucha sobre un DHT usando algo llamado HyperSWARM en ese tema para eventos de actualización. Y usas PAIR, la interfaz de línea de comandos, para luego desplegar tu aplicación. Y cuando despliegas, crea un evento de actualización entre todos los pares. Y luego los pares reciben ese evento de actualización, y hay un intercambio en disco donde presionan un botón, llama a aplicar actualización, se intercambia en disco, y tienen la actualización. Es realmente así de simple. No hay servidores de por medio. Además de eso, está BAIR. Así es. Suena como pair. Comienza con una plosiva, con una B, y el logo es un oso, pero se escribe B-A-R-E. Y la razón por la que se escribe B-A-R-E es porque es muy básico. No hay biblioteca estándar como en Node. Es un runtime similar a Node que se ejecuta en móvil, que se ejecuta en escritorio, que se ejecuta en embebido, que está específicamente construido para aplicaciones peer-to-peer como ciudadano de primera clase. Así que tenía soporte para UDP y UDP+, que usamos para el transporte. Antes tenía soporte para TCP y HTTP.

Ahora también lo tiene. Pero el soporte para cualquiera de estas cosas viene como un módulo. Así que si necesitas usar el sistema de archivos en Node, simplemente usas el módulo FS. Pero en BAIR, instalas BAIR-FS, y luego lo usas. Así que hay una especie de sandboxing natural aquí, también. Como, si no lo necesitas, no lo instalas, y entonces no hay posibilidad de que sea explotado en algún tipo de ataque a la cadena de suministro si las primitivas ni siquiera están allí para hacerlo.

Hay más sandboxing que hacer en eso, pero me gusta que sea naturalmente tan mínimo como sea posible. Ni siquiera hay un objeto de proceso en BAIR. Tienes que instalar eso por separado, también. Luego está el ecosistema de módulos BAIR, que son todas esas cosas, como BAIR-FS y BAIR-UDP o lo que sea. Tienes cosas como BAIR-FFMPEG. Así que hay complementos que van más allá de lo que proporcionaría la biblioteca central de Node, también.

El ecosistema de módulos BAIR es básicamente como la biblioteca central para Node, pero más. Y luego está el ecosistema Hyper, que son las capacidades peer-to-peer. Esto es cosas como HyperSWARM, que es para conectar dos pares a través de una tabla hash distribuida mediante un enlace de tema. Luego está HyperCore, que es la capa de persistencia, y luego hay un montón de cosas que se pueden construir sobre eso, como HyperDrive, que es un sistema de archivos peer-to-peer, HyperB, que es un almacén de clave-valor peer-to-peer, HyperDB, que es una base de datos peer-to-peer, Autobase, que es una biblioteca de linearización peer-to-peer de múltiples escritores, que es lo que usamos para Keet.

Porque uno de los grandes problemas para la mensajería, o cualquier cosa que sea eventualmente consistente, que todas las cosas peer-to-peer son, tiene este problema de resolución de conflictos. Y eso es lo que Autobase resuelve. Tienes una función de aplicación, y tu función de aplicación determina cómo deben resolverse las cosas. Así que el módulo es para aplicaciones de escritorio, móviles y terminales. Simplemente lo instalas en tu proyecto. Recibes y aplicas actualizaciones over-the-air. También viene con gestión de almacenamiento peer-to-peer, porque si estás haciendo algo peer-to-peer, necesitas usar disco.

Y viene con un método llamado pair.run. Y lo que hace es iniciar un trabajador de tiempo de ejecución Bear. Así que no necesitas instalar Bear por separado en tu sistema, o algo así. Viene como una dependencia nativa. Pero luego comienza como su propio tiempo de ejecución. La razón por la que hacemos eso es porque arquitectónicamente, encontramos que podemos escribir el mismo back-end exacto... Bueno, lo llamamos un back-end, pero en realidad es local. Lo llamamos un back-end local. Así que está en el dispositivo móvil y en el dispositivo de escritorio. Tienes el mismo código de back-end exacto, que se ejecuta en este trabajador, y luego simplemente hablas con eso a través de IPC.

Así que puedes tener una aplicación React Native que hable con eso en móvil, y puedes tener una aplicación Electron que hable con eso en escritorio. Pero toda tu lógica de negocio y peer-to-peer vive en tu back-end, y luego toda tu lógica de materialización de vistas vive donde debería en la vista. Así que significa que es realmente fácil, también, agregar nuevas cosas encima. Así que podríamos agregar una aplicación de terminal que sea estilo IRC Keat, o algo así, muy fácilmente, simplemente reutilizando el mismo back-end. Así que lo que el módulo PeerRuntime te da son las actualizaciones peer-to-peer, pero también un conjunto arquitectónico de primitivas muy simples.

Eso es literalmente todas las primitivas para hacer aplicaciones peer-to-peer a través de plataformas y dispositivos. El CLI. Puedes instalarlo ahora mismo con MPX Pair. No necesitas Node para ejecutar Pair. Es su propia compilación de Bear, pero usamos NPM porque todos tienen NPM, ¿verdad? Solo para iniciarlo.

Así que tienes tu módulo PeerRuntime en una aplicación, y básicamente usas estos comandos pair para desplegarlo. Estos son literalmente todos los comandos que necesitas para tener un flujo de despliegue completo de extremo a extremo con un entorno de staging, con un entorno de pre-lanzamiento y con un entorno de producción. Así que pair-touch crea un enlace pair que crea una clave. Ese es un tema en el DHT del que estaba hablando. Pair-seed expone ese enlace. Es lo mismo que con BitTorrent.

Si estás sembrando un archivo y alguien más está tomando ese archivo, es literalmente lo mismo. Es la próxima generación de esa tecnología llamada Cademlia en la que todo esto se basa. Pair-build crea una carpeta de despliegue multi-arco. Haces tu compilación en Windows, haces tu compilación en Mac, haces tu compilación en Linux, y luego pair-build los reúne a todos en este formato único. Pair-stage, etapas tu carpeta de compilación donde básicamente se sincroniza desde el disco en una estructura hyper-core que es sembrada por ese enlace pair.

Una vez que estás haciendo eso, inmediatamente puedes tomar esa aplicación, ponerla en otra máquina, ejecutarla, volver a hacer staging con una actualización, y tu flujo de actualización funciona. Ese es tu entorno de staging interno. Puedes simplemente hacer staging de una clave en cualquier momento, enviarla a otro desarrollador y decir, oye, ¿puedes revisar esto? Todos pueden tener en un equipo una única clave de staging que es como, esta es la clave del entorno de staging. Una vez que estás satisfecho con cómo están las cosas en el entorno de staging, pasas a pre-lanzamiento.

Así que pair-provision crea un enlace de pre-lanzamiento. Todo lo que hace es eliminar operaciones intermedias. Un hyper-core es un registro de solo anexado. Así que todo lo que sucede, incluso las eliminaciones, se anexa al registro. Lo que hace un provision es simplemente tomar una instantánea del estado de los datos y sincronizar bloques a través de él. Así que luego tienes un despliegue mucho más pequeño que va a ir a las máquinas de los usuarios. Así que esa es una clave de pre-lanzamiento. Es cuando te pones realmente serio. Vas a QA, te aseguras de que esté realmente, realmente bien.

Y una vez que todos están contentos con eso, entonces vas a pair-multisig. Y lo que hace multisig es que tienes, digamos que tenemos cinco personas que son partes interesadas de una aplicación. Y necesitas que tres de las cinco personas digan, sí, voy a poner mi carrera en juego y decir que esta aplicación está lista para salir. Y voy a firmarla con mi clave pública para decir que he verificado que esta aplicación está lista para salir. Reúnes las firmas, y luego haces un commit multisig. Boom, has pasado a producción. Y ese es todo el flujo de extremo a extremo que necesitas.

Eso es lo que usamos para desplegar Keats. Y como dije, tenemos un millón de usuarios llegando al mes. Se está volviendo muy estable en este punto. Siempre hay pequeños errores de UX y cosas así, pero se está volviendo muy, muy firme en este punto. Así que estamos muy contentos con el proceso que ha surgido de nosotros al hacer esto en la práctica a lo largo de los años.

Así que este es el modelo de distribución dual. Como puedes ver, tienes distribuciones firmadas por el proveedor. Lo que eso significa es que si estás en Mac o Windows, necesitas una clave de Apple, necesitas una clave de Microsoft clave de licencia, para realmente construir aplicaciones que luego puedas dar a los usuarios, ¿verdad? Eso no es negociable. Así que puedes hacer eso, y luego puedes ponerlo en las tiendas de aplicaciones. Puedes ponerlo en tu sitio web para descargar. Pero luego, una vez que el usuario está ejecutando la aplicación, están conectados a tu semilla peer, y luego cualquier actualización que hagas pasa por el flujo de despliegue peer-to-peer y luego va a tus usuarios a través de actualizaciones peer-to-peer por aire.

También próximamente habrá un comando de instalación de pair, para que puedas simplemente instalar peer-to-peer también. Pero esto significa que en lo que respecta a tu usuario, no les importa. Simplemente están instalando una aplicación como cualquier otra aplicación. Pero para ti, has eliminado todos tus costos de infraestructura. Ya he hablado bastante sobre Bear. Creo que he cubierto mucho de esto. Puedes jugar con él con NPM IG Bear, pero eso es solo para el REPL y probar cosas ejecutar pruebas y cosas así. El objetivo de Bear es que esté incrustado en otra cosa. Como en la aplicación Electron o en dispositivos móviles o cosas de IoT.

Aquí hay un montón de módulos del ecosistema Bear solo para darte una idea de dónde estamos. Los verdes se supone que son como tu equivalente al núcleo de node, y luego algunas cosas más más allá de eso también. Este es el ecosistema Hyper. Así que tienes, como ya he mencionado, Hyper core. Tienes Hyper DHT que son conexiones directas peer-to-peer, y luego tienes Hyper swarm que es el descubrimiento de temas sobre el DHT. Estructuras de datos que he mencionado, Hyper B es el almacén de clave-valor, Hyper drive es el sistema de archivos sistema, Autobase es la linealización multi-escritor, y luego estos módulos de utilidad, core store es para gestionar múltiples hyper cores, local drive es el sistema de archivos equivalente a Hyper drive, por lo que puedes reflejar desde un sistema de archivos peer-to-peer a un sistema de archivos local y viceversa versa, que es también lo que proporciona mirror drive.

Aquí están las capas de despliegue. Así que versionas tu aplicación, como incrementas la versión del paquete tal como lo harías con un módulo o cualquier cosa, y luego haces una nueva compilación, y luego usas pair build para crear el directorio de despliegue y luego etapas ese directorio de despliegue, y ese es tu entorno de staging del que hablamos antes, que es este nivel medio aquí. Una vez que estás listo, vas a pre-lanzamiento, eso es provisión, y luego una vez que eso está listo, vas a producción, y eso es multi-sig. Así que encontramos esto muy efectivo. Luego está el ciclo de lanzamiento. Nuevamente, versionas, haces los distribuibles, construyes la carpeta de despliegue, etapas, provisionas, reparas la solicitud, obtienes firmas, verificas las firmas, comprometes, vas a producción. La razón por la que sigo diciendo lo mismo, es porque una vez que entras en el patrón, es como oh, esto es realmente fácil. Una vez que lo has configurado, es como ba-ba-ba-ba-ba. Es como un estado de flujo, y hemos estado en él por un tiempo, y se siente genial.

No tienes que lidiar con servidores caídos, servidores de staging caídos, o alguien ha empujado a él y ahora está como roto y cosas así. No tienes que lidiar con nada de eso. Así que si te gustaría jugar con estas cosas, tenemos algunos boilerplates. El boilerplate Hello Power Electron te muestra, lo clonas, es un repo, simplemente lo clonas y luego puedes seguir las instrucciones, y rápidamente obtener una aplicación Electron habilitada para PIDS peer directamente desde el principio. Si ya tienes una aplicación Electron, echa un vistazo a esto, y puedes ver cómo ponerlo allí. Es como un par de pasos. Ponlo allí, y tienes actualizaciones peer-to-peer. Recientemente, hay una publicación en el blog en pears.com, barra diagonal news, sobre esto. Acabamos de lanzar el boilerplate Hello Pair Bear. Lo que hace es que es peer-to-peer sobre actualizaciones para procesos de programas de terminal. Así que como un CLI, un REPL, un servicio daemon, todas estas cosas pueden ser escritas como ejecutables independientes ejecutables, sin dependencias peer, sin necesidad de node, nada más necesario. Puedes simplemente dárselo a tu usuario a través de descarga de sitio web, fuentes app get, brew, lo que quieras. Y luego desde allí, tienen actualizaciones peer-to-peer instantáneas. Nunca tienen que actualizar de nuevo a través de otro canal, otro mecanismo. Y lo que también tenemos próximamente, tenemos esto funcionando internamente.

Es solo cuestión de aplicar rigor y asegurarse de que todo esté bien y verificar que todo funcione. React Native boilerplate, actualizaciones peer-to-peer por aire para aplicaciones móviles. Así que obtienen su aplicación de la tienda de aplicaciones, la ponen en su teléfono, haces un lanzamiento a la aplicación móvil, sabes que eso puede tardar un par de semanas en salir y esas cosas, ¿verdad? Porque tiene todo un proceso de revisión. Eso sale a la tienda de actualizaciones y tienes esa actualización allí. Pero al mismo tiempo, puedes actualizar peer-to-peer por aire a tus usuarios a las últimas cosas para que no tengan que pasar por ese flujo de la tienda de aplicaciones. Y en ese punto, especialmente cuando estás usando un backend compartido, es fantástico, porque tienes un backend y luego simplemente despliegas por aire ese mismo backend a tu aplicación de escritorio aplicación, tu aplicación móvil y si quieres, tu aplicación de terminal también. O tus aplicaciones IoT.

Así que otras aplicaciones que construimos en producción, tenemos PearPass. PearPass es un gestor de contraseñas clave. Así que si estás harto y cansado de los gestores de contraseñas de palabras clave que filtran contraseñas en texto claro, prueba PearPass, porque PearPass no puede filtrar tus contraseñas a menos que las filtres tú mismo. Los datos están en tu dispositivo. Otro en producción es Qvac. Estos son LLMs locales con un enfoque para uso descentralizado. Así que es más un SDK y es algo que estamos comenzando a integrar en Keat también para cosas como traducciones y demás. El punto es, toda nuestra ética es que deberías poseer tus datos, los LLMs deberían trabajar para ti, no para alguien más. Eso es realmente donde está. Así que Qvac está haciendo un trabajo increíble en hacer modelos locales de alta calidad que pueden ser modelos de parámetros más altos en prem en algún lugar. Échale un vistazo.

Y luego, por supuesto, está Keat, que creo que he mencionado. Realmente, realmente buena aplicación. Otra cosa que diré sobre Keat es que, cuando haces una videollamada en Keat, y tienes una videollamada con alguien, es como, wow. No me di cuenta de que he estado viviendo mi vida a tan baja resolución. Es como cuando comes comida italiana por primera vez en Italia, ¿sabes? Si tienes un servidor y tienes personas conectándose para una videollamada a través de ese servidor, ¿qué vas a hacer? Vas a comenzar a restringir tus costos, restringiendo tus recursos, comprimiendo la transmisión de video. Si tienes una videollamada en Keat y la comparas con una videollamada en Google y cualquier otra cosa, es como el día y la noche. Porque si no hay servidor, no hay necesidad de compresión. Y eso te hace pensar, ¿verdad? ¿Qué más es así?

Pairs.com. Revisa las cosas. Docs.Pairs.com. Todo lo que necesitas saber. ¡Estamos contratando! Así que si te interesa esto, si te interesa este paradigma, si te interesa este tipo de área, hablando de P2P, trabajando en cosas de P2P, ¡genial! Ven a hablar con nosotros, ven a hablar conmigo, conéctate conmigo en Keat. Pero también, si eres de estilo nodo de pila tradicional, arquitecto de software senior, tenemos proyectos dentro de Tether con los que también estamos ayudando. Así que, tenemos una amplia gama de necesidades para que el talento realmente bueno venga y se una a nosotros. Frontenders también. Tenemos muchos frontenders trabajando en Keat porque es Electron, ¿verdad? Así que eso es cosas de API web. Móvil es React Native. Y UX. Mira, si trabajas, si estás en esta sala, te contratamos, ¿de acuerdo? Gracias.

Un montón de preguntas aquí. Veamos cuántas podemos responder. Una cosa que está en la parte superior que ha sido... Por cierto, al salir, si pudieran mantener el ruido un poco bajo, sería agradable. Sí. Gracias. Gracias. Sí. Así que hay un riesgo de que esto se convierta tal vez en una herramienta popular para los malos actores en el mundo. Así que con sistemas menos centralizados, la gente podría descontrolarse. Correcto. Esta fue una de las primeras cosas que discutimos cuando se nos ocurrió el concepto. Básicamente, se trata de compensaciones. Y si te enfocas en un tipo de mal actor, puedes olvidar otros tipos de malos actores. El espacio centralizado ha sido capturado por intereses basados en ganancias. Cuando operas en un modelo basado en ganancias, como todos saben en esta sala, entonces tomas decisiones a veces que no son en el mejor interés de tus usuarios. Y cuanto más monopolizas, más centralizas, más converge el poder en un solo punto, más posibilidades hay de abuso a gran escala. Así que cuando se trata de depredadores en línea, no creo que la vigilancia masiva sea realmente la solución.

So when it comes to predators online, I don't think that mass surveillance is actually the solution. I think that you should be putting that money instead. All the money we're putting into mass surveillance and AI surveillance and all that kind of stuff could be going to cyber detectives. And ultimately, I think the way that predators are generally taken down is actually people infiltrating and taking them down. And there's nothing about peer-to-peer that stops that. What peer-to-peer stops is the situation where you have a ultra power leverage situation where an organization or a government or whatever gets to say what's okay and what's not okay and then monitor you about that. Now you might be like, I have nothing to hide. But you don't. But if the government changes in some way, or that power changes in some way to make something that you are in your identity illegal in some way, and we're seeing that all over the world, we're seeing it in the West, we're seeing it everywhere, but in the West more so than ever, it's in our faces. You can be made illegal in a way. So do you really want people who are up to that kind of stuff to have that kind of power leverage to have that kind of control over our lives? Yeah, these are questions that we should ask for sure. I think it's a worthwhile trade-off.

One specific thing about security, just staying on that topic, about the supply chain attacks. Because you were mentioning these bear modules, which is kind of an interesting thing, is that you have a very small core and then everything is installed on top of it. But I guess the question is saying the Keat, Pear, Bear, all of these are still vulnerable to normal supply chain attacks and through maybe even updates through peer-to-peer. Is that possible? Absolutely. The supply chain attack problem is universal. Everyone is vulnerable to the supply chain attack problem. Not just in programming, but in food, in absolutely everything. If you have a problem with your supply chain, you have a serious problem. We control the supply chain for the bear modules. It's open source, but we control it. The big thing is provenance, I think. We actually have some interesting stuff coming down the pipeline also to do with distributed package registries and stuff like that. And because it's all cryptographically based, you can create a system that's peer-to-peer with much better provenance primitives than you can with a centralized system. Because a centralized system is a black box. Once it goes in the black box, you don't know. But if it's open source and decentralized, you do know. So that can reduce the attack surface and we're moving towards that.

So that can reduce the attack surface and we're moving towards that. That's why we do multi-sig as well. When you run the pear-stage command, or the other ones, it gives you a diff of the files that are changing. And it's up to you to verify every line of that diff and be sure. And that's what when you're signing on a multi-sig, you're putting your career on the line saying, I'm sure that there's no supply chain attack here. Right. And I guess that's also how it's distributed through the peer-to-peer network, is that you have these signatures on each update that goes out. And then the first update... What's unclear to me is like, how does the first update go out if there are no servers? Well, you just get it from a website because it's just like an app that you just run. I get that part. But once you've downloaded it, how does your local thing that's running on your desktop or on your mobile device, how does it then get updates? It turns it into a peer. And then that peer connects with another peer that's seeding. Okay. So your peers or whoever is creating the software... We could get other peers to seed it. Got it.

One thing about the peer-to-peer via a browser, is there some way to do this? I don't think that's ever going to be a situation that's going to happen. Like technically, there's no reason why not. But look, the browsers are controlled by specs. The specs, people that work on the specs, a lot of them are hired by companies that have interests. And so things get implemented and don't get implemented based on those interests and agendas. It's just a natural phenomenon. It's a naturally occurring thing. The browser doesn't have the primitives. We use UDP with a little layer on top of it for the transport, and the browser's just never going to have UDP. It's just not going to happen. So we think apps are the way to go. There's been people in the community making peer-to-peer browsers and different things like that. All very interesting stuff. But we do like the web technologies because it's so available and so many people know it. So putting on things like Electron is where the sweet spot is for us. Yeah, okay.

Yeah, I think that's all the time that we have for today. But yeah, thanks again, David. So yeah, give a hand to David.