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, dispositivo a dispositivo, sin ninguna infraestructura. Y hemos creado una plataforma, hemos creado una aplicación, y más aplicaciones sobre ella, y hemos estado probándola internamente, hemos iterado, mucho iterado.

Pero hemos llegado a un punto en el que hemos destilado lo que necesitamos hacer hasta los puntos de contacto más pequeños posibles, para permitir que cualquier aplicación de JavaScript sea punto a punto, y se despliegue punto a punto.

Así que lo que eso significa es que no necesitas servidores. Crees que sí, debido al problema de disponibilidad, pero ese es un problema solucionable. No necesitas la nube. Crees que sí. Se ha gastado un presupuesto incalculable para hacerte pensar que sí. Y no necesitas maestros. Todo lo que necesitas es alguna habilidad para hacer algunas cosas de front-end, y la habilidad para entrar en un paradigma diferente, una forma diferente de pensar sobre la tecnología, y cómo la tecnología puede interactuar, y tú también puedes hacer aplicaciones punto a punto, 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. Pero, aunque eso crea una fuente de dinero, sin duda, no necesitas dirigir esa fuente de dinero en OPEX pagando por infraestructura. Así que si tomas ambos lados de la ecuación, resulta que puedes realmente monetizar aplicaciones de diferentes maneras. No hay solo un modelo de negocio.

Así que, como digo, hemos estado refinando esto durante cuatro años ahora. Todo el asunto ha estado en proceso 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 cosa pragmática. Nadie más está 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 punto a punto. Eso es todo. No se necesita nube. Solo dispositivo a dispositivo. Así que la app que hemos construido sobre esto se llama Keet. Es como meat con una K o key con un ET y no una Y. O como Parakeet. O en realidad, lo que hemos construido se llama Pear y la app que hemos construido se llama Keet. Así que si dices Pear y Keet mucho es como Pear y Keet, Pear y Keet, Pear y Keet. Cuando el pájaro de Twitter murió, Keet nació, literalmente alrededor del mismo tiempo. 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. Así que lo que es hole punching es un algoritmo estadísticamente garantizado para atravesar políticas de nat traversal en routers domésticos que impiden que los usuarios se conecten entre sí. También atraviesa el firewall de China. Así que tenemos alrededor de un millón de nuevos usuarios por mes en este momento en Keet 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 Keet Messenger. Para cualquier otra app necesitas darles tu número de teléfono.

No queremos conocer tus datos. {{^}}No queremos saber. Solo queremos que uses la app y te beneficies de ella. No necesitas proporcionar un correo electrónico, nada de eso.

Así que esto está construido usando la pila PAIRS. 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 Keet o si te gustaría obtener Keet, Keet.io. Este código QR te da acceso al grupo de desarrollo PAIRS. Que no está públicamente en línea ni nada. Esto es solo para desarrolladores. Actualmente hay unas 7,000 personas allí. Miembros. Un grupo bastante activo. Mucha gente construyendo muchas apps diferentes en esto. Mucha experimentación, mucha investigación. Y luego a veces surgen cosas donde es como, oye, esa es una app completa que has construido ahí. Y hay muchas en la comunidad. Y más y más vienen todo el tiempo. Este código QR estará en las diapositivas en la esquina inferior para que puedas seguir obteniendo Keet y escanearlo. Así que aquí está la pila. Tenemos un módulo llamado PAIR Runtime. Lo instalas con NPM en, digamos, una app de Electron. 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 a través de 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 en 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, intercambia en disco, y tienen la actualización. Es realmente tan simple como eso.

No hay servidores de por medio. Además de eso, está BEAR. Así es, suena como pear. 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 entorno de ejecución similar a Node que se ejecuta en móviles, que se ejecuta en escritorios, que se ejecuta en embebidos, 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 de tener soporte para TCP y HTTP.

Ahora también tiene eso. Pero el soporte para cualquiera de estas cosas viene a través de un módulo. Así que si necesitas usar el sistema de archivos en Node, simplemente usas el módulo FS. Pero en BEAR, instalas bear-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 luego 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 ahí para hacerlo, ¿verdad? Hay más sandboxing que hacer en eso, pero me gusta que sea naturalmente lo más minimalista posible. Ni siquiera hay un objeto de proceso en BEAR. Tienes que instalar eso por separado también.

Luego está el ecosistema de módulos BEAR, que son todas esas cosas como bear-fs y bear-udp o lo que sea, pero también tenemos cosas como bear-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 BEAR 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 hyper-swarm, que es para conectar dos pares a través de una tabla hash distribuida mediante un enlace de tema. Está hyper-core, que es la capa de persistencia, y hay un montón de cosas que se pueden construir sobre eso, como hyper-drive, que es un sistema de archivos peer-to-peer, hyper-B, que es un almacén de clave-valor peer-to-peer, hyper-DB, 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 resuelve autobase. 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 por aire. 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 peer.run.

Y lo que hace es que inicia un trabajador de bear runtime. Así que no necesitas instalar bear por separado en tu sistema ni nada por el estilo. Viene como una dependencia nativa, pero luego se inicia como su propio runtime. La razón por la que hacemos eso es porque, arquitectónicamente, encontramos que podemos escribir exactamente el mismo back-end, lo que 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 exactamente el mismo código de back-end, que se ejecuta en este trabajador, y luego simplemente hablas con eso a través de IPC.

Así que puedes tener una aplicación de React Native que está hablando con eso en móvil, y puedes tener una aplicación de Electron que está hablando con eso en escritorio. Pero tienes toda tu lógica de peer-to-peer y lógica de negocio viviendo 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 también es muy fácil agregar nuevas cosas encima. Así que podríamos agregar una aplicación de terminal que sea de estilo IRC o algo así, muy fácilmente, simplemente reutilizando el mismo back-end. Así que lo que te da el módulo PeerRuntime 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 npx pair. No necesitas Node para ejecutar pair. Es su propia construcció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 de pair para desplegarlo. Esto es 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 de pair. Eso crea una clave. Eso es un tema en el DHT del que estaba hablando. Pair seed expone ese enlace. Es igual que con BitTorrent. Si estás sembrando un archivo y alguien más ha tomado ese archivo, es literalmente lo mismo. Es la próxima generación de esa tecnología llamada Cademlia en la que todo esto está basado. Pair build crea una carpeta de despliegue multi-arco. Así que haces tu construcción en Windows. Haces tu construcción en Mac. Haces tu construcción en Linux.

Y luego pair build los reúne a todos en este formato único. Pair stage, preparas tu carpeta de construcción donde básicamente se sincroniza desde el disco en una estructura de hyper-core, que es sembrada por ese enlace de pair. Una vez que haces eso, inmediatamente puedes tomar esa aplicación, ponerla en otra máquina, ejecutarla, preparar de nuevo con una actualización, y tu flujo de actualización funciona. Ese es tu entorno de staging interno. Puedes simplemente preparar una clave en cualquier momento, enviarla a otro desarrollador y decir, oye, ¿puedes revisar esto? Y todos pueden tener en un equipo una sola 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, vas a prerelease. Así que pair provision crea un enlace de prerelease. 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 sincronizarlo en bloque. 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 prerelease. 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 multi-sig.

Y lo que hace multi-sig es que tienes, digamos, 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 multi-sig. 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 en un mes. Se está volviendo muy estable en este punto. Siempre hay, como, pequeños errores de UX y cosas así, pero, como, se está volviendo muy, muy firme en este punto. Así que estamos muy contentos con esto, el proceso que ha surgido de nosotros realmente haciendo 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 de par.

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 par, para que también puedas instalar peer-to-peer. Pero esto significa que, como, en lo que respecta a tu usuario, no les importa. Como, 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 ello con npmig-bear, pero eso es solo para, como, el REPL y, como, probar cosas, ejecutar pruebas y cosas así. El objetivo de Bear es que esté incrustado en algo más, 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, esto es, como, tu equivalente al núcleo de Node y luego algunas cosas más allá de eso, también. Este es el ecosistema Hyper. Así que tienes, como ya he mencionado, Hypercore. Tienes HyperDHT, que son conexiones directas peer-to-peer, y luego tienes HyperSWARM, que es el descubrimiento de temas sobre el DHT. Estructuras de datos que he mencionado. Hyper B es el almacén de clave-valor. HyperDrive es el sistema de archivos. Autobase es la linealización de múltiples escritores. Y luego estos módulos de utilidad, almacenamiento central para gestionar múltiples Hypercores. Unidad local es el equivalente del sistema de archivos a HyperDrive. Así que puedes reflejar desde un sistema de archivos peer-to-peer a un sistema de archivos local y viceversa, que es también lo que proporciona MirrorDrive. Aquí están las capas de despliegue. Así que versionas tu aplicación. Como, aumentas la versión del paquete de la misma manera que lo harías con un módulo o cualquier cosa, igual allí.

Y luego haces una nueva construcción, y luego usas pair-build para crear el directorio de despliegue. {{^}}Y luego preparas ese directorio de despliegue, y ese es tu entorno de preparación del que hablamos antes, que es este nivel intermedio aquí. Una vez que estás listo, pasas a pre-lanzamiento. Eso es provisión, y luego una vez que eso está listo, pasas a producción, y eso es multi-sig. Así que encontramos esto muy efectivo.

Luego está el ciclo de lanzamiento. Nuevamente, versionas, haces los distribuidos, construyes una carpeta de despliegue, preparas, aprovisionas, reparas la solicitud, obtienes las firmas, verificas las firmas, confirmas, pasas 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 configuras, es como, ba-ba-ba-ba-ba, ba-ba-ba-ba-ba, y 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 preparación caídos, o alguien ha empujado a él, y ahora está roto y cosas así. No tienes que lidiar con nada de eso. Así que si te gustaría jugar con estas cosas, tenemos algunas plantillas de inicio. La plantilla de inicio Hello Power Electron te muestra... Lo clonas. Es un repositorio. Simplemente lo clonas, y luego puedes seguir las instrucciones y rápidamente configurar una aplicación de Electron habilitada para PIDs-peer desde el principio. Si ya tienes una aplicación de Electron, echa un vistazo a esto, y puedes ver cómo ponerlo allí. Es como un par de pasos. Ponlo allí, y tienes actualizaciones PIDs-peer. Recientemente hemos... Hay una publicación en el blog en pairs.com, barra diagonal news, sobre esto. Acabamos de lanzar la plantilla de inicio Hello Pair Bear, y lo que hace es que es peer-to-peer sobre sus 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. Sin dependencias de pares, sin necesidad de node, nada más necesario que puedas simplemente dar a tu usuario a través de descarga de sitio web, fuentes de app get, brew, lo que quieras. Y luego desde allí, tienen actualizaciones instantáneas peer-to-peer. 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 esté bien y verificar que todo funcione.

React Native boilerplate, actualizaciones peer-to-peer over-the-air para aplicaciones móviles. Así que obtienen su aplicación de la App Store. La ponen en su teléfono. Haces un lanzamiento para la aplicación móvil, sabes que eso puede tardar un par de semanas en salir y todo, ¿verdad?, porque tiene todo un proceso de revisión. Eso sale en la App Store, y tienes esa actualización allí. Pero al mismo tiempo, puedes hacer una actualización peer-to-peer over-the-air a tus usuarios con lo último, para que no tengan que pasar por ese flujo de la App Store.

Y en ese punto, especialmente cuando estás usando un backend compartido, es fantástico porque tienes un backend, y luego simplemente despliegas over-the-air ese mismo backend a tu aplicación de escritorio, 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 gestores de contraseñas de palabras clave filtrando 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 empezando a integrar en Keat también para cosas como traducciones y demás. Pero el punto es, toda nuestra ética es, 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 algún lugar local. Échale un vistazo. Y luego, por supuesto, está Keat, que creo que he mencionado. Realmente, realmente buena aplicación. Una otra cosa que diré sobre Keat es, 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? Pero si tienes un servidor y tienes personas conectándose para una videollamada a través de ese servidor, ¿qué vas a hacer? Vas a empezar 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 o en 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? Como, ¿qué más es así? Únete a nosotros en Keat en el Pear Dev Group. Pears.com barra diagonal news, revisa las cosas. Docs.pears.com, todo lo que necesitas saber. Estamos contratando.

Ven a hablar con nosotros. Ven a hablar conmigo. Conéctate conmigo en Keat. Pero también, si eres del tipo stack tradicional, sin estilo de arquitectos de software senior, tenemos proyectos dentro de Tether en 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. Mobile es React Native. Y UX. Mira, si trabajas, si estás en esta sala, te contrataremos, ¿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 bajar un poco el volumen, eso 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, entonces la gente podría descontrolarse. Correcto. Esta fue una de las primeras cosas que realmente discutimos cuando se nos ocurrió el concepto. Básicamente, se trata de compensaciones. Y si te enfocas en un tipo de mal actor, puedes olvidarte de los otros tipos de malos actores.

El espacio centralizado ha sido capturado por intereses basados en el lucro. Cuando operas en un modelo basado en el lucro, como todos saben en esta sala, entonces tomas decisiones a veces que no están en el mejor interés de tu usuario. Y cuanto más monopolizas, más centralizas, más converge el poder en este único punto, más posibilidades hay de abuso a gran escala. Cuando se trata de depredadores en línea, no creo que la vigilancia masiva sea realmente la solución. Creo que deberías estar poniendo ese dinero en su lugar. Todo el dinero que estamos poniendo en vigilancia masiva y vigilancia de IA y todo ese tipo de cosas podría estar yendo a detectives cibernéticos.

Y, en última instancia, creo que la forma en que los depredadores generalmente son derribados es en realidad infiltrándose y derribándolos. Y no hay nada en peer-to-peer que detenga eso. Lo que peer-to-peer detiene es la situación donde tienes una situación de ultra-poder donde una organización o un gobierno o lo que sea puede decir qué está bien y qué no está bien y luego monitorearte al respecto. Ahora, podrías pensar, no tengo nada que ocultar. Pero no lo tienes. Pero si el gobierno cambia de alguna manera o ese poder cambia de alguna manera para hacer algo que tú eres, en tu identidad, ilegal de alguna manera — y lo estamos viendo en todo el mundo, ¿verdad? Lo estamos viendo en Occidente. Lo estamos viendo en todas partes. Pero en Occidente, más que nunca, está en nuestras caras, ¿verdad? Puedes ser hecho ilegal de alguna manera, ¿verdad? Entonces, ¿realmente quieres que las personas que están en ese tipo de cosas tengan ese tipo de poder, tengan ese tipo de control sobre nuestras vidas?

Sí, sí, estas son preguntas que deberíamos hacernos, sin duda. Creo que es un intercambio que vale la pena. Sí, una cosa específica sobre seguridad, solo manteniéndonos en ese tema, sobre los ataques a la cadena de suministro, porque mencionabas estos módulos bear, que es algo interesante, es que tienes un núcleo muy pequeño y luego todo se instala encima. Pero supongo que la pregunta es si el Keet, Pear, Bear, todos estos todavía son vulnerables a los ataques normales a la cadena de suministro y tal vez incluso a través de actualizaciones a través de peer-to-peer. ¿Es eso posible? Absolutamente. El problema de los ataques a la cadena de suministro es universal. Todos son vulnerables al problema de los ataques a la cadena de suministro, no solo en programación, sino en alimentos, en absolutamente todo.

Si tienes un problema con tu cadena de suministro, tienes un problema serio. Controlamos la cadena de suministro para los módulos bear. Es de código abierto, pero lo controlamos. Lo más importante es la procedencia, creo. De hecho, tenemos algunas cosas interesantes que vienen en camino también relacionadas con registros de paquetes distribuidos y cosas así. Porque todo está basado criptográficamente, puedes crear un sistema que sea peer-to-peer con primitivas de procedencia mucho mejores de lo que puedes con un sistema centralizado. Porque un sistema centralizado es una caja negra. Una vez que entra en la caja negra, no sabes. Pero si es de código abierto y descentralizado, sí sabes. Así que eso puede reducir la superficie de ataque y nos estamos moviendo hacia eso. Por eso también hacemos multi-sig. Cuando ejecutas el comando pair stage, o los otros, te da un diff de los archivos que están cambiando.

Entiendo esa parte, pero una vez que lo has descargado, ¿cómo hace tu cosa local que está ejecutándose en tu escritorio o en tu dispositivo móvil, cómo recibe entonces las actualizaciones? Lo convierte en un peer. Y ese peer se conecta con otro peer que está sembrando. Bien, entonces tus peers o quien sea que esté creando software. Podríamos conseguir que otros peers siembren también. Entendido, entendido.

Bien, sí, creo que ahora lo entiendo. Sí, una cosa sobre el peer-to-peer a través de un navegador, ¿hay alguna manera de hacer esto o? No creo que eso vaya a ser una situación que vaya a suceder. Técnicamente, no hay razón para que no, pero mira, los navegadores están controlados por especificaciones, las especificaciones, las personas que trabajan en las especificaciones, muchos de ellos son contratados por empresas que tienen intereses. Y así, las cosas se implementan y no se implementan basadas en esos intereses y agendas. Es solo un fenómeno natural. Es algo que ocurre naturalmente.

El navegador no tiene las primitivas. Usamos UDP con una pequeña capa encima de él para el transporte y el navegador simplemente nunca va a tener UDP. Simplemente no va a suceder. Así que creemos que las aplicaciones son el camino a seguir. Ha habido personas en la comunidad creando navegadores peer-to-peer y cosas diferentes como esa, todo material muy interesante. Pero nos gustan las tecnologías web porque son tan accesibles y tanta gente las conoce. Así que construir sobre cosas como Electron es donde está el punto ideal para nosotros. Sí, bien.