¿Estás haciendo un pair build? No, no lo creo. Tal vez. No lo hice funcionar 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 el eso parece que las cosas nuevas de sidecar pueden ser un problema. Solo verifica. Sí, eso está todo ahí. Rebuild arm 64. ¿Entonces no puedes reproducirlo o sí puedes? No, no puedo llegar tan lejos. Puedo ejecutarlo bien con npm run dev. npm start por el momento. Va a ser una cosa incompatible, pero esto es producción. Debería funcionar con eso. Oh, tienes razón. Puedo hacerlo en un segundo. Sí, estoy obteniendo lo mismo. Bien, hagamos el chat en su lugar. Esperemos que eso funcione. Ese es demasiado largo para depurar. Así que parece que vamos a hacer lo de make también. Así que bien, hagámoslo rápidamente. Así que lo que estoy haciendo es que voy a hacer esto desde cero en lugar de la aplicación snake. Haremos un chat desde cero y luego lo desplegaremos muy rápidamente. De hecho, ni siquiera necesita ser la aplicación de chat. Puede ser solo la clave de upgrade que ya creé con pair touch. Voy a usar eso para esto en su lugar. No puedo encontrarlo. Así que crearé uno nuevo. Genial.

Hola, y bienvenidos al despliegue de aplicaciones pair. En la última sesión, hablamos sobre la creación de aplicaciones con pair, es decir, la creación de aplicaciones peer-to-peer. En esta sesión, estamos hablando sobre el despliegue de aplicaciones peer-to-peer peer-to-peer, como en actualizaciones over-the-air, peer-to-peer de un par a otro para que no se necesite servicio para realizar despliegues 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 creado 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. 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 para actualizaciones over-the-air llamado pair runtime, y luego pair, el CLI, la interfaz de línea de comandos. También tenemos un tiempo de ejecución JavaScript que es para uso embebido, como en móvil, IOT embebido real, pero también embebido en cualquier otra aplicación JavaScript. El módulo de tiempo de ejecución pair tiene un método run que luego ejecutará un trabajador, un trabajador especial pair, no cualquier otro tipo de trabajador, con una conexión sobre IPC a él. Tenemos el ecosistema de módulos pair, que son todas las capacidades nativas.

La otra cosa sobre pair es que no hay biblioteca estándar en absoluto. No hay dependencias principales. Así que todo viene a través de la instalación. No tiene sentido que un proceso tenga acceso al sistema de archivos si no necesitas acceso al sistema de archivos, por ejemplo. No hay un módulo FS principal. Solo hay un módulo bear FS que instalas. Y luego está el ecosistema de módulos hyper y auto, que te da las capacidades P2P. Cubrimos algo de eso en la sesión anterior. En esta sesión, vamos a centrarnos realmente en la interfaz de línea de comandos como herramienta de despliegue. Vamos a echar un vistazo rápido al tiempo de ejecución de pair. Básicamente, creas una instancia de pair. Tienes un actualizador al que escuchas para eventos de actualización y 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 de trabajo bear o hilo en móvil. 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 la 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 desplegar un snake peer-to-peer para mostrar el flujo. Hay un flujo de despliegue completo, completamente documentado, el hello, ParaElectron 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. Vamos a simplemente 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 la masterclass. Ya la tengo aquí. Y luego estamos usando el...estamos en la parte dos de la masterclass. Estamos usando el...estamos en la parte dos del despliegue de esta masterclass en particular. Comenzando en el despliegue 01 pair touch. Así que la forma en que funciona pair es que básicamente posee un montón de hyperdrives. Un hyperdrive es una estructura de sistema de archivos que se construye sobre un hypercore. Un hypercore es una estructura de datos peer-to-peer para la replicación. El juego de snake utiliza Hyperswarm. Y generalmente, tú...y eso es para conectar pares entre sí a través de una tabla hash distribuida por tema. Y generalmente, replicarías un hypercore o hyperdrive sobre Hyperswarm. Todo eso para decir que 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 de tiempo de ejecución 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 cuando estamos usando pair stage, de lo cual hablaremos más adelante. Pero cuando hacemos eso, lo que esencialmente está haciendo es escribir datos en ese hyperdrive, que se mantiene en hypercore. Y luego, más adelante, el hypercore es replicado 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 a tu aplicación. Así que lo primero que necesitamos es obtener snake. Así que vamos a clonar snake. También voy a poner eso en el chat. 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, deberías ver algo como esto. Una vez que tengas pair instalado, simplemente crea tu enlace con pair touch. Y eso me dará un enlace. Ahora, para configurar el despliegue, lo que realmente necesitamos hacer, lo más importante que tenemos que hacer aquí es decirle a la biblioteca de tiempo de ejecución de pair qué enlace de pair usar para encontrar tu aplicación hyperdrive sobre la tabla hash distribuida desde otros pares. Y hacemos eso configurando el campo de upgrade como package JSON. Así que en snake, voy a ir al package JSON, configurar el campo de upgrade, que está aquí abajo, configurarlo al enlace que he creado. Así que el campo de upgrade ha sido configurado a ese nuevo enlace. Y eso ahora es mi enlace de staging.

Así que una vez que tenemos el enlace, necesitamos crear algunos distribuidos de la aplicación. Así que voy a ejecutar NPM install aquí, obtener las dependencias. Y luego, cuando hacemos los distribuidos, el enfoque sería ejecutar make en tu máquina Windows, en tu máquina Linux, en tu Mac. Si tienes Intel o ARM64, quieres uno de cada uno, idealmente para cada uno. Y luego los pones todos en una máquina, lo cual puedes simplemente... Hay muchas herramientas para hacer eso, pero podrías enviarlos a través de Keat, por ejemplo, o podrías realmente pair staging, pair dump entre máquinas, pero no es un ejercicio para hoy. Y luego los ensamblas en una sola carpeta de despliegue usando pair build. Y luego esa carpeta de despliegue es lo que se sincroniza en un hyperdrive a través de pair stage. Y eso es luego expuesto sobre el DHT a través de pair seed. Y luego, cuando das a los usuarios tu distribuible, como en myapp.app o lo que sea, lo abren y luego el campo de upgrade es verificado por el módulo de tiempo de ejecución. Y está conectado a, y luego verifica si hay actualizaciones. Y así es como conectamos todo esto. Pero lo que vamos a hacer es simplemente hacer un distribuible en nuestra propia máquina solo para ver el flujo completo. Pero a partir de eso, puedes ver cómo hacer una distribución completa multi-sistema operativo, multi-arquitectura para el despliegue. Así que ahora que las dependencias se han instalado, 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 probar otra caja Linux allí para ver el flujo completo de actualización entre diferentes máquinas, diferentes redes, lo que quieras probar. Pero créenos. Funciona a través de 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 particular sistema operativo y arquitectura. Y luego lo apuntas al package json del proyecto que tiene el campo de upgrade. Y luego le das una bandera de destino opcional para que sepa dónde poner eso. Así que solo vamos a hacer Darwin arm 64 porque es lo que estoy ejecutando. Pero si estás en Linux, tendrías Linux X 64, etc. Y luego cuando 32 usa la misma convención que el proceso de plataforma en node. Así que lo que hace pair build es crear esta carpeta llamada by arc, y coloca el package json en el nivel superior al lado de ella. Y luego dentro de la carpeta by arc app, están todos los diferentes directorios para todas las diferentes combinaciones de sistema operativo y arquitectura. Así que en nuestro caso, será by arc, o en este caso, será by arc, app down on 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. Así que desde antes, así que vamos a ejecutar her 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 repo actual, y luego decir ponerlo en dot out dot forward slash out for slash build. Sí. Así que ahora tenemos una carpeta by arc y un package json y la carpeta by arc. Oh, lo siento. Al revés. Ese es mi error. Siempre hago eso. La carpeta de la aplicación está dentro de la carpeta by arc. Y hay snake. Ábrelo para ver qué está pasando. Es una mala idea. Parece que hay algo mal con el flujo de construcción y snake. Dom, si tienes alguna idea sobre eso. Ahora puedes vernos depurar esto en vivo. Sí.

Esto es en realidad una mejor demostración porque tenemos el versionado. Así que puedes hacer... Lo que hice allí fue clonar hello pair electron y luego simplemente establecer el nombre y el nombre del producto a chat y configurar el campo de upgrade a nuestro enlace de pair touch. Así que ahora podemos volver a hacer. En cierto modo, es bueno porque lo estamos viendo ejecutarse varias veces a través. Así que queremos hacer... Genial. Bien, tenemos una construcción que está funcionando. Genial. Ahora podemos avanzar. Así que el mismo proceso pero tienes que tener una aplicación que funcione para que esto funcione. Así que en realidad es chat. Oh, ¿hiciste funcionar snake, verdad? Sí, si después de hacer, puedes simplemente ejecutar esto en este momento. Parece que no está trayendo el arm 64. Oh, es un problema bastante bueno. Sí. Bien, buena solución. Nos quedaremos con el tema del chat por ahora porque no se trata realmente de snake. Se trata de actualizar una aplicación peer-to-peer por aire. Así que... El comando de construcción. Le damos 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 una construcción de salida. Sí, obtuvimos el por arc y luego tenemos abajo en 64 dentro de eso y luego app y luego la aplicación real. En última instancia, lo que quieres es una carpeta bi-arc con todos tus sistemas operativos y arquitecturas. Y eso es lo que realmente importa.

Esa es la unidad de despliegue que se siembra de igual a igual. Así que pasemos a PairStage. Lo que hace PairStage es sincronizar desde el disco a hyper drive que está dentro de pair. Y luego, puedes ver eso. Pero antes de ejecutarlo, quieres hacer una ejecución en seco. Así que... Aquí está cómo obtienes la ayuda, pairstage.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. Así que, puedo obtener el enlace así de fácilmente. Aquí está el enlace que estamos usando. Y quiero decir PairStage dry run mi enlace y luego out build como el directorio. Este enlace de PairStage allí. Vemos con la diferencia, esto es lo que se va a sincronizar en nuestro hyper drive. Y eso es lo que parece 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 una 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 de versión. Vamos a usar eso más tarde cuando hagamos pair provision. Un enlace de versión dice, esta es la longitud del drive. El 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 PairSeed, el mismo enlace de nuevo. Y ahora estoy sembrado. 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 hacer una actualización y observar el flujo de actualización. Ahí vamos. Ahí está Dom. ¿Qué hiciste con Dom? ¿Lo hiciste? Sí. Ha ejecutado PairDump y luego pasó ese enlace. Y luego básicamente está tomando todo mi, todo lo que fue preparado en ese diff, él lo está obteniendo ahora en su sistema de archivos desde el mismo drive como un par. Pero si alguien estaba ejecutando una aplicación, porque nuestra aplicación tiene este enlace como el campo de actualización, entonces se unirían como pares también. Y luego podrían hacer descargas, y así sucesivamente. Verías todo eso sucediendo. 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 el boilerplate predeterminado funciona desde Hello ParaElectronics, voy a hacer una pequeña actualización. En realidad, no necesito hacer eso porque la forma en que el boilerplate predeterminado funciona desde Hello ParaElectron, es que genera la versión.

De todos modos, vamos a tener que aumentar la versión. Así que realmente no necesitamos aplicar ninguna actualización aparte de eso. Así que voy a omitir ese paso para esto. Entonces, para desplegar la actualización, lo que haces es asegurarte de que la aplicación esté sembrada, aumentas la versión de package.json, vuelves a crear los distribuibles, reconstruyes la carpeta de despliegue y luego la preparas de nuevo. Y entonces 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 make de nuevo. Y luego build de nuevo. Y entonces deberíamos tener en outbuild, el package.json dice 0.01. Así que ahora sabemos que eso está actualizado. Y entonces deberíamos tener en build, el package.json dice 0.01. Así que ahora sabemos que eso está actualizado. Así que luego simplemente lo preparamos de nuevo. Debería haber hecho un dry run primero. Pero podemos ver por el diff que el package.json se actualizó, el manifiesto de Apex 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 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 instalarlo. No, no necesito. Solo necesito ejecutarlo.

Entonces, si abro esta aplicación de chat aquí, debería ser la versión 0.00. Pero está escuchando este enlace sembrado que tenemos aquí. Así que lo he hecho al revés. Debería haber estado ejecutándose antes de ejecutar stage. Eventualmente se actualizará, pero tarda más cuando lo haces de esta manera. Así que voy a intentar aumentarlo de nuevo. Está bien. Podemos siempre pasar por el flujo de nuevo. Así que es version, make, pair build, pair stage. Esta vez voy a hacer un dry run por higiene. Sí, está bien. Y ahora sin el dry run. Hmm. Dom, ¿alguna idea? Pensé que eso funcionaría. De nuevo, ¿qué cambiamos? Hice una actualización. Actualicé el… Sí. Está bien. Pero eso es porque… Sí, creo que tal vez no debería haberlo ejecutado desde la carpeta out. Debería haberlo puesto en otro lugar y luego ejecutarlo. Eso es probablemente una de las veces 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 dash install. Voy a usar eso para instalar la aplicación de chat en mi sistema fácilmente. Puedes ver que está instalado. Se está descargando de mí mismo a través de una semilla, y ahora lo ha puesto en aplicaciones chat app. Así que probémoslo muy bien esta vez. Bien, y luego está actualmente en 0.02. Haré la actualización una vez más. Puedes ver, desde que lo lancé, que hay otro par que… Ves, ese fue 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 aplicación uniéndose. Y no se ha caído porque la aplicación sigue abierta.

Entonces, si podemos hacer… Debería actualizar. No. Parece todo correcto. Todo está correcto. Sí, estás conectado. Y eso significa que hay un error en el boilerplate. Muchos demos para ti. Sí, clásico. Bien, supongo que vamos a depurar de nuevo. Probablemente sea bueno. Si reinicias la aplicación, ¿se actualiza, o simplemente no siempre inicia? Sí, tal vez se está aplicando automáticamente, y luego tienes que reiniciar, pero no está notificando porque es muy básico, ¿verdad? Probemos eso. No. Oh, ahí está. Sí, ahí vamos. Interesante. No sé por qué tomó reiniciar para llegar allí. Bien, bien. Entonces, ves la actualización cruzar la red. Ha cruzado de igual a igual. Si esto fuera una build asignada, entonces otros podrían ejecutarla, y también verías la actualización, idealmente. Cuando se ejecuta en la misma máquina así, es posible que… Sí, es un poco raro. Sí, puede ser un poco más raro. 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á 0.3. Genial. Cool. Así que, esa es la premisa general. Haces una aplicación, cualquier aplicación de Electron o cualquier aplicación que tenga un package JSON, pones una actualización, pones un pair link en el campo de actualización, y luego haces stage a ese pair link tu carpeta de despliegue de build para despliegues multi-sistema operativo, multi-arquitectura que son completamente de igual a igual 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 algo en absoluto. Lo único que tenemos a nivel de infraestructura que no es necesario, pero es muy útil para la disponibilidad son los pares ciegos. Entonces, lo que querrías hacer es pasar tu pair link a un par ciego que luego tomará tu semilla y replicará eso y será como un servicio de larga duración que solo hace eso por ti, pero sin realmente ver los datos. Usamos pares ciegos para todo tipo de cosas, incluyendo en Keat donde tienes dos personas en un chat, y una de ellas está desconectada, una de ellas está en línea. Envía un mensaje, se encripta, se almacena con el par ciego hasta que la otra está en línea, y luego lo recibe del par ciego. Así que, usamos lo mismo para aplicaciones. Es una solución genérica a este problema de disponibilidad, pero eso es todo. No hay APIs de servidor ni ningún punto central ni ningún dato realmente filtrado como tal o disponible para nadie excepto para quien se supone que debe estar disponible. Gracias, Dom. Gracias por tu ayuda. Después de aquí, vamos a hablar un poco más sobre la producción de aplicaciones pair. 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. Entonces, dev es solo local. Es solo lo que hemos estado haciendo. Staging es lo que pair stage te ofrece. Puedes hacer 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 ser eficiente con ello. Y entonces, lo que pair provision hace 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. La forma en que un hypercore funciona es que es un registro de solo anexado, por lo que todo lo que sucede se anexa 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 pair provision hace. Así que, usamos pair provision para crear un drive de pre-lanzamiento que luego usaríamos multi-sig para crear un drive de producción. Usamos eso como la fuente. Entonces, el pre-lanzamiento es como la etapa reducida, y esa es la fuente. 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 multi-sig. Entonces, 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.

y luego necesitas establecer ese enlace en el campo de upgrade del package JSON nuevamente. Entonces, lo que terminas haciendo es probablemente tener algunos flujos de construcción CI, ¿verdad?, y cada flujo de construcción CI, como uno sería para staging, que usaría un enlace de staging como el campo de upgrade, y luego tu pre-lanzamiento usaría el enlace de pre-lanzamiento como el enlace de staging. Luego tu pre-lanzamiento usaría el enlace de pre-lanzamiento como tu 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. Entonces, voy a crear un nuevo enlace, y ese es ahora mi enlace de provision, y voy a establecer eso en el package JSON de esa manera, y luego pair provision funciona así. Le das un enlace de fuente de versión. Cuando ejecutamos pair stage antes, vimos un enlace versionado. Luego le das el enlace de destino, que es el enlace que acabo de crear para el drive de pre-lanzamiento, y luego le damos un enlace de producción de versión. No tenemos un enlace de producción en este momento. Entonces, en ese caso, necesitas inicializar el pre-lanzamiento, y simplemente usas un enlace de fuente versionado 0.0. 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 sepas que estás en el estado exacto de producción antes de superponer el estado de tu fuente, de tu enlace de fuente de versión. Entonces, podemos encontrar el enlace exacto de fuente haciendo una ejecución en seco de stage en el enlace de staging.

nada va a cambiar. No queremos que nada cambie, pero obtenemos los enlaces de versión. Ahora, tengo eso. Entonces, lo que necesito ejecutar ahora es una provisión. Voy a hacer una ejecución en seco primero porque siempre quieres asegurarte, solo como hábito, ya sea que estés en staging o en provisión, necesitas ver esa diferencia, necesitas verificar esa diferencia muy sinceramente. Y en un contexto de producción, no quieres que se cuele nada que no sabías que estaba entrando porque esto va a salir a las máquinas de los usuarios. Entonces, pair provision dry run version source link, que es eso. Mi enlace de destino, que es mi enlace de pre-lanzamiento, al que ahora vamos a provisionar. Y un enlace de producción de versión, pero aún no tenemos producción. Entonces, cero, cero. Genial. Entonces, ves que está sincronizando, y luego sincronizando nuevamente desde las dos fuentes, producción y fuente. Y, sí, todo parece estar bien. Entonces, ahora, sin la ejecución en seco. Entonces, espera diez segundos para asegurarse. Usualmente, hay más diferencia que eso, pero asegurándome de haber hecho esto correctamente. Sí, debería estar bien. Entonces, ahora que tenemos el enlace de provisión, podemos sembrarlo. Te da el comando. Solo voy a verificar la longitud de él usando el comando pair info. Sí. ¿Y cuál es la longitud del enlace de fuente?

Sí, uno, dos, nueve, tres en ambos casos. Con el tiempo, ves los beneficios porque el punto es que las eliminaciones se eliminan, y cuanto más iteras, más eliminaciones vas a tener. Una vez que tienes tu drive de pre-lanzamiento, voy a intentar instalar desde ese drive ahora solo para verificar que funciona. Voy a eliminar esto de mis aplicaciones. Instalar desde el drive de pre-lanzamiento. Estoy acostumbrado a usar el último. Aún no hemos lanzado. No estoy seguro de por qué los íconos son así. Necesito investigar eso. Pero al menos se abre. Y sí, se ve bien, en general. Después de que hagas pair provision, no voy a repasar los pasos de esto porque es largo, pero definitivamente vale la pena discutirlo. No voy a repasar los pasos de esto porque es largo, 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. Y con Keat, 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 obstáculo 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 que un while, true 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.

Así que sí, he estado trabajando en eso. Cada vez que la aplicación se inicia, no puede actualizarse. Ese es un ejemplo tonto, pero luego eso es todo. Ya no puedes actualizar, y las aplicaciones de tus usuarios están dañadas. Y luego tienen que volver a el 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 quieres evitar. Lo que multisig te da es un proceso para lanzamientos de producción con múltiples aprobaciones. Y además de eso, lo que también te da es una reducción en el riesgo de datos para tu drive de aplicación de producción porque todo es peer-to-peer. Así que el estado vive en el disco. Entonces, tu drive de stage y tu drive de provision, tu enlace de stage, tu enlace de provision, están en un hypercore, pero ese hypercore 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 actualizaciones ya no puede actualizarse porque has perdido el acceso de escritura a ella. Pero lo que multisig hace es que significa que ya no tienes que tenerlo en una sola máquina. Ya no está vinculado a la máquina. Mientras alguien lo tenga en algún lugar. Lo que importa es que para el acceso de escritura, es si tienes un quórum. Un quórum es, ¿tienes suficientes personas de entre suficientes personas que han firmado 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.

Entonces, si ejecuto pair multisig dash H de esta manera, puedes ver que tenemos algunos subcomandos diferentes. Diferentes personas tienen diferentes roles aquí. Así que, voy a llevarlo al repositorio hello parallel electron ahora. Así que, este es el flujo general. Creas, para una aplicación, creas signing keys. Eso significa como un par de claves públicas. Cualquiera que esté involucrado en firmar un lanzamiento de producción, obtiene una signing key. Así que, digamos que tienes a ti mismo y a otras dos personas. ¿Verdad? Y luego creas un multisig config, que es un archivo pair dot JSON que contiene las signing keys y el quórum, como en cuántos de los firmantes totales deben firmar para que se pueda escribir. Luego actualizas el campo upgrade, de la misma manera que hacemos con pair revision. Como, de nuevo, tendrías diferentes flujos de CI para esto, usualmente, pero en términos de lo que se necesita, necesitas establecer ese campo upgrade a tu production link. Y luego pasas por el mismo flujo de lanzamiento que antes. Etapas ese package JSON actualizado. Así que, lo versionas, lo etapas, luego lo provisionas, y esa provision key se convertirá en la fuente de tu multisig. Así que, tu pre-release key se convierte en la fuente de tu flujo multisig. Y luego una vez que llegas al punto de tener un pre-release listo en tu provisioned link, tu provisioned drive, entonces preparas una multisig request. Así que, lo que haces allí es ejecutar pair multisig request. Establezco tu version link del pre-release drive que fue pair provisioned. Y luego reúnes 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? Así que, una vez que alguien está firmando, están poniendo su reputación en juego, están poniendo su clave pública allí para decir, he verificado que este lanzamiento de producción está listo para salir. Y luego, una vez que tienes dos de tres firmantes, entonces puedes ir a pair multisig verify, que es un paso que usas para asegurarte de que las respuestas de las firmas son correctas. Reunir firmas es, ves aquí, para cada persona, ellos ejecutarían pair multisig sign y tú les darías la solicitud que creaste con pair multisig request. Y ellos firman eso y te devuelven la respuesta, luego lo verificas, etcétera. Y luego sabes que está listo para salir. Verify es en realidad solo un dry run en commit, pero es tan importante que hagas esto, que hicimos un comando separado porque esto es un asunto serio, 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 salir, entonces cometes. Y lo que hace el commit es que toma las firmas y las usa para cometer tu, el delta de tu production link actual, que ya está multisigged. De tu enlace anterior, que fue creado con el pair provision. Así que, una vez que tienes, una vez que llegas a este punto de multisigging una aplicación pair, es cuando estás, 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, es una forma realmente agradable de hacerlo. Otra cosa es que no, no tocas pair con enlaces multisig que pones en el campo de actualización. Primero configuras tu multisig config en tu pair.json y luego ejecutas pair multisig link porque el enlace está determinado por tu configuración de manera determinista. Así que, después de eso, todo el flujo por el que ya hemos pasado es el mismo, hasta la provisión. Y luego, luego usas tu, tu, tu enlace de versión provisionado y lo pasas a, a tu, a tu, a tu, tu, tu enlace de versión provisionado y lo pasas a una pair multisig request para iniciar un flujo multisig. Y así es como lo haces. Así es como, así es como haces aplicaciones peer-to-peer. Así es como despliegas aplicaciones peer-to-peer. Y así es como ejecutas un proceso de producción serio que está completamente integrado tecnológicamente con, con aplicaciones peer-to-peer para actualizaciones over-the-air, próximamente también para móviles, actualizaciones over-the-air de la misma manera. Mismo flujo de despliegue para móviles, mismo flujo de despliegue para escritorio. Para concluir, obtén Keet en Keet.io, encuéntrame, DMC0, únete al grupo PairDev. Y si estás trabajando en algún proyecto peer-to-peer, envíame un DM. Si estás, si estás interesado en trabajar con nosotros, estamos contratando, revisa careers.ted.com y holepunch.recrui.com. Muy bien. Gracias a todos.

Web Engineering Summit

Web Engineering Summit 2026

Pear: Releasing Production P2P Apps

Pear: Lanzamiento de Aplicaciones P2P de Producción

React Advanced

React Advanced 2026

Introducción al despliegue de aplicaciones pair con un enfoque en actualizaciones peer-to-peer y la pila pair. Se destaca el CLI de Pair para el despliegue, la falta de biblioteca estándar y las capacidades P2P. Se discuten los Hyperdrives, Hypercores y Pair Links de Pair para la replicación de datos. Creación de distribuciones, solución de problemas de construcción de pair y versionado para el despliegue. Sincronización de PairStage, actualización de aplicaciones y puesta en escena del despliegue sin intermediario de servidor. Aprovisionamiento para flujos de construcción CI, sincronización de versiones y lanzamientos de producción seguros con multisig. Herramienta de despliegue interna de Pair para el despliegue de aplicaciones peer-to-peer y actualizaciones over-the-air.

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

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

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

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

React Summit Asia 2027

AI Coding Summit Asia 2027

JS Nation

I’m attending JSNation – the main JavaScript conference of the year. You may join me there for free with 10k other JS engineers and 40+ great speakers. Just follow this badge. 

#javascript

JSNation 2027

React Summit

React Summit 2027

Pear: Lanzamiento de Aplicaciones P2P de Producción

Comments

Available in other languages: