P2P React: Estado Local-Primero, Verdad Compartida

Primero, quiero que cierres los ojos e imagines a un usuario en tu aplicación. ¿Puedes creerlo? Sucedió todo este tiempo construyendo. De repente aparecieron. Este es el sueño. Este es el sueño en el que pasaste tanto tiempo. Ahora finalmente están aquí. Los gráficos están graficando. Los usuarios están usando. ¿Son usuarios? ¿Son bots? ¿Quién sabe siquiera? ¿A quién le importa? Está sucediendo. El sueño es real. Finalmente pusiste IndieHacker en tu perfil de Twitter y esperas despertar a niveles de pares de riqueza y fama.

Y luego, al día siguiente, te despiertas y de repente los usuarios están allí, muchos usuarios, construiste una aplicación, es como una especie de cosa de chat. Tal vez sea como compartir archivos multimedia. Hay mucho almacenamiento de medios. Las facturas también comienzan a aparecer. Recibes una factura de tu proveedor de hosting llamado Triangle. Es como 20k de la nada. ¿Cómo? ¿Cómo? ¿Fueron solo imágenes? Luego tu proveedor de base de datos, SuperMaze, otra factura, Dork, tu servicio de autenticación cobra por asiento. ¿Los bots necesitan asientos? ¿Los bots tienen bots? ¿Quién sabe? Pero todos estos usuarios usando tu aplicación, este es el sueño. ¿No debería ser algo bueno?

De repente comienza a pesarte. ¿Cómo voy a pagar por este tráfico y todo este uso? Y aquí es donde puede entrar peer-to-peer. Porque ¿y si todos esos usuarios fueran realmente algo bueno que te ayudaría? Pero antes de eso, el problema aquí es que todo pasa por los servidores. Pero ¿qué es siquiera un servidor? En el sentido tradicional es más o menos tres cosas. Digamos que son al menos tres cosas. Así que están todas las solicitudes post que llegan de los usuarios. Van al servidor. El servidor las valida, se asegura de que todo esté bien, y almacena los datos. Y luego, por supuesto, en el otro extremo, están todas las solicitudes get, la gente leyendo los datos. Así que almacena los datos, se asegura de que los datos sean válidos, y luego entrega los datos, supongo. Sostiene la verdad y los datos.

Pero está bien. Podemos confiar en esto. Quiero decir, al menos nosotros sí. Confiamos en esto. Porque sí, lo hacemos. Pero también esto se convierte en un único punto de fallo. Si el servidor tiene un mal día, este servidor feliz se cae, GitHub. ¿Qué pasa entonces? Todo se cae. Nada funciona. Así que, pero luego recuerdas en tu cosa de construcción de aplicaciones aquí que una vez fuiste a una conferencia y había este tipo guapo, inteligente, brillante, hablando sobre peer-to-peer. Y al día siguiente, había otro tipo también hablando sobre peer-to-peer. Y mencionó cómo esto resolvería algunos de estos problemas.

Así que peer-to-peer, solo las mismas cosas. No puedes eliminar estas cosas. Solo las redistribuyes. Y hacemos esto con criptografía simple. Así que lo primero que tenemos es ¿qué es siquiera un usuario en este espacio? En un sentido tradicional, es la fila de la tabla, fila de la tabla HTML en doc, tu proveedor de autenticación, o es una fila en tu base de datos. ¿Qué está pasando? ¿Es mi barba? Una fila en una base de datos. Así que ese es el usuario tradicional que pensamos. Pero en realidad, un usuario en este sentido es como las claves. Las claves que usas para firmar las cosas que entran en este sistema compartido. Así que antes de tener un usuario, tienes un conjunto de claves.

Y luego podemos hacer que inventemos esto llamado un perfil. Estamos acostumbrados a tener perfiles, es como un avatar, y una descripción, y un nombre de usuario o lo que sea. Y podemos hacer que estas claves sean las únicas claves que pueden controlar este perfil en el sentido de que el uso se convierte en ese perfil, y las claves determinan quién puede modificarlo. Y puedes tener múltiples claves controlando el mismo perfil, como tu móvil y tu escritorio. De todos modos, ahora tenemos usuarios de nuevo. Y luego todos los usuarios, por supuesto, se reúnen alrededor de cosas. Así que en el ejemplo de la aplicación de chat es probablemente la sala, por ejemplo. Estamos construyendo una aplicación de chat en Tether llamada Keet.

Deberías usarlo. Mostraré un código QR más tarde. En una aplicación de documentos, sería el documento. Imagina una aplicación de DJ, sería el set de DJ. Sea lo que sea, probablemente siempre tengas algo alrededor de lo cual reunirte. Este es el espacio en este sentido. Y podemos hacer que solo los usuarios que son invitados a un espacio determinado tengan acceso a él. E incluso podemos hacer que haya roles y permisos y todo eso. Tienes que ser un moderador para, no sé, tú lo defines. La clave es que puedes construir casi cualquier aplicación que puedas imaginar, en esta forma donde está distribuida en lugar de basada en servidor.

Y entonces lo que sucede es que todos los usuarios... ¿Soy yo? ¿Es el cable en el suelo? No. ¿No? Son solo los ecos de los efectos de audio de UNICEF. De todos modos. Así que tenemos usuarios participando enviando mensajes. Todo lo que sucede en nuestro sistema hemos determinado que son como mensajes. Sabemos esto de, no sé, Redux o algo así. Tienes las acciones y luego pasan por un reductor o algo. Y luego tenemos que decir, saliendo al otro lado.

Podemos hacer lo mismo pero distribuirlo. Así que cada usuario usa sus claves para firmar los mensajes y podemos cifrarlo todo y todo. Y luego, mientras compartamos la misma verdad... ¿Cómo llegamos a esa verdad? Tenemos los registros de todos los mensajes de los usuarios. Todas las cosas que han sucedido en nuestra aplicación son como un registro gigante de cosas. Y luego si queremos hacer la misma función aquí llamada aplicar, que es como... Si esto huele un poco a blockchain, es porque es un poco como blockchain. Si ejecutas los mismos mensajes a través de la misma función, puedes hacerlo tantas veces como quieras. Mientras sea determinista, obtendrás los mismos resultados.

Y así, si ejecutamos los mismos mensajes a través de la misma función, obtendremos el mismo resultado. Podemos confiar el uno en el otro siempre que lleguemos al mismo resultado. Sí. Eso, por supuesto, significa que es determinista. No podemos usar fechas. Por ejemplo, en la función apply, no podemos usar aleatoriedad y todo eso. Sí. Y esto es, por supuesto, algo en lo que probablemente no piensas mucho cuando estás construyendo contra servidores. Pero se vuelve importante cuando lo haces para peer-to-peer. Pero en cierto sentido... ¿En qué estaba pensando? Sí. Entonces, creo que quiero volver a esto. Así que solo un punto que tal vez olvidé mencionar, pero es tu perfil. Así que puedes mantener el perfil. En cierto sentido, cualquiera puede mantener los datos. No importa quién mantenga los datos, porque probablemente están cifrados, y tú tienes las claves para ello. Así que digamos que mi perfil, o mis datos, o mis notas están en una pequeña caja fuerte. Puedo darte la caja fuerte, y puedo darle a otro una taza. No coincide completamente con el ámbito físico, pero aún así, si soy el único con las llaves de la caja fuerte, realmente no importa quién la lleve. Y esto es lo mismo aquí, con el perfil. Mi perfil puede ser compartido entre cualquiera.

Tenemos cosas incluso en Keap, como una bandeja de entrada. Así que cuando recibes una solicitud de amistad, un usuario pone una solicitud de amistad en tu bandeja de entrada, y luego la bandeja de entrada puede vivir donde sea, pero tú eres el único con acceso a ella, era el punto que creo que olvidé mencionar. Y todo esto ya existe, es lo que estamos usando para mantener la aplicación de chat. Está como hecho, como que funciona. No como que funciona, funciona. Keap hace todo lo que querrías de una aplicación de Messenger. Y lo que ahora estamos empezando a hacer lentamente es tomar todos los aprendizajes que hemos aprendido al construir Keap, y luego ponerlos en una especie de SDK tipo framework, para facilitar a cualquiera construir aplicaciones impulsadas por peer-to-peer. Así que no tienes que pensar demasiado en los métodos apply, funciones apply, y todo, pero darte algunas buenas convenciones para construir cosas, para que puedas pararte sobre los hombros de tether, supongo.

Así que esto no es definitivo, no es necesariamente cómo se verá, pero esta es más o menos la dirección que quiero seguir, donde tienes un gestor de espacios, así que el espacio en este caso es la cosa alrededor de la cual te reúnes, la sala para la app de chat, el documento para la app de documentos. Y puedes añadir comandos y puedes añadir colecciones y todo eso. Así que para una app de chat, por ejemplo, definimos un esquema para cómo se ven las cosas, es un chat, tiene colecciones, una de ellas son mensajes, tienen sensaciones como cualquier cosa que hayas visto antes, y también hay comandos. Así que se parece un poco a una cosa de Redux, tenemos acciones y se resuelven al mismo estado. También podrías, así que esto es clave para la app de chat, pero también podrías imaginar, en este caso lo llamaré bunk docs, este es un competidor de Google docs, donde también tenemos roles, así que un propietario puede hacer cualquier cosa, un editor puede hacer estas cosas. He jugado con un Yjs, ¿conoces Yjs? Es como una cosa de biblioteca multijugador, así que puedes usar tip tap, pero tener múltiples editores en la misma cosa, así que he escrito una capa de adaptador que pone Yjs en esto, y por supuesto un documento tiene metadatos, podemos añadir eso, y tenemos comandos de nuevo. Y esta es una demo de una app de prueba de bunk docs ejecutándose en el simulador y electron aquí. Captas la idea. Pero solo para decir, cualquier cosa es posible, es solo cuestión de estructurarlo de esta manera especial. ¿Lo vemos hasta el final, supongo? Bien, eso es suficiente. Tenemos un poco de acción de atún. Y los emojis no funcionan.

Bueno, esto es imaginar Dropbox, las buenas partes, supongo. Cómo solía ser, simplemente compartes una carpeta y cualquier cosa que pongas en esa carpeta puedes tener en todas tus máquinas y puedes invitar a personas a ella. Es el mismo tipo de cosa. El espacio aquí es la carpeta individual, luego usar es una palabra clave para, una especie de capa de middleware donde puedes usar todos los bloques de construcción que hemos creado para nuestra app también. Así que tenemos soporte para almacenamiento de blobs, y en este caso, drive, que es hyper-drive, uno de nuestros módulos, donde puedes obtener un drive y se comparte automáticamente entre los participantes. Así que tenemos archivos, tenemos comandos, y así sucesivamente. Aquí hay una demo de nuevo de Dropbunk ejecutándose en mi máquina y VPS. Así que editamos en la carpeta, recibimos una invitación, presionamos el trackpad demasiado fuerte, y entonces probablemente puedas imaginar lo que sucede. Casi suena divertido cuando no lo haces, cuando lo muestras.

OK, sí, nos unimos, vamos a la cosa, hacemos clic al azar. ¿Qué está pasando? ¿Llaves? Bien, sí, lo que sucede a continuación es que creo archivos y se sincronizan, puedes imaginar. Conoces archivos. Sí. Así que estoy llamando a esto peer SDK, no sabemos realmente cómo llamarlo todavía, porque realmente no es una cosa todavía, pero es un esfuerzo que queremos hacer. Peer en este caso es lo que escuchaste a Dave tal vez hablar ayer, que es una especie de capa de distribución y el tiempo de ejecución para gran parte de esto. Incluso hasta desplegar tu app, sucede en peer-to-peer, lo que significa que no está restringido por firewalls y todo eso. Tenemos algo de tecnología de perforación de agujeros, se llama, que encuentra una manera a través de todos los routers comunes y todo. Así que eso es realmente donde peer-to-peer brilla, cuando hay un caso de si Internet se cae, pero las personas todavía están juntas, encienden Bluetooth, todavía pueden compartir los mensajes en Bluetooth, porque esta es la capa de transporte, toda la matemática detrás de esto todavía funciona.

Para terminar, peer es la plataforma para construir esto, existe, puedes ir a leer los docs, está pasando por una transición, pero está ahí, existe, funciona. Tether es quien paga las cuentas, porque nos gusta esta idea de que las apps deberían poder hacer esto y funcionar así, y ser imparables, es lo que creo. Si quieres seguirme en Mecha, si quieres probar Keet, deberías. Ese es el código. Y luego eso es lo real... Gracias. Gracias a todos. Gran charla, me encantaron algunos de los chistes también. Y hubo muchas cosas que creo que realmente me hicieron pensar sobre los casos de uso y sobre algunos de los desafíos de ingeniería que creo que esto podría generar si estuviera construyendo algo con ello. Y creo que muchas otras personas en el chat también estaban pensando lo mismo.

Una de las primeras cosas es que a menudo estamos pensando en el rendimiento. Lo siento, estamos pensando en dónde viven los datos y asegurándonos de que se mantengan seguros. Una de las líneas que dijiste es, no importa dónde viva un lugar de datos, pero ¿no hay un riesgo de que los datos se pierdan si viven en el hardware de un peer? Tal vez ese hardware se comprometa, alguien deje caer su laptop y un autobús la atropelle. Como, ¿qué pasa entonces? Sí, así que tendrías que... Como para Keet, por ejemplo, puedes tener que usar la misma cuenta en diferentes dispositivos. Así es como estructuramos la cosa. Y luego, quiero decir, puedes trabajar sin servidores, pero añadimos algunos para ser solo como los relays entre cosas. Y como cuando envías un mensaje, no quieres que tu mamá también tenga que tener su teléfono encendido para que reciba el mensaje. Así que tenemos algunos servidores en medio para que simplemente funcione como esperas.

Pero lo importante es que el servidor no tiene... No tiene un rol en una base de datos. Solo tiene algunos datos encriptados que no tiene idea de qué son. Solo que tiene que ir allí, supongo. No, ni siquiera el metadato de eso, sino solo que existe. Y eso en realidad desencadena un seguimiento y esto es de mi parte, lo que significa que cuando estabas dando tu charla, estaba pensando en cada peer siendo un usuario. Pero en este caso, un peer podría ser un servidor que solo está de pie, ayudando a toda la red también. Sí, si tienes una app bastante activa, querrías que un servidor fuera un relay solo por como la usabilidad de las cosas. Pero como dije antes, es importante saber que no es un servidor que mantiene un caché, como sin encriptar o manteniendo una base de datos o algo así. Es solo como mantener datos encriptados que ni siquiera sabe qué son. Es solo como en medio para la usabilidad.

Eso tiene sentido. Y luego esto lleva a una pregunta de seguimiento, cuando hablamos de los peers, hay tantos dispositivos diferentes también. ¿Tiene P2P un efecto negativo en el consumo de energía cuando un dispositivo se convierte tanto en cliente como en servidor? Y esa es una pregunta de Lars, especialmente cuando piensas como mostraste un ejemplo de tener React Native, perdón, tener una app, creo que estaba impulsada por React Native haciendo esto. ¿Tiene un efecto en el consumo de energía o es prácticamente lo mismo que la transferencia de datos desde cualquier lugar? Quiero decir, si estuviera funcionando en segundo plano siempre, por supuesto, habría un efecto de eso, pero no lo hace. Así que las mismas reglas se aplican como a todos los demás en los dispositivos iOS, supongo. Así que en ese caso, no, no creo que haya ninguna, no hay preocupaciones allí, supongo. No lo creo. No conozco ninguna precaución sobre el uso de la batería. No creo que haga más que cualquier otro.

Eso tiene sentido, eso tiene sentido. Y hablaste sobre el servicio de retransmisión también, y creo que el servicio de retransmisión responde a esta siguiente pregunta, pero creo que aún voy a hacerla, que es de Alex Gale. ¿Qué pasa si todos los usuarios están offline, dónde viven los datos entonces? Sí, así que cuando escribes un mensaje, si estás offline, simplemente se queda en tu dispositivo. Aún pasa por las mismas verificaciones para que podamos asegurarnos, si requerimos que un campo sea texto, aún podemos asegurarnos de que se mantenga antes de guardarlo localmente, pero se queda en tu dispositivo. Cuando luego te conectas, si tienes los peers de retransmisión en tu red, probablemente irá allí. Y de lo contrario, simplemente se queda allí hasta que aparece otro peer y luego se transfiere, como guardado desde ambos y se sincroniza. Así que por lo que estoy escuchando, la gente tiene que pensar en sus casos de uso. ¿Para qué están construyendo? ¿Cuántos servidores de retransmisión van a necesitar? ¿Quieren habilitar que alguien pueda tener la desconexión? Y todo depende del caso de uso y para qué lo están haciendo en ese sentido. Sí, supongo, imagina un servidor de nodo, si fueras solo tú, no necesitarías ningún relé. Tal vez querrías, como si quisieras, podrías tener tu propio servidor como cliente o un peer también y luego se sincronizaría con el servidor y todo. Pero todo esto es local primero, lo cual fue todo el hype hace unos años. Y todo esto es local primero por defecto, porque así es como funciona. Como guardas localmente, luego se sincroniza con todo allí. Eso tiene sentido. Creo que porque para muchos de nosotros, pasamos tanto tiempo en el paradigma cliente-servidor, ver un modelo completamente diferente, una forma completamente diferente de pensar.

Hay tantas preguntas que el cliente servidor ha sido diseñado para responder y estamos tratando de usar el mismo modelo para responder preguntas en peer to peer cuando es muy, muy diferente.

Y la siguiente pregunta es bastante específica, es sobre glob storage. ¿Cómo funciona eso? ¿Tienes límites en el tamaño de los archivos? ¿Y hay un límite en los anchos de banda de la red P2P? Así que a través de la red peer to peer, y tal vez si estoy construyendo una app que está sobre tu SDK o tal vez usando esa herramienta, ¿hay cosas en las que debería estar pensando, sobre el rendimiento y sobre tal vez configurar algunas de estas?

El primer límite es el propio usuario. Cuando subes esto, tu propio límite local para qué tan rápido puedes hacer eso. Pero luego después de eso, ese es el único límite que veo. Si eres solo uno, es como torrents, todos tienen un amigo que está tratando de descargar archivos por torrent.

Y es lo mismo, cuantos más seeders, mayor es el ancho de banda. Así que imagina a la gente viendo la Copa del Mundo a través de peer to peer o lo que sea. El ancho de banda combinado de todas esas personas es gigantesco, ¿verdad? Y así, en el sentido del servidor, todos estamos limitados por la velocidad de transmisión a ese servidor, hacia y desde ese servidor. Pero en este caso, es simplemente cuantos más, mejor. Cuantas más personas se unan, más rápido será realmente el stream.

Genial, no, eso tiene sentido. Y realmente también, me gusta la forma en que pensaste, te pondremos el micrófono en un segundo, me gusta la forma en que lo explicas, y hablas sobre el hecho de que a medida que la red se hace más grande, muchas de estas preguntas se responden por sí mismas también. Porque si tienes como un millón, 10 millones de peers, la posibilidad es que suficientes se vayan a apagar de repente o desaparezcan de repente. Así que una red de búsqueda es poco probable. Y creo que ahí es donde tener una estrategia de servicio de retransmisión inteligente y luego entender cómo hacer eso podría ser muy, muy interesante. Pero es como, sí, sí, sí, sí.

Adelante. Me encantaría escucharte profundizar. Sí, es solo que no quiero poner demasiado en el servicio de retransmisión. Es como un detalle de implementación, si quieres eso o no en tu app. Así que es solo como una cosa opcional que puedes hacer si quieres la cosa de siempre encendido, siempre transmitiendo. Podrías simplemente elegir no usar un servidor de retransmisión. Eso tiene sentido. Eso tiene sentido. Y, quiero decir, para muchos desarrolladores de JavaScript y TypeScript, siempre nos ha importado la seguridad, pero este año nos ha importado aún más la seguridad.

Así que no hay un servidor que lleve metadatos como ocurre con Signal, por ejemplo. Todavía saben a quién envías los mensajes y cuándo y cosas así. No conocen el contenido, pero aún hay algo que vive en sus servidores. Y ese es el caso de todas las aplicaciones de mensajería, excepto Keed. Con orgullo no queremos tu número de teléfono cuando te registras, por ejemplo. Puedes simplemente comenzar a usar Keed y luego continuar. Así que, en primer lugar, resuelve muchas preguntas de seguridad desde otro ángulo. Y luego las que quedan son como las cosas de ingeniería social, como alguien todavía puede engañarte para que hagas clic en el enlace incorrecto o cosas así.

Así que si alguien obtiene tu dispositivo, están dentro de tu dispositivo, ¿verdad? Pero desde afuera, realmente no hay forma de entrar. Todo está encriptado. Me gusta el hecho de que muchos sistemas distribuidos imponen la seguridad como la base, mientras que muchas veces construimos y luego añadimos seguridad o pensamos en la seguridad. Como todavía estamos pensando en el diseño, pero vino en segundo lugar en lugar de cómo funciona en los sistemas distribuidos también. Así que esto está hablando específicamente sobre la pegatina que mostraste y solo la idea de espacio, ¿verdad? Entonces, los datos que, ¿los datos almacenados o compartidos en los dispositivos de los usuarios están limitados a los espacios de los que forman parte? ¿O toda la red ayuda a distribuir los datos de todos?

Correcto. Sí. Dave asiente. Sí. ¿Es extraño? Bien. Sí. Sí. Quiero decir, podrías construir un sistema que reutilizara los dispositivos de todos como relés, pero no por defecto, supongo. Pero imagina que estás en una sala con 800 personas o algo así. Alguien siempre va a estar en línea, llevando los datos para todos los demás. Así que sí. Ahora tiene sentido. Eso tiene sentido.

Tenemos otro que viene también, que es, ¿cómo aseguran los dispositivos cliente que están sincronizados entre sí? Como nos diste esa buena demostración de, era como un tipo de escritura al estilo de Google Docs, y viste los cursores y algunas reglas son las mismas. Pero si tienes muchos clientes, y estoy seguro de que todos hemos estado allí, es tan divertido, una de mis cosas favoritas que hace mi equipo es, si estamos en línea y todos están en el mismo documento, tenemos un espacio de estacionamiento de cursores para que simplemente elijas tu cursor cuando no estás moviéndote o cuando se pone tan ocupado.

Solo un pequeño aviso para cualquier otra persona. Era como si pudiera volverse sospechoso. Como, ¿por qué hay un cursor en esa palabra? ¿Por qué él... Sí, exactamente. Exactamente. Pero sí, entonces, ¿cómo aseguras que estos clientes estén sincronizados entre sí? ¿Hay alguna regla específica o formas de asegurarse de que el historial, especialmente con cambios y diferencias, no se vuelva demasiado desordenado? Sí, por defecto, todo es un registro de escritura anticipada, se llama. Es como todo lo que sucede va a la misma lista de mensajes. Y cuando los revisamos, terminamos en el mismo punto.

Así que para el ejemplo de los documentos, por ejemplo, solo usas un algoritmo que se basa en no en el contenido del documento, sino en los cambios en el documento. Así que es casi como algoritmos de cambio anidados, casi en ese caso. Y no sé realmente qué usa internamente Yjs, si es transformación operacional o cómo se llama, que es el que creo que Google basó los Google Docs originales. De todos modos, es solo cuestión de no almacenar el texto, sino almacenar los cambios que llevan al texto. Almacenar los cambios. Bueno, ha sido un placer. Y también quiero dar un gran agradecimiento y un enorme reconocimiento. Manejaste los problemas del altavoz realmente, realmente bien. Muchas gracias. ¿Podemos darle una ronda más de aplausos? Gracias.