También está bear-http, bear-http1 creo que se llama, y bear-net, bear, todas las cosas que están en Node Core están en bear, y eso está en el ecosistema de módulos bear, y más también, como bear-ffmpeg, f-f-m-p-e-g, que usamos en Keats para renderizado de video y otras cosas así. No renderizado de video, soporte de renderizado de imágenes a través de plataformas. El ecosistema de módulos hyper son las capacidades reales peer-to-peer, y pair la línea de comandos y pair runtime el módulo están ambos construidos sobre módulos hyper. Así que pair runtime es la biblioteca. Vamos a echarle un vistazo rápido. Así que este es el módulo pair runtime, y básicamente creas una instancia de él, le pasas algunas opciones, y luego tienes un evento de actualización y un evento actualizado. También viene con un método run, que es para ejecutar un trabajador bare, que viene a través de npm install como un nativo. El objetivo de eso es tener un entorno de backend local consistente usando el mismo runtime en móvil y escritorio, porque entonces puedes ejecutar un backend, tener React en tu aplicación de escritorio, y React Native en tu aplicación móvil como capas de vista, pero hablando con el mismo backend local peer-to-peer. Cuando juntas todo eso, básicamente tienes la misma arquitectura y enfoque que usamos para Keat. También hay, debería mencionar, PairPass, que es otra aplicación construida sobre Pair, que es un gestor de contraseñas. Así que si estás cansado de los gestores de contraseñas filtrando tu contraseña, esto no puede hacer eso porque está completamente en tus propios dispositivos. Mientras lo tengas en un par de dispositivos, si pierdes todos menos uno de tus dispositivos, entonces estás bien. Así que ponlo en un par de dispositivos, comienza a gestionar tus contraseñas peer-to-peer. No te preocupes nunca más por que tus contraseñas se filtren. Es una propuesta interesante. También está Qvac, que es una aplicación de IA, una aplicación de IA local. Va a haber mucho más viniendo de eso también pronto, y estamos en el proceso de lograr eso. Y estamos integrando elementos de eso en Keat también, cosas como la traducción, pero todo se ejecuta localmente. Así que una de las cosas clave de esta tecnología es, aparte de que no hay costos de infraestructura, es que no hay explotación de datos, no como un mecanismo incorporado. Así que las razones por las que construyes y demás pueden ser diferentes, pero lo que puedes construir es muy superior a los productos existentes en términos de robustez, anti-fragilidad, en términos de seguridad. Seguridad contra la explotación por organizaciones poderosas. Creo que ese es un punto de venta masivo de la tecnología, especialmente en los tiempos actuales. Así que vamos a pasar por la masterclass. También tengo a Dominic en la llamada, quien trabaja con Hull Punch. Dom, ¿estás ahí? Debería presentarte también. Sí, así que Dominic ha estado trabajando en esta tecnología. Cuéntanos un poco sobre ti también, Dom. ¿Por dónde empezar? Así que trabajo en el backend de Keat.

Y luego, además de eso, también ejecutamos Electron o React Native. Así que sí, mi experiencia es muy diferente a la de Dave. No vengo de un entorno de ciencia de datos. No vengo tanto de un entorno peer-to-peer o de código abierto. He venido mucho de Go, y obviamente un mundo completamente diferente con eso de ejecutar AWS y servicios Go y todo este tipo de cosas. Pero las cosas peer-to-peer, han sido estructuradas de una manera que lo hace tan fácil de aprender que he podido trabajar con eso y experimentar con un montón de cosas diferentes y explorar todas las cosas diferentes que hemos estado haciendo para que sea realmente fácil para las personas crear aplicaciones peer-to-peer. Y sí, no quiero entrar demasiado en eso o arruinar las cosas, pero hay muchas cosas realmente geniales allí que nos están permitiendo hacer aplicaciones mucho más rápido y mucho más fácil que nunca para todo. Y eso es algo que Peer desbloquea, poder hacer aplicaciones para Windows, para Mac, para iOS, para Android, con un clic de un botón sin herramientas especiales, sin miles de archivos nativos que necesitas gestionar. Solo aplicaciones súper simples, súper pequeñas que funcionan en todas partes. Y sí, como dije, todo ha sido estructurado de una manera que ha sido realmente fácil de aprender para alguien como yo que viene de Go. Sí, creo que eso lo cubre lo suficiente. Sí. Y podemos tener una discusión sobre las otras aplicaciones que se están construyendo al final de la masterclass también. Guárdalo para el final. Pero cosas extremadamente emocionantes. Y Dominic también está trabajando en algunas cosas muy, muy emocionantes que tal vez podamos compartir al final también. Bien, entonces Dom, hubo un pequeño problema. ¿Cómo va eso con esto? Solo estamos probando ahora mismo, pero creo que solo faltaba un oyente en el Read Me. Solo verificándolo. Bien, genial. Así que podrías hacer un PR durante esto y lo arreglaremos en vivo. Sí. Pero no te preocupes. Solo mantente actualizado con nosotros mientras lo hacemos. Así que si ejecutas este comando, lo pondré en el... Chat. ¿Dónde está el chat? También lo pondré en el chat de pair dev. Bien. Así que solo para ser absolutamente claro, esta tecnología no es un blockchain. Esta tecnología no es un token o una moneda, y nunca, jamás será ninguna de esas cosas. Un blockchain es un estado federado para consenso global. Y obviamente, en un blockchain, puedes acuñar monedas. Bien. Lo que es pair... lo que es el stack de pair... lo que es el stack de pair, es en ayuda de conexiones directas peer-to-peer entre dispositivos, punto a punto, donde el consenso está en el estado local entre los pares, local como en el estado intra-subjetivo entre los pares que están participando, entre los dispositivos o los humanos, ambos, que están participando entre sí, en lugar de una verdad global. Esta es una diferencia significativa. Pero cuando tienes una tecnología que está distribuida, definiendo estado global, verdad global, y otra que es para establecer estado o verdad intra-subjetiva, entonces esas dos cosas pueden trabajar juntas muy bien. Y cuando necesitas pasar de la verdad intra-subjetiva a la verdad global, entonces un blockchain se vuelve bastante interesante. Así que ejercicio uno, hagámoslo. Así que vamos a comenzar readme.md. Ejercicios haciendo, lo siento, debería ser ejercicios haciendo. Así que vamos a usar el boilerplate Hello Pair Electron. Este es un template boilerplate para comenzar rápidamente con una aplicación Electron que tiene Pair Runtime preintegrado y que utiliza la arquitectura de trabajador. Todo en este readme, pasa desde el desarrollo hasta la construcción de los distribuibles, hasta realmente desplegarlos y el flujo completo de despliegue, incluyendo a través de entornos de staging y despliegue, incluyendo a través de entornos de staging y compartiendo y diferentes cosas internamente. Pero veremos más sobre esto el miércoles. Por ahora, solo estamos interesados en usarlo para iniciar nuestra aplicación. Así que lo que queremos hacer es clonar eso a una carpeta que llamaremos chat. Oh, parece que he hecho esto antes. Bien, intentemos de nuevo.

Bien, intentemos de nuevo. Okay. Y luego dentro de la carpeta de chat, solo voy a cambiar el nombre. Bueno, voy a establecer el nombre que ya va a ser chat. Oh, no, no es así. Voy a establecer el nombre de Hello Pair Electron a chat y voy a establecer el nombre del producto a chat con C mayúscula. Y voy a establecer la versión a 0.0.0.0. Así. Estas cosas son importantes porque más adelante en la próxima sesión estaremos actualizando la versión y también el nombre es importante porque queremos crear una aplicación que se llame chat.app, ¿verdad? No Hello Pair Electron. E instalar dependencias. Con respecto a estas advertencias de deprecación, tal vez desaparezcan. Con respecto a estas advertencias de deprecación, tal vez haya algunas advertencias de auditoría npm o lo que sea. Ese es el estado del arte del ecosistema para Electron. Y no hay mucho que no esté realmente relacionado con lo que estamos mostrando. La otra cosa sobre todo este asunto de auditoría es que la mayoría es un sinsentido. Algo de eso es real. Pero no es contextualmente importante, no es una vulnerabilidad en contexto. Y así se queda ahí en este impasse. Pero hemos verificado todo. Hemos revisado. Todo está bien. Así es como es el ecosistema. Así que ahora hemos instalado. npm start. Genial. Así que si llegas a ese punto, entonces estás en buena forma. Te daré unos minutos para que llegues a eso. Dame un pulgar arriba cuando estés listo. Siempre que llegues a este punto de npm start y comiences Electron, dame un pulgar arriba y pasaremos al siguiente paso. Le daré cinco minutos. Hey, Christian, estás en Ubuntu, ¿verdad? Así que no te preocupes por el asunto del runtime de MPEX pair. Lo que está haciendo es ejecutándose. En realidad está ejecutando paired, diciéndote que no está en el path. Solo... ¿Dónde está? ¿Dónde está? Intenta esto. Oh, está en Windows. Bien, bueno, es este. Intenta eso. Y si eso no funciona, puedes ejecutarlo directamente desde esa carpeta justo aquí. Dale un par de minutos más. Dame un pulgar arriba cuando estés listo. O si todavía hay un problema, vamos a resolverlo. Creo que estás en silencio. Oh, vaya. Comienza de nuevo. Bien, así que vamos a hacer el chat up. Read me, que es el siguiente paso. Y lo que tenemos aquí es una arquitectura para ello. Y vamos a estar usando HyperSWARM. Y HyperSWARM es uno de los módulos Hyper que usamos para conectarnos a otros pares a través de una tabla hash distribuida.

The king is dead. That's the end of that game. All right, too late for anyone who wanted to join. Cool. Así que, peer-to-peer es realmente genial. Lo que puedes hacer con ello es increíble. Significa que no necesitas un montón de cosas que piensas que necesitas. Extremadamente eficiente. No se requiere compresión, porque es solo entre peers. Y nuestra stack es... la stack de pair es precisamente para este tipo de casos de uso. Hablando de casos de uso, ya que estamos terminando, primero que nada, ¿alguna pregunta antes de que pasemos a la sección, la siguiente sección? Hablemos de otras apps que estamos construyendo usando esta tecnología y luego podemos concluir. Así que, ¿qué pasaría si no necesitaras un servidor centralizado para la conocida herramienta de versionado descentralizada conocida como Git? Porque resulta que no necesitas eso. No sé dónde estamos con esto, Dom. ¿Cuál es la situación? Oh, sí, estoy probando bien. Quiero decir, puede que necesitemos algo de revisión y ordenar la experiencia del usuario y unir nuestras historias sobre liberar cosas y multi-firma. Pero en este punto, realmente solo necesitamos envolverlo en una app de pair para que podamos comenzar a probarlo en la comunidad, para ser justos. Creo que tal como está actualmente, hace muchas cosas buenas con las que necesitamos jugar y hacer que la gente juegue. ¿Y tenemos una fecha de lanzamiento? No tenemos una fecha de lanzamiento aún, ¿verdad? No. Pero realísticamente, quiero decir, como dije, podemos sacar APKs en cualquier momento. Es solo, sí, revisar cosas, ordenar cosas. Sí. Así que, esto es un adelanto de algo que realmente nos emociona. Hay un NPM install que puedes usar para configurar tu máquina, muy trivialmente, para soportar Git plus pair links que se ven así. Lo pondré en nuestro chat efímero aquí. Así que, Git plus pair key. Mi repo. ¿Git ya es público, Dom? Sí, eso es todo NPM. Sí, así que esto ya es algo que puedes hacer. ¿Cómo se llama, perdón, Git remote? Git transport. Transport. Nueva instalación global. ¿Puedes repetir? Nueva instalación global. Así que, si ejecutas ese comando, obtendrás soporte para Git plus pair. Si hay uno que pueda clonar de ti, Dom, sería genial. Sí, solo iba a sacar la lista de mi máquina. Y lo que eso significa es que estás clonando de un peer en lugar de desde un sitio web o lo que sea. Mi web de pruebas favorita. Sí, así que, si quieres clonar de un peer, puedes clonar de un peer. Además de eso, puedes hacer un cambio en tu archivo NPM RC para que soporte la instalación de dependencias desde peers. Sí. Así que podrías tener en tu package.json, podrías tener... Oh, shoot. Podrías tener, como, foo. Y luego... Y luego... Git plus pair. Key. Well, fork length. Key.

And with the fork length and key of any given pair link, you have... you have a... a locked-in version that's just self-described. Which means you don't need to use SEMVer for that. We could figure out ways to use SEMVer, but that's something that works. No, that doesn't work right now, does it, Dom? It needs the HTTP in front of it to work. For NPM, it does, yeah. I mean, NPM doesn't support just anything that you want. It's that it supports Git plus HTTPS, or HTTPS, or Git... Or is it Git plus HTTPS?So, for... Yeah, exactly. So, what it means is... Yeah. That you can set up in your NPM config, basically forward it to other stuff. Because, basically, anything that starts with Git plus HTTPS will get forwarded to Git. And then, from there, Git can then forward to whatever, what you want, based on the contents of it. So, it sort of facades it. Yeah, so what you can do is you can do Git clone like that. And I'm seeing that right now. So, it should work. It's all moving really quickly.So, this is the... The fork is the... Whether the hypercore has been truncated. Which is... So, it's forked off in a different direction. And the length is the... Is the length. So, we can use that as a... So, it means you clone it. Yeah, exactly. Which means you can clone it at the exact point that it's going to let you see just your version. And you can actually do this with Git modules, just with NPM modules quite easily as well. And obviously, that length locks you in and keeps you knowing that you're getting exactly what you want. So, now I'm cloning over Git pair. Yeah, I could see you connected as well. From you as a pair, I'm cloning the B4a repo. Lovely, live demo. I can see you connected, I can tell you that much.

Yeah. There we go. It's doing something. Oh, yeah. My blind PO is running as well, actually. This is... We've done this a bunch of times, and it works every time. Yeah. There we go. Oh, there we go. Yeah, it's probably because I was making some changes with my blind PO, but I don't know. I've got a slow connection as well. And we're on zero. So, that will probably explain it. Yeah, we're on a video call and everything. Oh, there we go. Nothing is. It's a connection. Boom. There it is. And obviously, if you do get... What's it called? Not git diff. Git log. Git log. Yeah, you can see everything's in there, just like normal. Fantastic.So, that's one thing. And then the other thing is the thing that you need to get rid of the need for a centralized server for storing your Git stuff, which is the ability to do issues, track issues, do PRs, and all of that. But obviously, with a peer-to-peer multi-writer data structure like AutoBase, and with a peer-to-peer DHT topic connection library like HyperSWARM, you can put those two things together again, and you can make an app that has a UI for issues and for peer reviews and for looking at code bases. And even as far as running action workflows, eventually. But that's also something that's in the works, right, Dom? Yeah, exactly. And the key thing is we're also trying to, rather than rush into as many features as possible, see how much you can do with as little as possible, which is kind of like a very paw-punchy approach to things anyway, trying to do as much with as little as possible to see how powerful things really are.And one of the great examples of this is by... not having loads of layers, by not having loads of... features and roles and users and multi-writing and stuff too quickly, we'll also see that the big wins we can get from... well, while everyone else is getting hacks and everyone else is losing data and everyone else is falling apart, by doing something as simple as this, I now have a repo that no one else could write to, and if no one wants to, they just have to make a fork of it. Yeah, and we can always, if we need to share a repo between us, it's no problem, you know. Yeah. And GitHub does go down a lot, let's be honest. It was down last week. Yeah. What's this about globally installing Bear first? Is GIT Transport relying on... Yeah, it's using Bear these days actually. Why not use Bear sidecar? Because Bear is better. Pure Bear. Yeah, OK. But if you did it that way and you used a worker... Yeah, sure. As far as possible. Then you wouldn't have to have it as a peer dependency.

Mikhail, quien se suponía que iba a presentar esta, no puede, así que lo estoy haciendo yo. Pero también haré otra masterclass el miércoles que está relacionada con esta. Esta masterclass trata sobre la creación de aplicaciones peer-to-peer, aplicaciones peer-to-peer en tiempo real. La próxima semana es... Lo siento, el próximo miércoles viene, el miércoles que viene, se trata de desplegar aplicaciones peer. No va a ser para nada centrada en React, pero puedes ver cómo funciona con React, sin problema, porque se trata del andamiaje alrededor de una aplicación React o una aplicación Svelte o cualquier aplicación que desees. Bueno, déjame contarte... En realidad, déjame hacerlo de esta manera. Déjame contarte sobre mí y cómo me metí en esto. Y creo que eso ayudará a la comprensión. Así que escribí un libro hace más de una década, creo, llamado Node Cookbook. Fue un libro para aplicaciones Node.js cuando Node estaba en sus primeras etapas, entre la versión 0.6 y 0.8. A partir de ahí, pasé a trabajar en capacitación y consultoría y capacité y consulté en varias organizaciones, desde startups hasta Fortune 500. Y también soy el autor de la Linux Foundation, OpenJS Foundation, certificaciones para el desarrollo de aplicaciones JavaScript y para el desarrollo de servicios JavaScript. Pero parte del trabajo, especialmente cuando llegas a organizaciones más grandes, como grandes organizaciones empresariales, comienzas a ver mucha complejidad logística organizativa. Y la tecnología y cómo interactúa con eso, con esas estructuras a escala humana ha sido de mi interés. Hay algo llamado Ley de Conway, que trata sobre la relación entre comunicación y tecnología y la estructura de una organización, cómo se comunica, se correlaciona con la tecnología que una organización produce. Pero también, si puedes ajustar la columna vertebral digital de una organización, puedes cambiar cómo esa organización se comunica. Y eso es realmente interesante. Y más allá de una organización también, puede ser interorganizacional o internacional o lo que sea.

Entonces, cuando te enfrentas a estos problemas realmente a gran escala, a menudo, y estos problemas logísticos que surgen de gran escala, tienes que encontrar un conjunto de compensaciones que funcionen. Y mientras formaba parte de la primera ola de Node.js, con consultoría, me convertí en parte de la ola de microservicios desde el principio. Y se trataba de aprovechar la distribución de la tecnología para facilitar la complejidad logística de trabajar en un monolito. Y así pudimos hacerlo. Así que realmente se trataba de aprovechar la distribución de la tecnología para facilitar la complejidad logística de trabajar en un monolito. Y eso es un fenómeno muy interesante que se puede observar. Que cuando se hace de una manera que... porque no siempre funcionó cuando las organizaciones hicieron este tipo de cosas. Pero una de las razones por las que no siempre funcionó en ese contexto para que los efectos de comunicación tuvieran lugar basado en cómo la tecnología estaba cambiando eso. Y eso podría ser anulado por las partes interesadas y otros, arquitectos y todo tipo. Así que hubo muchas veces en que esto no... los resultados no se vieron. Pero pude verlo en ciertos casos donde se podían ver resultados al distribuir esencialmente tu computación. Así que dentro de todo eso, también he estado trabajando en open source desde... hace mucho tiempo, supongo que dos décadas, aproximadamente. Así que comencé un poco... haciendo un poco de trabajo en algunas tecnologías open source, tecnología peer, incluyendo algo llamado HyperSWARM, que vamos a cubrir hoy. Porque me pareció que... esta era una forma más eficiente de construir un sistema en general dentro de las organizaciones. Y luego, mientras hablaba en conferencias de diferentes cosas, vi una charla sobre árboles Merkle-Dagg. Y estos son... Oh, no árboles, lo siento. Los Merkle-Daggs son grafos, no son árboles. Esto tiene algo que ver con cómo funciona la cadena de bloques de Bitcoin. Pero fue fascinante. Y terminé charlando con el orador y entendiendo más al respecto y demás. Y esa persona resultó ser Matthias Booths, AKA Maffintosh, quien es el CEO de nuestra empresa, Holepunch. Así que... y prolífico autor de open source.

Y así comenzamos a trabajar juntos y avanzando rápidamente hasta ahora, y hemos estado trabajando en un stack peer to peer durante... Bueno, ha estado en proceso durante unos 15 años, pero al menos creo que los últimos cinco años o cuatro años, hemos estado trabajando en ello como Holepunch. Y Holepunch ahora se está convirtiendo en parte de Tether. Así que esta es la imagen completa. Así que voy a hablar hoy sobre la creación de aplicaciones pair. Y necesito definir qué es pair, o qué son los pairs. Así que hay un sitio web pairs.com. Y docs.pairs.com tiene todo lo que necesitas saber. Pero el punto clave es, con el stack de lanzamientos de aplicaciones embebidas peer to peer, no hay nube. Y si no hay nube, y es open source, no hay tarifas. Y si no hay tarifas, o si no hay nube, entonces no hay alfa. Porque el servidor no puede caer si no hay un servidor. Todo el punto del stack pair es conexiones directas peer to peer. Y hacer que eso funcione con la menor infraestructura posible, infraestructura casi nula. Y ese es el punto clave. Así que lo primero de lo que quería hablar es hacer que sea infraestructura casi nula. Y eso es lo que hemos estado haciendo. Hemos estado construyendo aplicaciones sobre esto durante un par de años ahora, y está funcionando muy bien. Más sobre eso a medida que avanzamos aquí, de hecho. Así que la primera aplicación que construimos sobre el stack pair fue Keet. De hecho, se construyó en paralelo. Así que en algunos casos, hay cosas que se están construyendo en Keet y se están abstrayendo. Y en otros casos, hay cosas que se construyeron desde el lado de la plataforma y luego han entrado. Así que es este enfoque constante de dogfooding y pruebas de batalla, enfoques peer to peer en una aplicación de producción en vivo. Ahora mismo, estamos obteniendo millones de descargas al mes, nuevos usuarios. Así que lo que pasa con Keet es que no hay servidores. Y porque no hay servidores, no tenemos un costo unitario por usuario tecnológicamente o en infraestructura. Telegram tiene un costo unitario por usuario, algo así como 60, 70 centavos por usuario. Así que cada vez que obtienen nuevos usuarios, tienen un costo anual que se suma. Y sus costos de infraestructura son alrededor de 600, 700 millones al año. Nuestros costos de infraestructura para Keet son casi cero. Digo casi cero porque depende de cómo definas infraestructura. Si incluyes CI y cosas diferentes como esa, entonces no es cero. Si incluyes lo que llamamos peers ciegos, que son peers que ayudan con la disponibilidad que ejecutamos, entonces estrictamente no es cero. Pero el costo de esto frente al costo de un enfoque centralizado, tradicional, es un error de redondeo. Podría ser cero. Así que Keet puede escalar al planeta. Podrías poner a 8 mil millones de personas en una sola sala, al menos algorítmicamente debajo. Podría haber problemas de UX, UI con eso. Pero sabemos que podemos escalar al planeta, no solo para mensajes, no solo para imágenes, no solo para videos, sino muy pronto para transmisiones de difusión. Actualmente, puedes tener alrededor de, bueno, puedes tener tantas personas como puedas caber en un video llamado Juntos en Keet. Así que no hay limitaciones aparte de las limitaciones físicas reales de ancho de banda y demás. Pero no hay compresión porque no hay servidor en el medio. Así que puedes tener la más alta calidad que puedas obtener. Y también puedes enviar terabytes de datos a otros peers. Podrías enviar un archivo de audio de un terabyte, dos terabytes, como archivos de sonido en bruto o videos o lo que sea. Y sin costos de nube, sin cargos adicionales por usar datos y todo ese tipo de cosas. Simplemente lo estás enviando de un dispositivo a otro. Y muchas veces, si manejas grandes cantidades de datos como ese, a menudo solo estás tratando de producir algo o estás tratando de enviar los datos a ti mismo. Así que la noción de tener que pagar a un tercero solo para enviar datos entre tus propios dispositivos es absolutamente absurda.

Y el hecho de que alguna vez permitimos que eso se convirtiera en el caso es una vergüenza para nuestra especie, en mi opinión. Si tienes Keet, si lo has descargado de Keet.io, puedes encontrarme en DMC0, agrégame, envíame un DM. También puedes unirte al grupo de desarrollo paired. Dejaré eso en la pantalla por un minuto. Déjame también dejar caer algunos PDFs en el grupo de desarrollo paired ahora mismo, y luego puedes escanear este código QR desde tu teléfono y unirte. Puedes obtener Keet para tu teléfono y para tu escritorio. También pondré este enlace de escritorio en el chat de Zoom. Solo cópialo y pégalo, no intentes hacer clic en él. Este es Keet justo aquí. Este es mi Keet real. Así que si deseas los PDFs para esto, puedes encontrarlos en la sala de desarrollo paired en Keet, que acabo de pegar en el chat aquí. Puedes copiarlo, y luego simplemente ponerlo en esta barra de búsqueda superior aquí así, y luego se unirá. Bien. Así que tenemos otro enlace. Solo voy a guardarlo. Así que tenemos otro enlace que voy a enviar aquí. Este es nuestro masterclass de hoy. Así que necesitas asegurarte de que tienes Node y NPM instalados porque usamos eso para instalar dependencias. Y una vez que lo tengas instalado, también puedes bootstrap pair con NPX pair. Entonces, chicos aquí, ¿ya tienen pair instalado? ¿Es la primera vez que se encuentran con pair? Háganmelo saber, porque entonces puedo averiguar cuánto tiempo esperar en este paso. Primera vez, bien. Entonces, ¿tienen Node y NPM instalados? Genial. Así que todo lo que necesitas ejecutar es NPX pair, y eso bootstrap el pair a tiempo en tu máquina. O la plataforma pair, más bien. Este es el código. Así es como funciona. Lo que hace es obtener la clave de producción de pair, que es un enlace pair, y luego usa HyperSwarm, que en realidad vamos a, oh, está en una dependencia más profunda, pero usa HyperSwarm para conectarse a esa clave y luego descargarla en tu disco, y luego hace algunas otras cosas aquí y allá, pero solo cosas de terminal. Puede tardar un poco, pero una vez que esté configurado, en este momento, aún necesitas configurar tu ruta. Si estás en Windows, Mac o Linux, esto es necesario, para que apunte a la carpeta bin correcta. Estás en Nix. Sí. Tenemos usuarios ejecutando pair en Nix, pero hay más que tienes que configurar. Hay algunas dependencias a nivel C que faltan. Sí, prueba Ubuntu. Eso estará bien. Así que si estás en Linux, solo agrega eso a tu bashRC o cualquier RC que estés usando. Va a dar un poco de tiempo para que eso baje. Así que mientras eso sucede, este es el stack pair. Solo vamos a estar viendo el módulo de tiempo de ejecución pair y un solo módulo hyper en esta sesión. Y en la sesión del miércoles, también veremos el CLI de pair y tal vez bear un poco también. Pero el tiempo de ejecución pair, el módulo, se puede agregar a cualquier aplicación de JavaScript, no en el navegador, pero como electron o lo que sea, o React Native. No, aún no React Native, pero eso está por venir. Se puede agregar a cualquier aplicación de JavaScript y proporcionar actualizaciones por aire peer-to-peer en Windows, Mac y Linux, y próximamente también en iOS y Android, lo que significa que no tienes que pasar por las tiendas de aplicaciones para actualizar. Y tampoco tienes que pasar por ningún servicio central para actualizar, solo desde tu propio enlace pair. La interfaz de línea de comandos es para desplegar aplicaciones pair. Nuevamente, cubriremos eso más el miércoles. Muy pronto también podrás instalar aplicaciones pair con ella. Eso saldrá muy al final de este mes. Bear es un tiempo de ejecución de JavaScript similar a node que se puede incrustar en móviles, y no tiene biblioteca estándar, ni siquiera un objeto de proceso, ni siquiera un módulo módulo. Así que con bear, solo instalas con MPM los módulos que necesitas, como bear-fs.

Alguien más puede unirse al mismo tema, le das ese tema. Y luego puedes conectarte como pares porque ambos se han descubierto a través del DHT con el mismo tema. Entonces, el DHT es una tabla hash distribuida. Es un grupo de pares que mantienen estados o no mantienen estado. Bueno, es estado, pero es un estado de descubribilidad. Está basado en la misma forma en que funciona BitTorrent, usando un algoritmo de próxima generación llamado Connect. Así que esto es realmente todo lo que necesitas para que dos pares se comuniquen entre sí. HyperSWARM. Y eso es todo lo que vamos a usar en este ejercicio. Entonces, la arquitectura de la aplicación que está actualmente en el boilerplate que hemos clonado es un tipo híbrido de HyperSWARM. La arquitectura en el boilerplate que hemos clonado es que por cada aplicación Electron, generalmente tienes una pieza de renderer. Tienes una pieza de preload, que también se ejecuta en el renderer, pero justo antes de todo lo demás. Luego tienes Electron main, que se ejecuta en el hilo principal de Electron. Y luego lo que tenemos aquí arriba con nuestra arquitectura es Workers main, que es un proceso bare. Así que está ejecutando el runtime de JavaScript bare como un proceso. Y hablas con eso a través de un solo pipe IPC.

Así que el Worker es realmente lo que está hablando sobre el HyperSWARM con el par remoto, con el Worker de los otros pares. Y está ejecutando todas las instancias de la aplicación de chat, ¿verdad? Y los Workers enviando mensajes, recibiendo mensajes de vuelta, y luego escribiéndolos de vuelta sobre Electron main a través del puente de contexto preload y luego en el renderer. Así que el flujo de datos es... Entonces, lo que necesitamos hacer es instalar algunas dependencias, que son para la biblioteca Java y B4A, que es para la manipulación de buffers, simplemente manipulación de buffers estandarizada en todo, navegadores, bla, bla, bla. Tiene que ver con el hecho de que los buffers de node y los buffers de array nativos en procesos de renderer son obviamente diferentes. Suaviza esas diferencias sin que sea una lucha convertir entre ellos todo el tiempo. Así que, bien, tenemos una solicitud interesante de Dominik. Tomemos un momento para hacer eso. Solo lo miraré. Dom, ¿quieres hablar sobre esto un segundo, solo para que podamos hacerlo interesante? Oh, es bastante simple. Es solo el framework reframed streams que nos ayuda a asegurar que el streaming funcione correctamente en las mismas plataformas RESTful. Y en la última actualización de Pair, ahora hay un frame stream siendo usado en ambos extremos del worker. Correcto, sí. Esto es una cuestión de alineación. Pero la misma arquitectura se mantiene de la que estábamos hablando. Esto es básicamente una solución alrededor de la conexión entre... Vamos, ¿dónde estás? La conexión entre el worker y Electron main en el... ¿Qué lado es este? Este es el lado del worker. Porque había... Estamos constantemente alineando todo con nuestros últimos enfoques. Y el boilerplate fue actualizado para usar un módulo llamado frame stream, que debería haber estado en primer lugar, en realidad. Así que eso solo asegura que cuando envías los datos por el pipe, que esté correctamente fragmentado basado en el fragmento real que enviaste al otro lado. Porque lo que puede pasar cuando tienes dos streams hablando sobre una conexión entre sí? ¿Qué puede pasar cuando tienes dos streams hablando sobre una conexión entre sí? Puedes escribir algunos datos, pero en el otro lado, no hay garantía de que esos datos se emitan como una sola pieza. Podría fragmentarse aún más, dependiendo del tamaño. Pero si usas frame stream, entonces te dice exactamente dónde comienza y termina un fragmento. Así que todavía podrías tener múltiples fragmentos que se emiten, como, más profundamente. Pero lo que el stream actual emite es el marco completo.

Genial. Gracias. Vamos a incluir eso. Y esas son contribuciones de código abierto en la vida real. Genial. Gracias, Dom. Bien, he instalado las dependencias, y ahora voy a copiar esto en el recién arreglado en workers main.js. ¿Dónde estoy? Espera. Lo siento. Entonces, workers main.js. Voy a sacar esto y simplemente pegarlo encima. Así que esto está funcionando en Bear. Se parece mucho a Node, porque es muy similar a Node. Más profundamente, Hyperswarm está usando algo llamado import maps. Para soportar tanto Node como Bear, te lo mostraré rápidamente. Como ves, Hyperswarm está usando el módulo de eventos y el módulo de procesos. Y los mapea a través de ellos. Así que en Bear, está cargando un módulo llamado bear-events. Pero en Node, cargará events y lo mismo para process. Y tenemos una instancia de un swarm. Y luego, cuando el swarm obtiene una conexión de par, escuchamos datos en ese par. Y luego simplemente enviamos eso a través de esta función send, que lo escribe en el pipe. El otro extremo de ese pipe está en el hilo principal de electron. Lo mismo para update. Y cuando el pipe recibe datos, tiene una especie de interfaz de comando. Para create, se une al swarm con bytes aleatorios. Para join, se une al swarm con un tema que se le ha dado. Así que bytes aleatorios es básicamente crear un tema. Y para message, recorre todos los pares a los que está conectado, esas conexiones de swarm, y luego escribe el mensaje a cada par. Esto va a ser solo para chat. Así que eso es prácticamente toda la lógica peer-to-peer que necesitas para hacer una aplicación de chat completamente desarrollada.

Aquí está el HTML. Voy a poner eso en renderer.html. Lo siento, renderer.index.html. Es muy simple. Es solo un botón de Create, un botón de Join con un cuadro de texto, peer count, room topic que está en una especie de vista separada. Así que tenemos esta vista de configuración. Esa será la primera. Una vez que pases por eso, entonces está la vista de chat. Que tiene un div de mensajes y luego un formulario de entrada para cada mensaje. Y luego renderer app.js es muy simple de nuevo. Estamos usando text decoder y text encoder. Estamos usando text decoder y text encoder. Pero está funcionando. Esto va a estar trabajando con el lado de preload. Así que este puente es cómo el… Sigue con context bridge y preload.js. Pero no veo preload.js.

Creo que preload.js falta. Dom, ¿ya miraste esto? Oh, no, lo siento. Preload ya está ahí debido al boilerplate. Sí, exactamente. Renderer app.js. Así que el boilerplate viene con un context bridge configurado para ti en preload. Electron preload. No del todo correcto. Y eso expone window.bridge. Y luego tienes estas funciones que esencialmente solo envían los datos por el cable nuevamente. Y la app está llamando a start worker. Luego preload toma eso, dice start worker aquí, invocándolo en IPC renderer de una manera diferente. IPC renderer en Electron. Así que eso está llegando en Electron main. Y luego Electron main realmente genera el worker, obtiene el pipe, y luego escucha los datos, los procesa, y escribe apply update. Si es apply update en start worker, es solo get worker, que lo inicia. Bien. Así que ahora podemos revisar nuestra app, ver si eso está funcionando. No, no lo está. ¿Qué nos falta? Es bastante raro. Oh, ah, no es porque ya lo estoy ejecutando. Ese es el problema. Aquí ya está. Así que necesito detener ese. Comenzar de nuevo. Ahí vamos. Genial. Así que voy a crear un chat. Y voy a poner ese tema en el chat de Zoom. Oh. Y cuando estés, cuando, ¿quién es este? ¿Quién acaba de decir hola? Bien hecho. Bien hecho. Dom, vas a unirte al chat. Así que esto ahora es un chat peer-to-peer. Lo hemos iniciado desde un chat centralizado. Y ahí está Dom también. Así que ahora tenemos tres peers que pueden ver que pueden enviarse mensajes entre sí. Tan pronto como cierras la app, esos mensajes se pierden porque solo se mantienen en RAM, por supuesto. No tenemos ninguna persistencia. Otras partes del HyperStack serían para persistencia. HyperCore es para persistencia, en última instancia. Y luego, además de eso, tienes cosas como HyperB, HyperDB, HyperDrive, y uno que no se llama Hyper pero es parte del HyperStack, que es Autobase. Y eso es capacidad de multi-escritor. Así que lo que Keet usa para, Keet básicamente funciona exactamente así en términos de conexiones peer-to-peer y mensajes que se envían a través de esas conexiones peer-to-peer usando HyperSWARM. Pero lo que también tiene es una estructura de datos de multi-escritor en la que se escriben esos mensajes. Y luego esa estructura de datos se comparte entre todos los peers dentro del mismo grupo de Keet. Y de esa manera, tienes persistencia. Esa es una tarea mucho más grande que la parte inicial de conexión. Esta parte inicial de conexión es extremadamente trivial. Hay muchas cosas que puedes hacer con esto, obviamente.

Vi que un peer se desconectó. ¿Quién fue el que se desconectó? Fui yo. Bien. Entonces vimos... Oh, bien. Sí, eso es correcto. Usas una ruta de almacenamiento diferente. Sí, puedes... Eso es fantástico. Lo descubriste. Porque ahora sabes, si usas dash-dash storage cuando haces NPM start, entonces puedes ejecutar dos instancias de la misma app. No es solo en Windows, es en todas las plataformas. Y eso es por diseño. Porque entonces puedes... Yo también puedo dejar esto. Y luego aún puedes hablar contigo mismo a través de una conexión peer-to-peer. Así que es genial para pruebas locales y verificación local de aplicaciones mientras las construyes para ejecutar una segunda instancia con su propio almacenamiento personalizado. Así es exactamente como lo hacemos. Oh, ya veo. Ya veo. Sí, supongo que será diferente... Sí, lo arreglaremos. Encantador. Bien, entonces... Desde aquí, iba a hacer un poco de recorrido, una especie de tour, realmente, de Snake. Así que tenemos otro repo. Puedes llegar a él desde... Oh, espera, no, lo siento. Hay otro ejercicio. Oh, no, también hicimos eso. Acabamos de hacer ese otro. El otro ejercicio es exactamente lo que hicimos, unirnos al chat. Ahora, vamos a Snake. Haz clic en ese enlace. Lo pondré aquí también. Ahí lo tienes. Así que esto, con suerte, va a funcionar. Jaja. Porque lo alineé recientemente también. Podría haber cometido el mismo error. Tal vez Dom pueda salvarme de nuevo. Esto está basado en el mismo boilerplate, usando la misma arquitectura, el mismo enfoque. Y... puedes ver muchos de los mismos elementos aquí. Volveremos a esto el miércoles, pero aquí mismo, también está configurando la biblioteca de tiempo de ejecución de Pair, y luego escuchando los eventos de actualización. Y luego, en última instancia, se puede actualizar por aire con esa configuración. Pero nos estamos enfocando principalmente en construir realmente la aplicación ahora mismo. Es solo que esto tiene todo. Pero puedes ver unirse al juego, que es muy similar a unirse al chat grupal. Está el CryptoRandomBytes siendo usado para el buffer de tema.

Así que eso es crear y unirse, realmente. Y luego en el proceso del renderer, verás un HTML muy, muy similar. Pantalla de configuración con crear juego, una especie de crear chat. Y luego el juego en sí, que está construido con un elemento personalizado en lugar de React. Así que se ve así. Los elementos personalizados son nativos de WebViews, y Electron usa WebViews. En mi opinión, no soy una autoridad en React ni nada por el estilo. Pero en mi opinión, en términos de componentización, en React, si un componente tiene estado, particularmente con estado desde un punto de vista de reflexión de interfaz, como en la UI depende mucho del estado interno del componente, entonces en mi opinión, podría tener más sentido hacerlos como elementos personalizados y luego mantener React para componentes sin estado. Y entonces creo que terminas con lo mejor de ambos mundos. Pero de todos modos, ¿dónde estás? Sí, los elementos personalizados definen PerSnake, y luego le das una clase. Aquí está la clase del juego. Y está haciendo más o menos el mismo tipo de cosas como enviar y recibir mensajes. Es solo que cuando la tecla está presionada, está cambiando el estado. Y hay una función de tick. Cada tick se llama una y otra vez, cada tick, sincroniza ese estado con otros jugadores. Aquí vamos, sincronizar. Eso se envía al trabajador, el ID, la comida, la serpiente, y si el jugador se ha caído, la serpiente en sí, dónde está la comida. Y eso se envía. Así que vamos a intentarlo. Así que estoy clonando snake. Estoy instalando dependencias. Estoy ejecutando npm start. Con suerte, eso es todo lo que necesito hacer. Genial, así que lo que puedo hacer es si todavía estás aquí, sí, ¿qué es esto? Oh, ¿es este un juego de snake? ¿Ya tienes eso? Sí, bien, vamos. Encantador. Oh, tienes la ventaja del primer movimiento. Oh, ese ya tiene que arreglarse desde frame stream. Sí, agradable. Puedes unirte de nuevo, tienes que salir de la app y luego iniciarla de nuevo si quieres unirte de nuevo. Lo pondremos en Pear Dev también en caso de que alguien quiera involucrarse. ¿Otro juego entonces? Vamos de nuevo, vamos de nuevo. Sí. Lo siento, te estoy eliminando inmediatamente. No sé quién fue. Sí, lo que hemos construido aquí es el juego de snake con una app de chat complementaria. Usando esencialmente código mayormente copiado y pegado. Sí, lo realmente genial es, porque en el momento en que quitas el backend, ves exactamente que puedes comenzar con muy poco boilerplate, comenzar a armar apps que deberían tomar equipos enteros para hacer, pero en cambio no lo hacen porque no hay nada que hacer. Sí. Y solo se convierte en... También significa que puedes enfocarte como... Teóricamente significa que puedes enfocar una organización mucho más en la UI y la UX, porque no tienes que poner todo ese esfuerzo extra y dinero y coordinación y recursos en la infraestructura y no necesitas equipos enteros alrededor de una base de datos, por ejemplo. Exactamente. Bien, dejaré eso encendido en caso de que alguien entre, pero oh, uno más entonces. Ahora soy un poco un monstruo. Hemos tenido... Hemos tenido intentos en esto donde hemos tenido tal vez siete u ocho personas jugando. No hay restricción en la cantidad de peers que podrían... Oh, mierda. Ja ja ja.

It's true. Because peer dependency is a problem. I'm very much a Bear takes over the world and everyone else goes away. Yeah, sure, sure. I understand that. But you got to meet people where they're at. Yeah. I think at one point I did have one that... To be fair, I don't know if it's installed... No, actually, no, I removed it. I was going to have both versions installed, ultimately. But some of the stuff we do is just a bit too cool.Yeah, yeah, yeah, creative, but there's an edge to it. GIT stands for Git, Get Into Pear. Or Git Into Pear, sorry. Either one. Exactly. What other apps? Anything else you want to talk about? We have a thriving community in the Pear Dev Group as well, if you want to get involved in that. Lots of people building lots of things in lots of different ways, actually. But it's really cool to see a community coming up around this and very inspirational engagement from a lot of very smart people, very bright people.So we're excited about this technology. We're excited about where it can go. And it's essentially unstoppable. It's unstoppable, like you can't stop it. So if you do the math, the technology is unstoppable. It can connect to hole punchers through various things. And there's no infrastructure costs. And it gives you a way to monetize without data exploitation. The thing with data exploitation scale is it does generate a lot of revenue, but it also costs a lot of OPEX operational expenses because of the infrastructure costs and associated. So if you get rid of one side, you can get rid of the other side and you can build things that are actually products rather than subscription services for productizing users.Let's get back to building products that just work, that just do the thing the users want them to do. And then we can all live in a better world. Okay, well, thank you for joining. And I hope you found this informative and hopefully inspirational. Hopefully see you out there in the Pear Dev Room. And feel free to DM me, DMC0 on key. DM me your projects. DM me. We are hiring. You can check out careers.tether.com and holepunch.recrui.com for positions. Thank you very much.

React Summit

React Summit 2026

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

Sin Servidores, Sin Nube, Sin Amos: Crea Apps P2P con Pear

React Summit US

React Summit US 2026

Mikhail introduce una masterclass sobre aplicaciones peer-to-peer con un enfoque en la funcionalidad en tiempo real y discute el impacto de la comunicación y la tecnología en la estructura organizativa. Explorando desafíos de problemas a gran escala, la participación en código abierto y tecnologías avanzadas peer como el ecosistema de módulos Hyper. Utilizando la tecnología Pair para el desarrollo rápido y discutiendo las capacidades versátiles de la tecnología Pair. Configurando la configuración del proyecto e implementando la arquitectura HyperSWARM para la comunicación peer-to-peer en aplicaciones Electron. Configurando la comunicación peer-to-peer y múltiples instancias de aplicaciones, junto con el uso de elementos personalizados para el desarrollo rápido. Discutiendo la integración eficiente de Git peer-to-peer sin la necesidad de servidores centralizados y prácticas éticas de monetización.

Todo lo que se necesita es un módulo y una herramienta CLI para construir y desplegar aplicaciones peer-to-peer de producción.En esta masterclass:<ul><li>Convierte una aplicación existente de React para que ya no necesite un servidor para desplegar</li><li>Prepara la aplicación y configura el flujo de despliegue para el lanzamiento de producción</li><li>Pasa a producción con multisig - lanzamientos descentralizados basados en quórum criptográfico</li></ul>Esto es para cualquiera que construya con React o JavaScript y cualquiera que despliegue aplicaciones.

David Mark Clements

Mikkel Malmberg

React Advanced

React Advanced 2026

JSNation US

I’m attending the main #JavaScript conference in the US. Join me and 10k other JS engineers. Follow this link to receive a free remote ticket. The theme of the year is AI for coding and the future of #WebDev.

#JSNation

JSNation US 2026

TechLead Conference

I'm attending TechLead Conference 2025 – get your free remote ticket and join me there

TechLead Conf London 2026: Adopting AI in Orgs Edition

AI Coding Summit

I'm attending AI Coding Summit with 5k other participants to learn how AI transforms software development and stay up to date with the latest AI tools - get your free remote ticket and join me there!

AI Coding Summit NYC

React Day Berlin

React Day Berlin 2026

AI Coding Summit Berlin

React Summit Asia

I am attending the largest #ReactJS conference remotely. You may get a limited free ticket (50% of talks, no workshops) and join me by clicking this badge.

#react #reactjs

Sin Servidores, Sin Nube, Sin Amos: Crea Apps P2P con Pear

Comments

Available in other languages: