Hola, bienvenido a la implementación de aplicaciones pair. En la última sesión, hablamos sobre hacer aplicaciones con pair, es decir, hacer aplicaciones peer-to-peer. En esta sesión, estamos hablando sobre implementar aplicaciones peer-to-peer, peer-to-peer, como en por aire, actualizaciones peer-to-peer de un par a otro para que no se necesiten servidores para hacer implementaciones de producción a gran escala. Pairs es una pila de lanzamientos de aplicaciones embebidas peer-to-peer. No hay nube, no hay tarifas, no hay interrupciones, porque todo es punto a punto. Hemos construido una aplicación peer-to-peer llamada Keet que está sobre nuestra pila, que llamamos la pila pair. Puedes encontrarme en Keet en dmc0. También tenemos un grupo de desarrolladores al que puedes unirte obteniendo Keet en tu teléfono y escaneando ese código QR. Pegaré este enlace en el chat ahora, si quieres unirte copiando y pegando este enlace. La pila pair consiste en el módulo, el módulo para actualizaciones por aire llamado runtime de pair, y luego pair el CLI, la interfaz de línea de comandos. También tenemos un runtime de JavaScript que es para uso embebido, como en móviles, realmente como IOT embebido, pero también embebido en cualquier otra aplicación de JavaScript. El módulo runtime de pair tiene un método run que luego ejecutará un trabajador, un trabajador bear especial. No cualquier otro tipo de trabajador con una conexión sobre IPC a él. Tenemos el ecosistema de módulos bear, que son todas las capacidades nativas. La otra cosa sobre bear es que no hay biblioteca estándar en absoluto. No hay dependencias centrales. Así que todo viene a través de instalación. Así que no hay razón para que un proceso tenga acceso al sistema de archivos si no necesitas acceso al sistema de archivos, por ejemplo. Así que no hay módulo FS central. Solo hay un módulo FS bear que instalas. Y luego está el ecosistema de módulos hyper y auto, que te da las capacidades P2P. Y cubrimos algo de eso en la sesión anterior. En esta sesión, nos vamos a enfocar realmente en la interfaz de línea de comandos como una herramienta de implementación. Echemos un vistazo rápido al runtime de pair. Así que básicamente creas una instancia de pair. Tienes un actualizador al que escuchas para actualizar y eventos actualizados. Aplicas las actualizaciones cuando tienes un evento actualizado, o puedes poner un botón y luego cuando el usuario hace clic en eso, aplica la actualización. Depende de ti. Y hay un método run, como dije, que inicia un proceso o hilo de trabajador bear en móviles. Y luego puedes tener un backend compartido, un backend local que puede funcionar en escritorio y móvil, esencialmente, usando esta arquitectura.

Así que en el masterclass anterior, hicimos una aplicación de chat, y luego mostramos cómo esa aplicación de chat podría usarse para hacer un juego de snake. Y aquí está el juego de snake. Vamos a implementar un snake peer to peer para mostrar el flujo. Hay un flujo de implementación completo, completamente documentado, el hello pair electron boilerplate readme. Esto podría moverse en algún momento, pero ahora mismo, aquí es donde está. Siempre redirigiremos desde aquí. Pero esto realmente entra en detalle, si quieres profundizar aún más en ello. Solo vamos a pasar por encima y mostrar el flujo para hacer esto. Así que entremos en los ejercicios. Voy a pegar esto en el chat. Así que si quieres trabajar junto con, encuentra el masterclass. Ya lo tengo aquí. Y luego estamos usando el…estamos en la parte dos implementando de este masterclass en particular, comenzando en implementar cero uno pair touch. Comenzando en implementar cero uno pair touch. Así que la forma en que funciona el pair es que básicamente posee un montón de hyperdrives. Un hyperdrive es una estructura de sistema de archivos que está construida sobre un hypercore. Un hypercore es una estructura de datos peer to peer para replicación. El juego de snake usa hyper swarm. Y eso es para conectar pares entre sí sobre una tabla hash distribuida por tema. Y generalmente, replicarías un hypercore o hyperdrive sobre hyper swarm. Todo eso para decir, todo está representado por lo que llamamos un pair link, que es un enlace que comienza con el protocolo pair y luego tiene una clave. Esa clave es lo que la aplicación, cuando está usando el módulo runtime de pair, descubre tu aplicación sobre el DHT, peer to peer con. Así que lo primero que tenemos que hacer es crear uno de estos pair links. Y luego lo que haremos es escribir datos en él. Y cuando estamos usando pair stage, cuando asumimos…de lo que hablaremos más tarde.

Pero cuando hacemos eso, lo que esencialmente está haciendo es escribir datos en ese hyperdrive, que se mantiene en un hypercore y luego más tarde el hypercore se replica sobre pares. Y eso es lo que entrará en tu aplicación y te informará que hay un evento actualizado para que puedas aplicar esa actualización para tu aplicación. Así que lo primero que necesitamos es obtener snake. Así que vamos a hacer un git clone. Así que, solo voy a poner eso en el chat también. Y luego podemos instalar pair con mpx pair. Para mí, esto va a hacer eso en su lugar. Eso significa que ya lo tengo instalado. Una vez que esté instalado, pair v dash v. Deberías ver algo como esto. Una vez que tengas pair instalado, simplemente crea tu enlace con pair touch. Y eso genera un enlace para mí. Ahora, para configurar la implementación, lo que realmente necesitamos hacer, lo más importante que tenemos que hacer aquí es decirle a la biblioteca runtime de pair qué enlace de pair usar para encontrar tu aplicación hyperdrive sobre la tabla hash distribuida de otros pares. Y hacemos eso configurando el campo upgrade como package json. Así que, en snake, voy a ir al package json, configurar el campo upgrade, que está en la parte inferior aquí, para que al enlace que he creado. Así que el campo upgrade se ha configurado a ese nuevo enlace. Y eso es ahora mi enlace de staging. Así que una vez que tenemos el enlace, necesitamos hacer algunas distribuciones de la aplicación. Así que voy a ejecutar npm install aquí, obtener las dependencias. Y luego cuando hacemos las distribuciones, el enfoque sería hacer las distribuciones. El enfoque sería ejecutar make en tu máquina Windows, en tu máquina Linux, en tu Mac. Si tienes Intel o ARM64, querrás uno de cada uno, idealmente para cada uno. Y luego los pones todos en una máquina, que puedes simplemente, hay muchas herramientas para hacer eso. Pero podrías enviarlos a través de Keete, por ejemplo. O podrías realmente pair stage y volcarlos entre máquinas. Pero no es un ejercicio para hoy. Y luego los ensamblas en una sola carpeta de implementación usando pair build. Y luego esa carpeta de implementación es lo que se sincroniza en un hyper drive a través de pair stage. Y eso luego se expone sobre el DHT a través de pair seed. Y luego cuando das a los usuarios tu distribuible, como en mi aplicación o lo que sea, lo abren y luego el campo upgrade es verificado por el módulo runtime de pair time y se conecta a él.

Y luego verifica si hay actualizaciones. Y así es como conectamos todo esto juntos. Pero lo que vamos a hacer es crear un distribuible en nuestra máquina solo para ver todo el flujo. Pero a partir de eso, puedes ver cómo hacer una distribución completa multi-sistema operativo, multi-arquitectura para la implementación. Así que ahora que los pasos han sido almacenados, voy a npm run make. Para compartir un distribuible con alguien en otra máquina, si estás en Mac o Windows, necesitas una clave de inicio de sesión o necesitas auto-firmar. Ese es nuestro alcance para esto. Así que solo vamos a ejecutar en nuestras propias máquinas por ahora. Si estás en Linux, puedes fácilmente probarlo en otra caja Linux para ver el flujo completo de actualización entre diferentes máquinas, diferentes redes, lo que quieras probar. Pero créenos. Funciona entre pares. Así que ahora que el make ha completado, vamos a usar el comando pair build. Puedes ejecutar pair build dash h para ver la salida de ayuda. Es un comando muy, muy sencillo. Lo que hace es esperar un montón de estas diferentes banderas, y luego cada una de ellas debería apuntar a las compilaciones para ese sistema operativo y arquitectura en particular. Y luego lo apuntas al package.json del proyecto que tiene el campo upgrade. Y luego le das una bandera de destino opcional para que sepa dónde ponerlo. Así que solo vamos a hacer Darwin arm 64 porque es lo que estoy ejecutando. Pero si estás en Linux, tendrías Linux x64, etcétera. Y luego win32. Está usando la misma convención que process platform en node.

Entonces, lo que hace pair build es crear esta carpeta llamada byarc, y coloca el package.json en el nivel superior al lado de ella. Y luego, dentro de la carpeta byarc app, están todos los diferentes directorios para todas las diferentes combinaciones de sistema operativo y arquitectura. Así que en nuestro caso, será byarc, o en este caso, será byarc app Darwin arm 64. Así que debería tener las compilaciones en ls out. Sí. Lo único que necesita ser corregido allí es que debería ser snake, no chat. Eso es de antes. Así que vamos a ejecutar pair build Darwin arm 64 app flag, la ruta a la aplicación snake que acabamos de construir con npm run make, y luego el package.json que está en este repositorio actual. Y luego, decir, ponerlo en dot out dot forward slash out forward slash build. Sí. Así que ahora tenemos una carpeta byarc y un package.json, y la carpeta byarc tiene una aplicación. Oh, lo siento, al revés. Ese es mi error. Siempre hago eso. La carpeta de la aplicación está dentro de la carpeta byarc. Y ahí está snake.app. Ábrelo para ver qué está pasando. Esa es una mala idea. Dom, si tienes alguna idea sobre eso. Ahora puedes vernos depurar esto en vivo. Sí. Así que funciona bien para mí. ¿Estás haciendo pair build? No, no lo creo. Tal vez. No lo hice correr localmente, así que solo voy a, sí, no, mismo problema. ¿No estás viendo eso? No puedo llegar a esa parte porque estoy usando una versión diferente de fair en este momento, pero parece que las cosas nuevas de sidecar pueden ser un problema. Vamos a verificar. No, está todo ahí. Rebuild arm 64. ¿Así que no puedes reproducirlo o sí puedes? No, no puedo llegar tan lejos.

Puedo ejecutarlo bien con npm start en este momento, pero no puedo obtener eso. Sí, npm start está bien. Va a ser una versión incompleta. Esto es producción, así que debería funcionar con eso. De hecho, puedo hacerlo en un segundo. Sí, estoy obteniendo lo mismo. Bien, hagamos la aplicación de chat en su lugar. Con suerte, eso funcionará. Esa es simplemente demasiado larga para depurar. Así que parece que también vamos a hacer lo de crear. Así que, bien, vamos a empezar. Así que lo que estoy haciendo es que voy a hacer esto desde cero en lugar de la aplicación Snake. Haremos una aplicación de chat desde cero y luego la desplegaremos muy rápidamente. De hecho, ni siquiera necesita ser la aplicación de chat. Puede ser simplemente la clave de actualización que ya creé con PairTouch. Voy a usar eso para esto. Así que, hagámoslo. Voy a hacerlo de nuevo. Genial. Así que, creo que esto funcionará. Así que, lo que voy a hacer es que voy a desplegar esto. Voy a desplegar esto. Así que, hagámoslo. Así que, de nuevo, voy a hacerlo desde cero. Ni siquiera necesita ser la aplicación de chat. Puede ser simplemente la clave de actualización que ya creé con PairTouch. Voy a usar eso para esto en su lugar. O, no puedo encontrarlo, así que crearé uno nuevo. Esto es en realidad una mejor demostración porque tenemos la versionado. Así que, lo que hice allí fue clonar Hello Pair Electron, y luego simplemente configuré el nombre y el nombre del producto a chat y configuré el campo de actualización a nuestro enlace de PairTouch.

Así que, ahora podemos volver a hacer. De alguna manera, es bueno porque lo estamos viendo ejecutarse varias veces, así que queremos hacer. Así que, hagámoslo. Ahora podemos avanzar. Así que, mismo proceso, pero tienes que tener una aplicación que funcione para que esto funcione. Así que, en realidad es chat. Oh, genial, lo tengo funcionando. Oh, ¿tienes Snake funcionando, verdad? Sí, después de hacer, puedes simplemente ejecutar esto en este momento. Parece que no está trayendo el R64. Oh, está preconstruido, pero problema. Sí. Bien. Buen arreglo. Nos quedaremos con el tema del chat por ahora porque realmente no se trata de Snake. Se trata de actualizar una aplicación peer-to-peer por aire. Así que... El comando de build. Le damos una bandera para el sistema operativo y la arquitectura, una bandera para el sistema operativo y la arquitectura, lo apuntamos a la aplicación, lo apuntamos al package.json, le damos un objetivo. Así que, eso debería ser ahora un outbuild. Sí, tenemos el BIARC, y luego tenemos DarwinR64 dentro de eso, y luego app, y luego la aplicación real. En última instancia, lo que quieres es una carpeta BIARC con todos tus sistemas operativos y arquitecturas, y eso es lo real, esa es la unidad de despliegue que se siembra peer-to-peer. Así que, pasemos a Pear Stage. Así que, lo que hace Pear Stage es que sincroniza desde el disco a un hyperdrive que está dentro de Pear, y luego puedes sembrar eso. Pero antes de ejecutarlo, quieres hacer una ejecución en seco.

Aquí es cómo obtienes la ayuda, pear-stage.h. La ejecución en seco solo ejecuta la etapa sin escribir. La razón por la que queremos hacer eso es para que podamos ver la diferencia. Como práctica general, quieres saber qué se va a escribir antes de que se escriba, ¿verdad? Así que, puedo obtener el enlace así de fácilmente. Así que, ese es el enlace que estamos usando, y quiero decir, pear-stage dry run my link, y luego out build como el directorio, ¿verdad? Es pear-stage link allí. Vemos con la diferencia, esto es lo que se va a sincronizar en nuestro hyperdrive. Así es como se ve una aplicación Electron, más o menos. Así que, contento con eso. Voy a ejecutarlo de nuevo sin la bandera de ejecución en seco. Y puedes ver que tenemos un... diferencia, todos los tamaños y demás, cuál es la longitud más reciente, y aquí no es tan visible, pero aquí hay un enlace versionado. Vamos a usar eso más tarde cuando hagamos pair provision. Un enlace versionado dice, esta es la longitud del drive que me interesa. Y el cero es si está bifurcado. Así que, uno sería si está truncado una vez. Así que, ahora que lo hemos preparado, solo necesitamos exponerlo, y hacemos eso con seed. Así que, digo, pear-seed, mismo enlace de nuevo, y ahora estoy viendo, y ahora estoy sembrando. No hay pares ni nada todavía. Lo pasaré. No podrás necesariamente ejecutar esto, pero puedo pasarlo en el chat aquí, y Dom, puedes generar algo de actividad si quieres, si lo descargas o algo así. No podrás ejecutarlo porque necesita estar firmado por el proveedor, por supuesto, esto es Mac.

Pero ahora puedo ejecutar y actualizar, hacer una actualización y observar el flujo de actualización. Ahí vamos. Ahí está Dom. Y él está, ¿qué hiciste, Dom? ¿Lo hiciste? Sí. Sí, él ejecutó pair dump y luego pasó ese enlace y luego básicamente está tomando, va a obtener el enlace, y luego va a ejecutar un pair dump, y luego va a obtener el enlace. Y luego va a generar un enlace. Luego pair dump y luego pasa ese enlace. Y luego básicamente está tomando todo mi, o todo lo que fue preparado en ese diff, él está obteniendo eso ahora en su sistema de archivos desde el mismo drive como un peer. Pero si alguien estaba ejecutando una aplicación, porque nuestra aplicación tiene este enlace como el campo de actualización, entonces ellos se unirían como peers también, y luego podrían hacer descargas y demás. Verías todo eso sucediendo. Así que lo que voy a hacer es, voy a simplemente decir crear chat, como crear juego, pero voy a hacer una pequeña actualización. En realidad, no necesito hacer eso porque la forma en que funciona el boilerplate por defecto de Hello, Power Electron, es que muestra la versión. Vamos a tener que aumentar la versión de todos modos, así que realmente no necesitamos aplicar ninguna actualización aparte de eso. Así que voy a omitir ese paso para esto. Así que para implementar la actualización, lo que haces es asegurarte de que la aplicación esté sembrada, aumentas la versión de packageJSON, haces los distribuibles de nuevo, reconstruyes la carpeta de implementación, y luego la preparas de nuevo. Y luego deberías ver que llega una actualización. Así que voy a aumentar la versión. No sé si necesito esa primera cosa. Así que npm version. Oh sí, por eso lo necesito, ¿verdad? Así que npm version patch. Y luego make de nuevo, y luego build de nuevo. Y luego deberíamos tener un outbuild. El packageJSON dice 0.01, así que ahora sabemos que eso está actualizado. Así que luego simplemente preparamos de nuevo. Debería haber hecho un dry run primero, pero podemos ver por el diff que el packageJSON fue actualizado y el appx manifest fue actualizado. Eso es parte de las cosas de Forge que están actualizando otras piezas. Así que todo lo que necesitaba ser actualizado fue actualizado con ese cambio de versión. Y la longitud ha aumentado. Así que tenemos, antes era 1, 2, 6, 3, y luego después es 1, 2, 7, 3. Así que ha aumentado en 10.

Depende de la cantidad de escrituras. Así que si estoy ejecutando la aplicación, donde sea que esté, déjame ver. Necesito instalarla. No, no solo necesito ejecutarla. Así que si abro, abro este chat aquí, esto debería ser la versión 0.00, ¿verdad? Pero está escuchando este enlace sembrado que tenemos aquí. Así que, lo he hecho al revés. Debería haber estado ejecutando antes, ejecutando stage. Eventualmente se actualizará, pero tarda más cuando lo haces de esta manera. Así que voy a intentar aumentarlo de nuevo. Está bien. Siempre podemos pasar por el flujo de nuevo. Así que es versión, make, pair build, pair stage. Esta vez voy a hacer un dry run por higiene. Sí, está bien. Y ahora, sin el dry run, funcionará. Huh. Dom, ¿alguna idea? Pensé que eso funcionaría. De nuevo, ¿qué has cambiado? Hice una actualización. Sí. Está bien. Pero eso es porque... Sí, creo que tal vez no debería haberlo ejecutado desde el outfold. Debería haberlo puesto en otro lugar y luego ejecutarlo. Sí. Vamos a intentarlo una vez más. Lo que voy a hacer es, tenemos este otro comando llamado pair install, pero no está completamente... Saldrá a finales de junio, pero puedes previsualizarlo con npx pair-install. Voy a usar eso para instalar la aplicación de chat en mi sistema fácilmente. Puedes ver que se está instalando. Se está descargando de mí mismo.

Voy a ponerlo en aplicaciones chat app. Así que, probémoslo muy bien esta vez. Está bien. Y actualmente está en 0.02, ¿verdad? Haremos la actualización una vez más. Puedes ver, ya que lo he lanzado, que hay otro par que está... Ves, ese era DOM uniéndose y saliendo. En realidad, no estoy seguro de qué era el otro. Pero uno de ellos es el pair install, y luego este es esta app uniéndose, y no se ha caído porque la app sigue abierta. No puedes verlo. Debería actualizar. ¿No? Parece todo correcto. ¿Hmm? Todo está correcto aquí. Estás conectado. Eso significa que hay un error en el boilerplate. ¿Quieres una demostración? Sí, clásico. Está bien, supongo que vamos a depurar de nuevo. Probablemente sea bueno. Si reinicias la app, ¿se soluciona? ¿O simplemente se reinicia automáticamente? Sí, tal vez se esté aplicando automáticamente, y luego tienes que reiniciar, pero no está notificando porque es muy básico, ¿no? Probemos eso. Sí, la posición está bien. No. Oh, ahí está. Yay. Sí, ahí vamos. Interesante. No sé por qué tomó reiniciar para llegar allí. Está bien, bien. Así que ves la actualización a través de la red. Ha llegado de peer-to-peer. Si esto fuera una build firmada, entonces otros podrían ejecutarla, y entonces también verías la actualización, idealmente. Cuando se ejecuta en la misma máquina así, es posible que...

Sí, puede ser un poco más complicado. En realidad, es mejor cuando está en diferentes máquinas, pero la maldita firma del proveedor. Así que apliquemos la actualización, y ahí está 03. Genial. Cool. Así que esa es la premisa general. Creas una app, cualquier app de Electron o cualquier app que tenga un package JSON. Pones una actualización. Pones un enlace pair en el campo de actualización, y luego preparas para ese enlace pair tu carpeta de despliegue de build para despliegues multi-sistema operativo, multi-arquitectura que son completamente peer-to-peer con actualizaciones over-the-air. No hay servidores involucrados en nada de esto. No hay un servidor en el medio que necesite proporcionar alguna autoridad o nada en absoluto. Lo único que tenemos a nivel de infraestructura que no es necesario pero es muy útil para la disponibilidad son los peers ciegos. Así que lo que querrías hacer es pasar tu enlace pair a un peer ciego que luego tomará tu semilla y la replicará y será como un servicio de larga duración que solo hace eso por ti pero sin realmente ver los datos. Usamos peers ciegos para todo tipo de cosas, incluyendo en Keat, donde tienes a dos personas en un chat, y una de ellas está offline, una de ellas está online. Envía un mensaje. Se encripta, se almacena con el peer ciego hasta que la otra está online, y luego lo recibe del peer ciego. Así que usamos lo mismo para aplicaciones. Es una solución genérica al problema de disponibilidad, pero eso es todo. No hay APIs de servidor ni puntos centrales ni datos realmente filtrados como tal o disponibles para nadie excepto para quien se supone que deben estar disponibles. Gracias, Dom. Gracias por tu ayuda. Después de aquí, vamos a hablar un poco más sobre la producción de apps pair un poco más. En el próximo ejercicio, hablaremos sobre pair provision. Y lo que quieres hacer es, en general, en términos de despliegue, quieres un entorno de staging, quieres un entorno de pre-lanzamiento, y quieres un entorno de producción, y también quieres un entorno de desarrollo.

Así que dev es solo local. Es solo lo que hemos estado haciendo. Staging es lo que pair stage te ofrece. Puedes usar pair stage todo el día, compartir enlaces con personas solo internamente o con amigos o lo que sea, y eso es suficiente. Para producción, quieres hacerlo más eficiente. Y lo que hace pair provision es una sincronización de bloques entre hypercores, lo que significa que omite el op log, y el op log tiene todo tipo de cosas, como todo. La forma en que funciona un hypercore es que es un registro de solo anexado. Así que todo lo que sucede se añade a los datos en ese registro de solo anexado. Pero luego puedes hacer una instantánea de los datos en sí y luego solo sincronizar esa instantánea, y eso es lo que hace pair provision. Así que usamos pair provision para crear un pre-release drive que luego usamos multisig para crear un production drive. Usamos eso como la fuente. Así que el pre-release es como la etapa reducida, y esa es la fuente. Así que eso te da un entorno de staging que fluye hacia un entorno de pre-lanzamiento a través de pair provision que luego fluye hacia un entorno de producción a través de pair multisig. Así que para provisionar, quieres un nuevo enlace. Quieres un enlace para tu pre-lanzamiento. Y luego necesitas establecer ese enlace en el campo de upgrade del package.json nuevamente. Así que lo que terminas haciendo es probablemente tener algunos flujos de CI build, ¿verdad? Y cada flujo de CI build, como uno sería para staging, que usaría un enlace de staging como el campo de upgrade, y luego tu enlace de pre-lanzamiento como el campo de upgrade, ¿verdad? Y luego producción sería un flujo ligeramente diferente nuevamente. Pero idealmente tendrías algún CI que simplemente establezca automáticamente el campo de upgrade al enlace para el despliegue que te interesa. Así que voy a crear un nuevo enlace.

Y ese es ahora mi enlace de provisionamiento. Y voy a establecer eso en el package.json así. Y luego pair provision funciona de esta manera. Le das un enlace de fuente de versión. Cuando ejecutamos pair stage antes, vimos un enlace de versión. Luego le das el enlace de destino, que es el enlace que acabo de crear para el pre-release drive. Y luego le damos un enlace de producción de versión. No tenemos un enlace de producción en este momento. Así que en ese caso, necesitas iniciar el pre-release, y solo usas un enlace de fuente de versión 0.0. Entonces, porque lo que hace pair provision es sincronizar todo desde el enlace de producción a tu enlace de pre-lanzamiento primero, solo para que siempre puedas tener – siempre sabes que estás en el estado exacto de producción antes de que luego superpongas el estado de tu fuente, de tu enlace de fuente de versión. Así que podemos encontrar el enlace de fuente exacto haciendo una prueba en seco en el enlace de staging. Así que si hago lo mismo que acabo de ejecutar pero con prueba en seco, nada va a cambiar. No queremos que nada cambie. Pero obtenemos los enlaces de versión, y ahora tengo eso. Así que lo que necesito ejecutar ahora es un provisionamiento. Voy a ejecutarlo en seco primero porque siempre quieres asegurarte, solo como un hábito, ya sea que estés en staging o provisionando, necesitas ver esa diferencia. Necesitas verificar esa diferencia muy, muy sinceramente, y en un contexto de producción, como, no quieres que se cuele nada allí que no sabías que estaba entrando allí porque esto va a salir a las máquinas de los usuarios, ¿verdad? Así que pair provision, prueba en seco, enlace de fuente de versión, que es eso. Mi enlace de destino, que es mi enlace de pre-lanzamiento, al que ahora vamos a provisionar, y enlace de producción de versión, pero aún no tenemos producción, así que cero, cero, y genial. Así que ves que está sincronizando, y luego sincronizando nuevamente desde las dos fuentes, producción y fuente. Y, sí, todo parece estar bien. Así que ahora sin la prueba en seco. Así que espera diez segundos para asegurarse. Usualmente hay más diferencia que eso, pero asegurándome de haber hecho esto bien. Sí, debería estar bien. Así que ahora que tenemos el enlace de provisionamiento, podemos sembrarlo. Te da el comando. Voy a verificar la longitud de él usando el comando pair info. Sí. ¿Y cuál es la longitud del enlace de fuente? Podría ser uno a uno porque no hemos hecho ninguna eliminación. Así que la longitud será la misma aquí, creo, porque con el tiempo, ves los beneficios.

Sí, uno, dos, nueve, tres en ambos casos. Porque el punto es que las eliminaciones se eliminan, y cuanto más iteras, más eliminaciones vas a tener. Así que una vez que tengas tu pre-release drive, voy a intentar instalar pair install desde ese drive ahora solo para verificar que funciona. Voy a eliminar esto de mis aplicaciones. Pair install desde el pre-release drive. Estoy acostumbrado a usar el último. Aún no hemos lanzado. No estoy seguro de por qué el ícono es así. Necesito investigar eso, pero al menos se abre. Y, sí, se ve bien, en general. Después de que hagas pair provision, y no voy a repasar los pasos de esto porque es tedioso, pero definitivamente vale la pena discutirlo, y luego vamos a concluir. Hemos estado trabajando en esta plataforma peer-to-peer y estas aplicaciones peer-to-peer durante varios años ahora. Con Keet, llegamos a un punto donde nos dimos cuenta de que el rigor es muy importante. Hay compensaciones para todo, pero cuando estás desarrollando tecnología peer-to-peer, sí, no tienes infraestructura. Sí, en muchos sentidos, es más fácil porque hay menos infraestructura de la que preocuparse. No tienes que pasar por ningún aro, realmente, en ese frente. Pero necesitas un rigor realmente serio en los lanzamientos de producción porque está funcionando en las máquinas de los usuarios, y si lo rompes de una manera que significa que no puede actualizarse nuevamente, digamos si un truce salvaje se coló allí o algo así, de modo que cada vez que la aplicación se inicia, no puede actualizarse. Ese es solo un ejemplo tonto, pero entonces eso es todo. No puedes actualizar más, y las aplicaciones de tus usuarios están dañadas, y luego tienen que volver al sitio web y descargarlo o lo que sea en lugar de mantener las actualizaciones OTA en marcha. Así que esa es una situación que realmente queremos evitar. Lo que Multisig te ofrece es un proceso para lanzamientos de producción con múltiples aprobaciones, y además de eso, lo que también te ofrece es una reducción en el riesgo de datos para tu drive de aplicación de producción porque todo es peer-to-peer, por lo que el estado vive en el disco. Así que tu stage drive y tu provision drive, tu stage link, tu provision link, están en un hyper-core, pero ese hyper-core existe en tu sistema de archivos, en tu disco. Y así, si tu disco se corrompe o dejas caer tu laptop en el río o lo que sea, entonces eso se pierde.

Y así, tu clave de actualización de la que dependen tus usuarios para las actualizaciones ya no se puede actualizar porque has perdido el acceso de escritura a ella. Pero lo que hace Multisig es que ya no tienes que tenerla en una sola máquina. Ya no está vinculada a la máquina. Mientras alguien la tenga en algún lugar, lo que importa para el acceso de escritura es si tienes un quórum. Un quórum es si tienes suficientes personas de entre las personas que están firmadas para permitir que este lanzamiento avance. Y una vez que tienes eso, entonces simplemente puede avanzar. Así que el comando pair Multisig es esencial para los lanzamientos de producción. Así que si ejecuto pair Multisig-h de esta manera, puedes ver que tenemos algunos subcomandos diferentes. Diferentes personas tienen diferentes roles aquí. Así que ahora voy a llevarlo al repositorio Hello Pair Electron. Así que este es el flujo general. Creas para una aplicación. Creas claves de inicio de sesión. Eso significa, como, un par de claves públicas. Cualquiera que esté involucrado en aprobar un lanzamiento de producción, obtiene una clave de inicio de sesión. Así que digamos que tienes a ti mismo y a otras dos personas, ¿verdad? Y luego creas una configuración Multisig, que es un archivo pair.json que contiene claves de inicio de sesión y el quórum, como en cuántos de los firmantes totales deben firmar para que se pueda escribir. Luego actualizas el campo de actualización, de la misma manera que hacemos con pair revision. Nuevamente, normalmente tendrías diferentes flujos de CI para esto, pero, en términos de lo que se necesita, necesitas establecer ese campo de actualización a tu enlace de producción. Y luego pasas por el mismo flujo de lanzamiento que antes. Etapas ese package.json actualizado. Así que lo versionas. Lo etapas. Luego lo aprovisionas. Y esa clave de aprovisionamiento se convertirá en la fuente de tu Multisig. Así que tu clave de pre-lanzamiento se convierte en la fuente de tu flujo Multisig. Y luego, una vez que llegas al punto de tener un pre-lanzamiento listo en tu enlace aprovisionado, tu unidad aprovisionada, entonces preparas una solicitud Multisig. Así que lo que haces allí es ejecutar pair Multisig request. Establezco tu enlace versionado de la unidad de pre-lanzamiento que fue pair provisioned. Y luego recopilas firmas. Así que vas a tus otros firmantes y dices, esto está listo para el lanzamiento de producción. ¿Puedes por favor confirmar, verificar y firmar?

Y luego, una vez que tienes, digamos, dos de tres firmantes, entonces puedes ir a pair Multisig verify, que es un paso que usas para asegurarte de que las respuestas de firma sean correctas. Reunir firmas es, como ves aquí, para cada persona, ellos ejecutarían pair Multisig sign, y les darías la solicitud que creas con pair Multisig request. Y ellos firman eso, y te devuelven la respuesta. Luego lo verificas, etcétera. Entonces sabes que está listo para continuar. Verify es en realidad solo una ejecución en seco en commit, pero es tan importante que hagas esto, que hicimos un comando separado porque esto es un asunto serio, muy serio en este punto. Así que una vez que estás satisfecho con el – una vez que el verificador ha pasado y ha dicho, sí, está bien, está listo para continuar, entonces te comprometes. Y lo que hace el commit es que toma las firmas, y las usa para comprometer tu – el delta de tu enlace de producción actual, que ya está Multisigged, desde tu enlace de pre-lanzamiento, que fue creado con el pair provision. Así que una vez que llegas a este punto de Multisigging una aplicación pair, es cuando estás haciendo un despliegue de producción real. Es lo que usamos internamente. Lo hemos estado usando durante varios años, y luego lo convertimos en una herramienta de despliegue como parte de pair. Pero es una forma realmente agradable de hacerlo. Otra cosa es que no haces pair touch con enlaces Multisig que pones en el campo de actualización. Primero, configuras tu configuración Multisig en tu pair JSON, y luego ejecutas pair Multisig link porque el enlace está determinado por tu configuración de manera determinista.

JS Nation

JSNation 2026

Pear: Releasing Production P2P Apps

Pear: Lanzamiento de Aplicaciones P2P de Producción

JSNation US

JSNation US 2026

Bienvenido al despliegue de aplicaciones pair enfocándose en actualizaciones peer-to-peer sin servidores. Utilizando PairTouch para crear hyperdrives e hypercores para el despliegue del juego snake. Desplegando aplicaciones con Pair build, depurando problemas en vivo y planificando un nuevo despliegue de aplicaciones. Explorando pear-stage para actualizar aplicaciones y sincronización peer-to-peer. Discutiendo Multisig para lanzamientos de producción y la importancia de la verificación de firmas en pair Multisig para el despliegue.

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 este masterclass:<ul><li>Construir una aplicación peer-to-peer en tiempo real</li><li>Conectar con otros en tu propia aplicación, completamente peer-to-peer.</li><li>Entender cómo desplegar, incluyendo prácticas de producción, principios y herramientas</li></ul>Esto es para cualquiera que construya con JavaScript y cualquiera que despliegue aplicaciones.

David Mark Clements

Mikkel Malmberg

React Advanced

React Advanced 2026

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

React Summit US

React Summit 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

Pear: Lanzamiento de Aplicaciones P2P de Producción

Comments

Available in other languages: