Construyendo Aplicaciones con Cifrado de Extremo a Extremo (Web & React Native)

Entonces, hola a todos. Comencemos. Construyendo aplicaciones cifradas de extremo a extremo. ¿Qué quiero decir con eso? ¿Qué entiendo por una aplicación cifrada de extremo a extremo? Básicamente, una aplicación donde puedes tener múltiples clientes, pueden ser tus dispositivos, pueden ser dispositivos de otros usuarios, y puedes colaborar. Y el contenido solo es conocido por estos participantes. Así que, todos los intermediarios, cada tercero, cada ISP, las personas que están ejecutando el servicio, gestionando la base de datos, no pueden leer el contenido.

Y eso podría plantear la siguiente pregunta, ¿por qué hacer esto realmente? Bueno, para mí, realmente me intrigó cuando usé por primera vez aplicaciones de mensajería como Signal y así sucesivamente y me di cuenta, wow, en realidad soy yo, puedo estar seguro de que el contenido solo puede ser leído por mí si el código es sólido. Y me intrigó desde dos perspectivas, porque como usuario, puedo decidir quién puede realmente leer mis datos. Los administradores del servicio, no pueden leer los datos. Pero también, como alguien que ejecuta servicios y bases de datos, realmente me intrigó la idea de algún tipo de datos, como datos sensibles, a los que ni siquiera quiero tener acceso. Y con el cifrado de extremo a extremo, básicamente puedes hacer que eso suceda.

Así que, seguí ese camino hace un par de años y comencé a construir aplicaciones cifradas de extremo a extremo. Y con eso, comencé a trabajar en herramientas. Y obviamente, vinieron con un par de desafíos en términos de UX y arquitectura, porque muchas cosas son diferentes. Y hoy, quiero compartir estas lecciones. Y para hacer eso, sentí que quería construir algo realmente práctico o mostrar algo práctico. Y para procrastinar, construí esta aplicación llamada Linny, que está en GitHub, es de código abierto, y puedes incluso probarla en linny.app. Y lo interesante de esto es que es una aplicación de tareas cifrada de extremo a extremo.

Así que déjame mostrarte rápidamente. Está construida con Expo. Así que es React y React Native. Se compila para la web, se compila para iOS, y aún no lo he configurado, pero puede hacer Android también. Y veamos rápidamente aquí, podemos registrarnos, nombre de usuario, contraseña, y podemos iniciar sesión. Aquí tenemos nuestra lista de tareas, podemos agregar elementos. Si miras al lado derecho, se sincroniza directamente con el otro dispositivo, con la aplicación móvil. Y todo está cifrado de extremo a extremo. Pero lo especial de esto es que también podemos crear enlaces de invitación, copiar el enlace e ir a otro usuario. El usuario puede aceptar la aplicación, la invitación, y compartimos esta lista de tareas cifrada de extremo a extremo y podemos colaborar en ella. Y lo que quiero hacer ahora con esta charla es básicamente guiarte a través de cómo llegué allí. Así que comencemos con el núcleo de esto, el cifrado de extremo a extremo.

Lo que queremos hacer es, queremos obtener datos de A a B, y nadie en el medio debería leerlos. Y eso es un problema resuelto. Simplemente defines una clave o generas una clave, cifras los datos. Así que aquí, por ejemplo, mi to-do, con la clave, obtienes un texto cifrado, lo envías a través de tu servidor. Y si no te importa los metadatos que un servidor conoce, entonces puedes simplemente enviar el texto cifrado y el texto cifrado no revela nada sobre los datos excepto su longitud, que es metadatos en ese sentido nuevamente.

Y en el otro extremo, si tengo la clave, puedo simplemente descifrarlo y tener los datos. Y aunque hay muchos detalles, todos estos están resueltos, y solo tienes que escribir y elegir los algoritmos correctos y pista, pista. Puedes simplemente usar bibliotecas para hacer eso. Llegaremos allí en un momento.

Pero quiero profundizar un poco más en lo que realmente ciframos. Porque en comparación con un sistema donde la base de datos es la única fuente de verdad y tienes todos los datos allí, es un poco más complicado cuando solo obtienes texto cifrado y bloques cifrados. Porque si tienes una lista de tareas, y recibes una solicitud de API para agregar una tarea, en realidad no obtienes eso. Solo obtienes información de que hay un nuevo texto cifrado como servidor. Entonces, ¿cómo gestionas eso? Y una forma muy simple y fácil de hacer eso es simplemente cifrar con una clave, con una clave de lista de tareas, todo el contenido de la lista de tareas y enviarlo. Y eso funciona. Y para algunas aplicaciones, eso es definitivamente suficiente. Si solo necesitas hacer eso, genial.

Pero si quieres construir algo que funcione de manera colaborativa y en tiempo real, eso no será suficiente. Porque rápidamente te encuentras con conflictos. ¿Qué haces si diferentes dispositivos crean prácticamente al mismo tiempo cambios en el mismo objeto? Permíteme ilustrar con un ejemplo. Digamos que tienes dos líneas de tiempo, dos clientes. Uno agrega una tarea, la sincronizas. Y luego, básicamente antes de sincronizar nuevamente, cada uno de estos dispositivos, haces un cambio, lo cifras, y quieres sincronizarlo. Y eso se vuelve realmente complicado porque ¿cómo resuelves eso? Estas diferentes... cuando lo sincronizas. Y afortunadamente, este también es un problema resuelto. Solo tienes que usar CRDTs, conflict-free replicated data types. Suena aterrador. Y definitivamente vale la pena una charla por sí mismos. Pero en resumen, son solo estructuras de datos que te permiten sincronizar sin nunca tener un conflicto.

Y si usas estos, resuelves el problema de los conflictos y puedes construir algo en tiempo real de manera colaborativa. Permíteme ilustrarlo con nuestro ejemplo de los eventos. Digamos que tienes un CRDD basado en eventos. Lo que el CRDD tiene que hacer es simplemente resolver y fusionar tus datos de una manera que no importe en qué orden lleguen los eventos. Siempre se resolverán al mismo estado. Y si tienes eso, básicamente tienes un CRDD. Y eso es realmente, realmente genial para nuestro cifrado de extremo a extremo porque lo que podemos hacer entonces es simplemente cifrar cada cambio por separado. Podemos sincronizarlos. No importa en qué orden lleguen a cada cliente diferente. Pero mientras cada cliente para la misma lista de tareas, por ejemplo, reciba los mismos eventos, todos terminan en el mismo estado. Y es por eso que el cifrado de extremo a extremo y los CRDDs son realmente una combinación hecha en el cielo. Es fantástico. Esto desbloquea una gran usabilidad con aplicaciones cifradas de extremo a extremo. Y por supuesto, no tienes que construir estos CRDDs por ti mismo porque mucha gente ya lo hizo. Y tenemos bibliotecas que hacen esto. Solo quiero mostrarte una de ellas, Yjs, por ejemplo. No solo puedes operar con JSON en ella, sino que es prácticamente lo mismo. Tienes una API un poco diferente. La importas. Puedes crear un documento. Documento es esto. Piensa en ello como un repositorio de GitHub, y puedes hacer cambios en él. Y luego básicamente todos se sincronizan. Y luego podemos ver en este documento, quiero este espacio de tareas. Eso debería ser como un objeto, como un mapa. Puedes crear una nueva tarea, establecer las propiedades y agregarla a la lista de tareas. Y una gran cosa para cada uno de estos cambios ahora, podemos obtener actualizaciones. Y esto es, cuando pensamos en nuestro sistema cifrado de extremo a extremo, exactamente lo que queremos. Porque podemos obtener actualizaciones, y también podemos aplicar actualizaciones. Y tienes cosas realmente geniales como, incluso puedes tomar todo el documento, ya sabes.

Actualizaciones. Si tienes un sistema basado en eventos, eso podría convertirse en una larga lista de cambios. Puedes tomar un documento y codificarlo como una actualización en esta biblioteca. Lo cual es realmente, realmente útil.

Y eso significa, como- Así que tenemos la parte de CADD. Has visto que no es tan complicado. Solo manejas diferentes APIs y gestionas datos, y puedes hacer que funcione. Pasemos a la parte de cifrado. Y esta es la parte que en realidad es bastante genérica.

Y es por eso que el equipo con el que trabajé, simplemente construimos SecSync. Es una biblioteca que sincroniza CLDTs de manera cifrada de extremo a extremo. Y viene con una especificación y un backend de ejemplo, para que puedas adaptarlo por ti mismo. Y puedes revisarlo. Pero realmente queríamos hacer que la parte del front-end fuera especialmente muy, muy simple. Solo tienes hooks, como use YGS sync o use AutoMerge sync. Y lo conectas. Y si estás usando una de estas bibliotecas CLDT, deberías estar listo para ir y automáticamente fusionar y sincronizar tus documentos cifrados de extremo a extremo. En realidad, se volvió un poco más complejo de lo que queríamos.

Quiero decir, fue construido para un caso de uso específico, porque también queríamos tener permisos y snapshots. Pero cuando construí Linny para esta presentación, me di cuenta de que en realidad debería ser esta API. Y prometo, bueno, tengo la intención de simplificar la API a esto. Así que déjame guiarte a través de lo que probablemente será en un par de semanas. Solo usa YGS sync. Y luego pasas el documento. Pasas el ID, lo que debería ser en el servidor. Pasas la clave. Así que la clave que solo conoces en el cliente, el endpoint del web socket. Y deberías estar listo para ir. Así que déjame probar esto. Aquí tenemos Linny abierto.

Pero no lo hemos conectado a la sincronización en tiempo real de la lista. Puedes ver esto. Si agrego esta tarea aquí y actualizo, desaparecerá. Porque nunca se almacenó en ningún lugar. Y este es todo el componente de la lista de tareas. Este componente completamente aislado. La única diferencia en comparación con los otros componentes que acabamos de gestionar para declarar a través de un YGS CDT. Y lo que podemos hacer ahora es que tenemos este documento Y. Podemos conectar Y sync. Y de inmediato, se sincroniza, configura el web socket, hace la sincronización automática, y puedes ver los mensajes. Cifra todo. Porque con tu clave, con cifrados modernos adecuados, básicamente usando live SORIM bajo el capó. Y lo que podemos hacer ahora es que podemos agregar una tarea, e incluso puedes actualizar. Así que no solo retransmite los datos, sino que también tiene esta integración de base de datos donde los almacena. Así que lo único que tienes que hacer es conectarlo y estás listo para tener tus datos cifrados de extremo a extremo. Y cada vez que haces un cambio, básicamente envías un nuevo mensaje con un nuevo texto cifrado. Y eso básicamente resolvió nuestro problema.

Si tienes esto y si lo usas, ya puedes construir aplicaciones cifradas de extremo a extremo. {{^}}Si tienes la clave. Y eso nos lleva al siguiente gran tema de esta charla, que es cómo gestionamos esta clave. La gestión de claves es un problema complicado en el cifrado de extremo a extremo.

No puedes pedir a los usuarios que simplemente recuerden estas. Cómo crear la clave. Podrías crearla por sí misma. Usualmente lo que haces es simplemente generar un montón de bytes aleatorios. Y no queremos que los usuarios recuerden estos. Esto es bastante terrible. Y de hecho, los usuarios no deberían recordar solo uno de estos.

Si quieres colaborar con otros, queremos asegurarnos de que cada lista de tareas tenga su propia clave para que no expongamos los datos realmente a otros usuarios. Así que necesitamos gestionar un montón de claves. Aquí solo tenemos dos. Pero, ¿cómo hacemos esto? Bueno, es bastante simple. Podemos simplemente construir un locker.

Así que lo que queremos hacer es construir un locker. Es un concepto de tener una clave donde cifras otras claves, y estas claves puedes usarlas para acceder a tus documentos. Así que no hay magia especial detrás de esto. Esto es bastante simple. Simplemente creas una clave y cifras tu locker. Locker significa simplemente que cifras un montón de un blob, un blob en formato de cadena, con tu clave de locker y eso es todo. Y si estás usando TRPC o GraphQL o lo que sea, incluso puedes construir un hook que realmente lo reduzca a estas dos funciones. O ni siquiera funciones. Como la función de añadir tareas. Puedes añadir una nueva clave. Y luego puedes acceder a una clave desde el contenido. Y básicamente se sincroniza. Permíteme demostrar esto de nuevo.

Así que aquí tenemos, por ejemplo, cada vez que inicias la aplicación, se carga, obtienes el texto cifrado, y todo esto se hace automáticamente, y lo que obtienes son las claves. El contenido.

Lo descifra, y solo tienes que proporcionar la clave. Y si añades una nueva lista de tareas, ejecutamos la clave de añadir ítem, y básicamente se creará una nueva estructura, un nuevo locker con la nueva clave allí, y simplemente subes todo. Y eso significa que todo sigue cifrado. Porque lo único que envías es texto cifrado, y el servidor básicamente para cada usuario almacena exactamente un locker.

Sí. Eso es bastante genial. Así que logramos reducir nuestro problema de gestión de claves a recordar una clave, lo cual aún no es lo suficientemente bueno. Porque lo que realmente queremos es que las personas puedan simplemente iniciar sesión con nombre de usuario y contraseña. No deberían necesitar recordar esta clave. Y permíteme presentarte una solución que puede ayudarte a hacer esto, que es Opaque.

Así que Opaque es una autenticación cliente-servidor basada en contraseña con el servidor nunca obteniendo conocimiento sobre la contraseña. Eso fue un artículo hace un par de años, y ahora es un RFC por el IETF. Y Facebook de hecho construyó una biblioteca en Rust para hacer qué? Para construir copias de seguridad basadas en contraseña cifradas de extremo a extremo para WhatsApp. Y lo mismo, basado en PIN, ahora también se usa en el Facebook Messenger para hacer copias de seguridad de tus mensajes que están cifrados de extremo a extremo. Y lo que hicimos fue construir estos enlaces de TypeScript para que pudieras acceder a ellos a través de TypeScript. Así que tienes la biblioteca Rust, la compilas a WebAssembly, y luego la tipeas y así sucesivamente. Así que queríamos hacer que Opaque fuera realmente, realmente accesible para nuestros propios casos de uso pero también para todos los demás.

Pero ¿qué nos da esto? ¿Qué nos da la autenticación cliente-servidor? Por supuesto, nos da una buena base para una clave de sesión compartida entre el cliente y el servidor de una manera segura, y eso es increíble. Pero hay un hecho interesante sobre Opaque. También nos da una clave de exportación en el registro. Así que esta es una buena, sólida clave que puedes usar para cifrado o incluso para firma. Y lo genial de esto es que cada vez que inicias sesión nuevamente con el mismo nombre de usuario y contraseña, el servidor nunca obtiene el conocimiento sobre la contraseña y cómo reconstruirla, pero también obtienes la misma clave de exportación de vuelta. Y eso significa que podemos usar esta clave para asegurar nuestro locker.

Y para pasar rápidamente por esto, por supuesto hay algunas matemáticas interesantes bajo el capó. Utiliza OPRF, así que Funciones Pseudo Aleatorias Oblivias, pero a un alto nivel puedes construir una API, y esto es lo que hicimos en LINI, y puedes verificar esto en el repositorio de código abierto, solo tienes que llamar a la función registrar, pasar el nombre de usuario y la contraseña, y lo que obtienes es la clave de exportación y el resultado. Bajo el capó, hay como dos solicitudes yendo y viniendo en este proceso. Probablemente no valga la pena entrar en detalle, pero está abstraído de una manera que cada desarrollador puede realmente usar esto. Y bajo el capó, si lo miras, por ejemplo, si entramos en este proceso, registramos la clave de exportación, porque realmente quiero mostrarte que es exactamente la misma. Así que si inicio sesión como Alice, Google se quejará de mi contraseña no tan fuerte, pero luego si miras las solicitudes de red, hay un montón de cosas, todo está codificado en Base64, tiene que ver con curvas elípticas bajo el capó, porque lo que realmente está sucediendo, tu contraseña se ejecuta a través de Argon2, que es un mecanismo de hash de contraseña, que probablemente uses en el servidor usualmente, pero en este caso lo usamos en el cliente, luego es a través de una función de hash a curva convertida a punto elíptico, y luego cada inicio de sesión, básicamente obtienes una nueva sal o un nuevo factor, antes de que se envíe al servidor, y esto es por qué cada inicio de sesión está aleatorizado, y es realmente difícil atacar esto a menos que tengas una computadora cuántica. Y lo que obtienes es esta clave de exportación, en este caso comienza con C24q, y esto fue el registro, pero podemos pasar por el mismo proceso, más o menos, es un poco diferente, pero muy similar en ese sentido, y obtienes la clave de exportación nuevamente, y será exactamente la misma clave de exportación, y por eso es tan genial para construir estos lockers, porque podemos simplemente asegurarlos.

Sí, Google se queja de nuestra contraseña nuevamente, y luego otra vez, se envía un montón de cosas, estas curvas elípticas, puntos, pero en ningún momento, y hace un intercambio de Diffie-Hellman, es todo material sofisticado, pero lo que obtienes de nuevo es esta clave de exportación, C24q y yada, yada, yada.

Y como se mencionó, esto básicamente nos permitió hacer toda la gestión de claves, resolver la gestión de claves para nuestra aplicación en un par de cientos de líneas de código, y es todo, no tienes que saber matemáticas ni nada, solo puedes construirlo, o entrar en la aplicación y copiar lo que necesitas.

Pero hay una última cosa que nos falta, porque hasta ahora, esto funciona muy bien para construir una aplicación donde puedes colaborar con tus propios dispositivos. Puedes iniciar sesión desde diferentes dispositivos, diferentes navegadores, y siempre obtienes la misma clave abierta, y con eso, puedes obtener el locker, desbloquearlo y acceder a tus documentos. Pero dijimos que queremos construir algo colaborativo, y esto es lo que Lini también soporta.

Puedes compartir la invitación. Así que básicamente queremos llegar a un punto donde alguien más con su propio locker y tal vez diferente acceso también pueda acceder al mismo documento. ¿Cómo hacemos esto? Bueno, si tienes un sistema de invitaciones, solo lo extiendes. Por ejemplo, si tienes invitaciones por enlace. La invitación por enlace puede ser solo la URL con barra diagonal invitación, y luego tienes un token que el servidor entiende para darte acceso a esos datos.

Un hecho interesante sobre las URLs es que en realidad podríamos ocultar una clave en la parte de hash. Porque dato curioso, ¿sabías que la parte de hash nunca se envía al servidor? Si tomas esta URL, la pones en el navegador y presionas enter, la parte de hash solo permanece en el cliente. Y esto es realmente, realmente agradable para básicamente construir esta UX de compartir enlaces con aplicación cifrada de extremo a extremo.

Y luego básicamente en el otro cliente, en este caso, el que acepta la invitación, podemos simplemente sacar el parámetro de hash, en este caso la clave. Podemos aceptar la invitación del documento, en este caso usando TRPC con el token original. No la clave, sino el token para aceptar la invitación. Y luego una vez que sabemos que fue aceptada, simplemente la agregamos a nuestro propio locker. ¡Voila! Y así es como puedes gestionar invitaciones en un sistema cifrado de extremo a extremo.

Hay una cosa, sin embargo. Probablemente no quieras poner la clave real en una URL que compartas, tal vez en Slack o un correo electrónico o algo así. Puedes idear esquemas que sean un poco más inteligentes. Y de hecho hice esto en Linne, así que si revisas el código fuente, está descrito y está documentado. Pero desafortunadamente, se me acabó el tiempo, así que esto tiene que ser una historia para otro momento. Mira la charla de seguimiento. De hecho, tengo la intención de bloguear mucho sobre esto en los próximos meses, porque estuve profundamente en el agujero del conejo en los últimos dos años y ahora realmente quiero compartir todas estas lecciones aprendidas. Pero lo que quería mostrarte con esta charla es que en realidad ya hay herramientas, o sistemas, que podemos usar, bibliotecas que podemos usar, como Opaque y Zexion y así sucesivamente, que hacen que sea realmente, realmente fácil construir aplicaciones cifradas de extremo a extremo. Pueden ser simples. Solo tienen autenticación y enlaces de invitación. Pero ya es bastante poderoso. Y si tienes un subconjunto de datos que te importa que debería estar cifrado de extremo a extremo en tu aplicación, podrías estar bien solo haciendo eso.

Y sí, por supuesto, puede ser mucho más avanzado. Pero realmente es un agujero de conejo, si piensas en la recuperación de cuentas, cómo hacer eso, y rotaciones de claves y permisos que están criptográficamente asegurados, puedes profundizar mucho. Pero lo que quería mostrar es que también puede ser muy simple y poderoso. Y espero haber logrado entusiasmarte un poco con esto y que te adentres un poco más. Y si quieres, estaré en el Q&A. Habla conmigo. Hazme preguntas. Envíame un mensaje en Twitter, en BlueSky, en Macedon. Encantado de hablar sobre ello. Y sí, si lo construyes y necesitas ayuda, también estoy haciendo consultoría en esta área. Este es definitivamente el trabajo más emocionante que estoy haciendo. Y sí, espero que esto haya sido interesante. Espero que hayas disfrutado la charla. Y al menos hayas aprendido algo. Muchas gracias por escuchar.

En lugar de hacerte esta primera pregunta por sí sola, voy a agruparla con algunas otras. Básicamente, la gente quiere saber sobre el concepto de encriptación. ¿Cuándo debería hacerlo? ¿Debería hacerlo para todos los datos de mi aplicación? ¿Cuándo es demasiado? Bueno, creo que realmente depende de... ¿Cuáles son los beneficios? Creo que realmente depende del modelo de amenaza que quieras establecer.

Por ejemplo, déjame hacer un ejemplo del mundo real. Si tengo una aplicación donde mis usuarios se comunican con su médico, podría estar completamente bien compartir los pacientes que están relacionados con un médico y cuál es su relación cuando tienen una cita. Pero si están compartiendo información médica, estos podrían ser datos que valga absolutamente la pena encriptar. Porque en Austria, incluso tienes requisitos legales para asegurarte de que esto se envíe de manera segura. Y aunque no necesite ser encriptado, encriptado de extremo a extremo, puedes hacerlo. Y eso te salvará de realmente filtrar los datos si tienes un texto y la base de datos se filtra. Y esto tal vez se refiere al modelo de amenaza.

Es como, no me importa mucho la NSA y demás. Probablemente puedan conocimiento cero. No, no conocimiento cero. Hay estos ataques. Pueden atacar mi teléfono y probablemente no tenga ninguna posibilidad de defenderme contra eso. Pero lo que me importa es como filtrar mi propia base de datos. Esto es sí, esto puede suceder y lo vemos. Tenemos muchas brechas y sucede todo el tiempo. Así que incluso con una filtración, los datos encriptados están protegidos. Sí. De miradas indiscretas.

Muy importante. La siguiente pregunta es sobre CRDTs y cómo interactúan con la gestión de estado. ¿Cómo lo integrarías en una aplicación usando como un Redux, por ejemplo? Eso es muy complicado. Yo diría, bueno, podrías, podrías combinar realmente Redux para hacer el, así que tienes, quiero decir, Redux a un alto nivel, es solo un sistema basado en eventos. Así que puedes, donde empujas una acción. Así que podrías en el Reduxer básicamente hacer las actualizaciones a tu gestión de estado. Y sí, eso podría funcionar.

Solo, Yjs tiene esta API Mutable, así que simplemente muta el documento y listo. AutoMerge por sí mismo es inmutable, diseñado. Así que si te gusta este patrón, podrías estar mucho más feliz con AutoMerge. Sí. Tiene sentido. Realmente me gusta este.

¿Puede un desarrollador sin un título en ciencias de la computación crear con confianza soluciones encriptadas de extremo a extremo? Sí y no. Quiero decir, creo que puedes, si vas lo suficientemente alto y confías en los autores de las bibliotecas, sí, definitivamente puedes hacerlo. Lo he mostrado aquí y hay algunos otros frameworks como Chess o así que te permiten hacerlo en una API de alto nivel. Pero sí, realmente necesitas ir lo suficientemente alto y básicamente confiar en estos autores para hacer lo correcto. Supongo que la gente no debería estar escribiendo su propia encriptación a mano la mayor parte del tiempo. Sí. Probablemente. Probablemente. Sí.

Quiero decir, está esta cosa, no hagas tu propio cripto. Pero luego, si nadie lo hace, no avanzamos y no obtenemos más aplicaciones llegando allí. Así que también hubo esta cita de un criptógrafo muy famoso. Lo dijo en Twitter. Es como, estaría feliz si tuviéramos más sistemas encriptados de extremo a extremo rotos en lugar de no tenerlos en absoluto. Interesante. Como introducir un poco de competencia. Sí. Quiero decir, cuanto más los tienes, mejoran generalmente. Sí. Y no es solo un punto de fallo.

Sí. Un poco como a raíz de eso, mencionaste YJS y mostraste un par de logos. ¿Cuáles son algunas alternativas que la gente debería revisar? Bueno, está YJS, AutoMerge, LoRa.

LoRa está, creo, todavía en alfa. Estas son, por sí mismas, bibliotecas CRDT, pero luego hay frameworks como Chess o Eberloo, que gestionan CRDTs y toda la parte de encriptación y local-first, de la cual ni siquiera he hablado todavía, en un solo framework. Y si quieres construir aplicaciones, sí, podrían ser una muy buena opción a un nivel alto.

Hay en realidad una pregunta sobre local-first, y ¿estás al tanto de algo llamado P2P Panda y, en general, cómo se integra? Sí. Conozco P2P Panda. Así que, conozco local-first. Local-first es la idea de que básicamente puedes ejecutar todo localmente y sincronizarlo. Y también tienes este concepto de aprovechar la encriptación de extremo a extremo opcionalmente.

Quiero decir, es más una idea y tenemos a mucha gente construyendo hacia ella. Así que, hace dos semanas, hubo la conferencia local-first en Berlín. Estuve allí y soy parte de esta comunidad. Sí. Y P2P Panda es un proyecto muy emocionante, pero no lo he visto usado en producción en ningún lugar. Interesante. Aún no. Pero están trabajando en ello y tienen un par de conceptos muy interesantes.

Es como, lo fascinante es que básicamente local-first, encriptación de extremo a extremo y CRDTs, van muy bien de la mano. Así que, mucha gente simplemente construye todo. Hay mucho solapamiento. Sí. Pero no tienes que construir una aplicación local-first para que sea encriptada de extremo a extremo y no tienes que ser encriptado de extremo a extremo para ser local-first. Simplemente encajan tan bien juntos que mucha gente va en esa dirección. Especialmente con mucha más gente siendo consciente de su propia privacidad de datos. Hoy en día, hay muchas regulaciones surgiendo.

Tenemos una pregunta interesante sobre casos de uso, que es, ¿cómo manejas los datos de consulta de filtro? Así que, por ejemplo, para buscar, ¿tienes que enviar todos los datos al cliente para que puedan ser desencriptados y filtrados? Sí. Así que, sí. El enfoque más simple hoy en día probablemente es simplemente tener los datos en el cliente y luego se convierte en una aplicación local-first. Y luego simplemente tienes, por ejemplo, SQLite en el cliente y haces búsqueda de texto completo. Pero, por supuesto, podrías idear esquemas donde uses... Quiero decir, hay encriptación homomórfica, que todavía es muy lenta.

Pero podrías idear índices. No es un problema fácil si realmente quieres abordarlo. Excepto que lo más fácil es simplemente tener que hacer los datos localmente y luego permitir buscar en ellos.

Justo. Tenemos muchas más preguntas. Pero voy a dejarlos ir, porque estamos casi en el almuerzo y tengo que hacer algunos anuncios más.

Una última cosa es, ¿hay algún recurso que recomendarías para que la gente aprenda más sobre ya sea las bibliotecas de las que hablaste o la encriptación de extremo a extremo en general?

Buena pregunta. El blog de Signal, por ejemplo, es increíble. El trabajo de métricas. Signal. Signal. Sí. Tienen un blog y a menudo comparten sus lecciones aprendidas. Están a la vanguardia de esto. Se siente como si estuvieran cinco, diez años por delante del resto. Mantén un ojo en Signal. Buena señal.

Pero sí. De hecho, solo envíame un mensaje en Mastodon, Blue Sky o Twitter.

Oh, ¿cuál es tu usuario de Mastodon? Está en todas partes. Nick Graf. Nick Graf. Sí. Solo ve a nickgraf.com y luego puedes encontrarlo. Nickgraf.com.

Muchas gracias por tu tiempo, Nick. Ha sido un placer tenerte. Por favor, un aplauso para Nick.