Construyendo aplicaciones cifradas de extremo a extremo (Web y React Native)

Así que, hola a todos. Comencemos. Construyendo aplicaciones encriptadas de extremo a extremo. ¿Qué quiero decir con eso? ¿Qué entiendo como una aplicación encriptada 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. Entonces, todos los intermediarios, cualquier tercero, cualquier ISP, las personas que ejecutan el servicio, administrando la database, no pueden leer el contenido.

Y eso puede plantear la siguiente pregunta, ¿por qué hacer esto en realidad? Bueno, para mí, realmente me intrigó cuando usé por primera vez aplicaciones de mensajería como Signal y otras, 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 code es sólido. Y me intrigó desde dos perspectivas, porque como usuario, puedo decidir quién puede realmente leer mis data. Los administradores del servicio no pueden leer los data. Pero también, como alguien que ejecuta servicios y bases de datos, me intrigó mucho la idea de algún tipo de data, como data sensible, que ni siquiera quiero tener acceso. Y con la encriptación de extremo a extremo, básicamente puedes hacer que eso suceda.

Así que, me embarqué en ese camino hace algunos años y comencé a construir aplicaciones encriptadas de extremo a extremo. Y con eso, comencé a trabajar en herramientas. Y obviamente, vinieron con algunos desafíos en términos de UX y architecture, 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 incluso puedes probarla en linny.app. Y lo especial de ella es que es una aplicación de tareas encriptada de extremo a extremo.

Permíteme mostrarte rápidamente. Está construida con Expo. Así que es React y React Native. Se compila para web, se compila para iOS, y aún no lo he configurado, pero también se puede hacer en Android. Y veamos rápidamente aquí, podemos registrarnos, nombre de usuario, contraseña, y podemos iniciar sesión. Tenemos aquí nuestra lista de tareas, podemos agregar elementos. Si miras en el lado derecho, se sincroniza directamente con el otro dispositivo, con la aplicación mobile. Y todo está encriptado 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 encriptada 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, la encriptación de extremo a extremo.

Lo que queremos hacer es enviar data de A a B, y nadie en el medio debería poder leerlo. Y eso es un problema resuelto. Solo defines una clave o generas una clave, encriptas los data. Entonces aquí, por ejemplo, mi lista de tareas, con la clave, obtienes un texto cifrado, lo envías a través de tu servidor. Y si no te importa que el servidor conozca los metadatos, entonces puedes enviar solo el texto cifrado y el texto cifrado no revela nada sobre los data excepto su longitud, que es metadato en ese sentido nuevamente.

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

Pero quiero profundizar un poco más en lo que realmente encriptamos. Porque en comparación con un sistema donde la database es la única fuente de verdad y tienes todos los data allí, es un poco más complicado cuando solo obtienes texto cifrado y bloques encriptados. Porque si tienes una lista de tareas y recibes una solicitud de API para agregar una tarea, en realidad no obtienes eso. Solo recibes información de que hay un nuevo texto cifrado en el servidor. ¿Cómo lo gestionas? Y una forma muy simple y fácil de hacerlo es encriptar con una clave, con una clave de lista de tareas el contenido completo 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 encontrarás con conflictos. ¿Qué haces si diferentes dispositivos crean cambios prácticamente al mismo tiempo en el mismo objeto? Permíteme ilustrarlo con un ejemplo. Digamos que tienes dos líneas de tiempo, dos clientes. Uno agrega una tarea, lo sincronizas. Y luego, básicamente antes de sincronizar nuevamente, cada uno de estos dispositivos realiza un cambio, lo encripta y desea sincronizarlo. Y eso se vuelve realmente complicado porque ¿cómo lo resuelves? Estos diferentes... cuando lo sincronizas. Y afortunadamente, esto también es un problema resuelto. Solo tienes que usar CRDT, tipos de datos replicados sin conflictos. Suena aterrador. Y definitivamente vale la pena hablar de ellos por separado. Pero en pocas palabras, son simplemente estructuras de datos que te permiten sincronizar sin obtener un conflicto.

Y si utilizas 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. Supongamos que tienes un CRDD basado en eventos. Lo que el CRDD tiene que hacer es simplemente resolver y fusionar tus datos de 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 genial para nuestra encriptación de extremo a extremo porque lo que podemos hacer entonces es simplemente encriptar cada cambio por separado. Podemos sincronizarlos. No importa en qué orden lleguen a cada cliente diferente. Pero siempre y cuando cada cliente para la misma lista de tareas, por ejemplo, reciba los mismos eventos, todos terminarán en el mismo estado. Y por eso la encriptación de extremo a extremo y los CRDDs son realmente una combinación perfecta. Es fantástico. Esto desbloquea muchas funcionalidades realmente geniales con aplicaciones encriptadas de extremo a extremo. Y, por supuesto, no tienes que construir estos CRDDs por ti mismo porque mucha gente ya lo ha hecho. Y tenemos bibliotecas que hacen esto. Solo quiero mostrarte una de ellas, Yjs, por ejemplo. No solo puedes operar con JSON en ella, pero es prácticamente lo mismo. Tiene una API un poco diferente. La importas. Puedes crear un documento. El 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. 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 algo genial para cada uno de estos cambios ahora, podemos obtener actualizaciones. Y esto es exactamente lo que queremos cuando pensamos en nuestro sistema encriptado de extremo a extremo. 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 sola actualización en esta biblioteca. Lo cual es realmente, realmente útil.

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

Y por eso el equipo con el que trabajé, simplemente construimos SecSync. Es una biblioteca que sincroniza CLDTs de manera encriptada de extremo a extremo. Y viene con una especificación y un ejemplo de backend, para que puedas adaptarlo tú mismo. Y puedes echarle un vistazo. Pero realmente queríamos 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 utilizando una de estas bibliotecas CLDT, deberías estar listo para fusionar y sincronizar automáticamente tus documentos encriptados de extremo a extremo. En realidad, se volvió un poco más complejo de lo que queríamos.

Quiero decir, se construyó 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 mostrarte lo que probablemente será en un par de semanas. Simplemente usa YGS sync. Y luego pasas el documento. Pasas el ID, lo que debería ser en el servidor. Pasas la clave. Entonces la clave que solo conoces en el cliente, el punto final del web socket. Y deberías estar listo para comenzar. Así que déjame demostrártelo. 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 está completamente aislado. La única diferencia en comparación con los otros componentes que acabamos de manejar a través de un YGS CDT. Y lo que podemos hacer ahora es tener este documento Y. Podemos conectar Y sync. Y de forma predeterminada, se sincroniza, configura el socket web, realiza la sincronización automática y puedes ver los mensajes. Todo se encripta. Porque con tu clave, con cifrados modernos adecuados, básicamente utilizando SORIM en vivo bajo el capó. Y lo que podemos hacer ahora es agregar una tarea y puedes incluso actualizar. Por lo tanto, no solo retransmite los data sino que también tiene esta integración de database donde lo almacena. Entonces, lo único que tienes que hacer es conectarlo y estás listo para tener tus datos encriptados 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 lo utilizas, 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 pedirles a los usuarios que simplemente las recuerden. Cómo crear la clave. Podrías crearla por sí misma. Por lo general, lo que haces es generar un montón de bytes aleatorios. Y no queremos que los usuarios recuerden esto. Esto es bastante terrible. Y de hecho, los usuarios no deberían recordar solo una de estas.

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

Entonces, lo que queremos hacer es construir un armario. Es un concepto en el que tienes una clave con la que cifras otras claves, y estas claves las puedes utilizar para acceder a tus documentos. Así que no hay magia especial detrás de esto. Es bastante simple. Solo creas una clave y cifras tu armario. Armario significa simplemente que cifras un montón de datos, un objeto convertido en cadena, con tu clave de armario, y eso es todo. Y si estás utilizando TRPC o GraphQL o cualquier otra cosa, incluso puedes construir un gancho que lo simplifique a estas dos funciones. O incluso no funciones. Como la función de agregar tarea. Puedes agregar una nueva clave. Y luego puedes acceder a una clave desde el contenido. Y se sincroniza básicamente. Permíteme demostrártelo de nuevo.

Entonces, aquí tenemos, por ejemplo, cada vez que inicias la aplicación, se carga, obtienes el texto cifrado, y 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 agregas una nueva lista de tareas, ejecutamos la clave de agregar elemento y básicamente se creará una nueva estructura , un nuevo armario con la nueva clave allí, y simplemente subes el conjunto completo. Y eso significa que todo sigue cifrado. Porque lo único que envías es el texto cifrado, y el servidor básicamente almacena exactamente un armario por usuario.

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

Entonces, Opaque es una autenticación cliente-servidor basada en contraseñas en la que el servidor nunca obtiene conocimiento sobre la contraseña. Eso fue un artículo hace un par de años, y ahora es un RFC del IETF. Y Facebook realmente construyó una biblioteca Rust para hacer qué? Para construir copias de seguridad cifradas de extremo a extremo basadas en contraseñas para WhatsApp. Y lo mismo, basado en PIN, ahora también se utiliza en el Facebook Messenger para hacer copias de seguridad de tus mensajes que están cifrados de extremo a extremo. Y lo que hicimos es construir estas uniones de TypeScript para que realmente puedas acceder a ella a través de TypeScript. Así que tienes la biblioteca Rust, la compilas a WebAssembly, y luego la escribes 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 brinda una buena base para una clave de sesión compartida entre el cliente y el servidor de manera segura, y eso es increíble. Pero hay un hecho interesante sobre Opaque. También nos brinda una clave de exportación al registrarnos. Esta es una clave sólida que se puede utilizar para cifrado o incluso para firmar. Y algo genial al respecto es que cada vez que vuelves a iniciar sesión con el mismo nombre de usuario y contraseña, el servidor nunca obtiene el conocimiento sobre la contraseña y cómo reconstruir , pero también obtienes la misma clave de exportación nuevamente. Y eso significa que podemos usar esta clave para bloquear nuestro armario.

Y para resumir rápidamente esto, por supuesto, hay algunas matemáticas interesantes detrás. Utiliza OPRF, por lo que funciones pseudoaleatorias inconscientes, pero a un alto nivel puedes construir una API, y esto es lo que hicimos en LINI, y puedes verlo 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 que van y vienen en este proceso. Probablemente no valga la pena profundizar en esto en detalle, pero está abstraído de una manera que cualquier desarrollador puede 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. Entonces, si inicio sesión como Alice, Google se quejará de mi contraseña no tan segura, 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 en el fondo, porque lo que realmente está sucediendo, tu contraseña se ejecuta a través de Argon2, que es un mecanismo de hash de contraseñas, que tú probablemente uses en el servidor normalmente, pero en este caso lo usamos en el cliente, luego es a través de una función de hash a curva convertida en punto elíptico, y luego cada inicio de sesión, tú obtienes una nueva sal básicamente, o un nuevo factor, antes de que se envíe al servidor, y esto es por qué cada inicio de sesión es aleatorio, 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 obtendrás la clave de exportación nuevamente, y será exactamente la misma clave de exportación, y esto es por qué es tan bueno para construir estos armarios, porque simplemente podemos bloquearlos.

Sí, Google se queja de nuestra contraseña nuevamente, y luego nuevamente, 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 un asunto elegante, pero lo que obtienes nuevamente es esta clave de exportación, C24q y bla, bla, bla.

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 code, y todo es, no tienes que saber matemáticas ni nada, simplemente puedes construirlo, o ir a 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 armario, desbloquearlo y acceder a tus documentos. Pero dijimos que queremos construir algo colaborativamente, y esto es lo que también admite Lini.

Puedes compartir la invitación. Básicamente, queremos llegar a un punto en el que otra persona con su propio armario y tal vez diferentes permisos también pueda acceder al mismo documento. ¿Cómo lo hacemos? Bueno, si tienes un sistema de invitaciones, simplemente lo amplías. Por ejemplo, si tienes invitaciones por enlace. La invitación por enlace puede ser simplemente la URL con una barra diagonal y luego tienes un token que el servidor entiende para darte acceso a esos data.

Un dato interesante sobre las URL es que en realidad podríamos ocultar una clave en la parte del hash. Porque, dato curioso, ¿sabías que la parte del hash nunca se envía al servidor? Si tomas esta URL, la pones en el navegador y presionas enter, la parte del hash solo se queda en el cliente. Y esto es realmente, realmente útil para construir esta compartición de enlaces con cifrado de extremo a extremo en una aplicación.

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

Sin embargo, hay una cosa. Probablemente no quieras poner la clave real en una URL que compartas, tal vez en Slack o en un correo electrónico, y así sucesivamente. Puedes idear esquemas más inteligentes. Y de hecho, hice esto en Linne, así que si revisas el código fuente, está descrito y documentado. Pero desafortunadamente, se me acaba el tiempo, así que esta tiene que ser una historia para otra ocasión. Mira la charla de seguimiento. En realidad, tengo la intención de escribir mucho sobre esto en los próximos meses, porque estuve muy inmerso en el tema en los últimos dos años y ahora quiero compartir todas estas lecciones aprendidas. Pero lo que quería mostrarte con esta charla es que ya existen herramientas o sistemas que podemos usar, bibliotecas que podemos usar, como Opaque y Zexion, y así sucesivamente, que facilitan mucho la construcción de aplicaciones cifradas de extremo a extremo. Pueden ser simples. Solo tienen authentication y enlaces de invitación. Pero ya es bastante poderoso. Y si tienes un subconjunto de data que te importa y que debe estar cifrado de extremo a extremo en tu aplicación, es posible que esté bien hacer solo eso.

Y sí, por supuesto, puede ser mucho más avanzado. Pero es realmente un agujero de conejo, si piensas en la recuperación de cuentas, cómo hacerlo, 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 emocionarte un poco con esto y que investigues un poco más. Y si quieres, estaré en la sesión de preguntas y respuestas. Háblame. Hazme preguntas. Contáctame en Twitter, en BlueSky, en Macedon. Encantado de hablar sobre esto. Y sí, si lo construyes y necesitas ayuda, también ofrezco consultoría en esta área. Definitivamente, este es 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 hacer esta primera pregunta por separado, la voy a combinar con 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 amenazas que quieras establecer. Por ejemplo, déjame darte un ejemplo del mundo real. Si tengo una aplicación donde mis usuarios se comunican con su médico, podría ser completamente aceptable compartir los pacientes 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, podría ser data que vale la pena encriptar. Porque en Austria, incluso tienes requisitos legales para asegurarte de que se envíe de manera segura. Y aunque no sea necesario encriptarlo de extremo a extremo, puedes hacerlo. Y eso te evitará filtrar los data si tienes un texto y la database se filtra. Y esto tal vez se relacione con el modelo de amenazas.

Es como si no me importara mucho la NSA y demás. Probablemente puedan tener conocimiento cero. No, no conocimiento cero. Hay estos ataques. Pueden atacar mi teléfono y probablemente no tenga oportunidad de defenderme. Pero lo que me preocupa es que se filtre mi propia database. Esto sí puede suceder y lo vemos. Tenemos muchas filtraciones y ocurre todo el tiempo. Entonces, incluso con una filtración, los datos encriptados están protegidos. Sí. De miradas indiscretas. Muy importante. La siguiente pregunta es sobre los CRDTs y cómo interactúan con la state management. ¿Cómo los integrarías en una aplicación que utiliza, por ejemplo, Redux? Eso es muy complicado. Yo diría que podrías combinar Redux para hacerlo, ya que, en un nivel alto, Redux es simplemente un sistema basado en eventos. Entonces, puedes, donde envías una acción. Así que podrías hacer las actualizaciones a tu state management en el Reduxer. Y sí, eso podría funcionar.

Simplemente, Yjs tiene esta API Mutable, así que simplemente muta el documento y listo. AutoMerge en sí mismo es inmutable, diseñado. Entonces, si te gusta este patrón, es posible que estés mucho más satisfecho con AutoMerge. Sí. Tiene sentido. Realmente me gusta este.

¿Puede un desarrollador sin un título en ciencias de la computación crear soluciones encriptadas de extremo a extremo con confianza? Sí y no. Quiero decir, creo que puedes hacerlo, si te vas a un nivel lo suficientemente alto y confías en los autores de las bibliotecas, sí, definitivamente puedes hacerlo. Lo he mostrado aquí y hay otros frameworks como Chess o algo así que te permiten hacerlo en una API de alto nivel. Pero sí, realmente necesitas ir a un nivel 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 de no crear tu propia criptografía. Pero luego, si nadie lo hace, no avanzamos y no obtenemos más aplicaciones que lo utilicen. También hubo esta cita de un criptógrafo muy famoso. Lo dijo en Twitter. Es como si estuviera feliz si tenemos más sistemas encriptados de extremo a extremo rotos en lugar de no tenerlos en absoluto. Interesante. Introducir un poco de competencia. Sí. Quiero decir, cuanto más los tengas, generalmente mejoran. Sí. Y no es solo un punto de falla. Sí. Un poco relacionado con eso, mencionaste YJS y mostraste un par de logotipos. ¿Cuáles son algunas alternativas que la gente debería revisar? Bueno, están YJS, AutoMerge, LoRa.

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

En realidad, hay una pregunta sobre local-first, ¿conoces algo llamado P2P Panda y en general, cómo se integra eso? 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 mucha gente trabajando en ello. Hace dos semanas, hubo una conferencia sobre local-first en Berlín. Estuve allí y soy parte de esta community. Sí. Y P2P Panda es un proyecto muy emocionante, pero no lo he visto utilizado en producción en ningún lugar. Interesante. Aún no. Pero están trabajando en ello y tienen algunos conceptos muy interesantes.

Es fascinante que básicamente local-first, encriptación de extremo a extremo y CRDTs, van muy bien de la mano. Mucha gente simplemente construye todo. Hay mucha superposición. 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 más personas conscientes de su propia data privacy. Hoy en día, hay muchas regulaciones que surgen.

Tenemos un caso de uso interesante, que es, ¿cómo manejas los datos de consulta de filtro ? Por ejemplo, para la búsqueda, ¿tienes que enviar todos los datos al cliente para que pueda ser desencriptado y filtrado? Sí. Así es. El enfoque más simple en la actualidad probablemente es 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 una búsqueda de texto completo. Pero por supuesto, podrías idear esquemas donde uses... Quiero decir, hay encriptación homomórfica, que aún es muy lenta.

Pero podrías idear índices. No es un problema fácil si realmente quieres abordarlo. Excepto que el más fácil es simplemente tener que hacer data localmente y luego permitir buscarlo.

Bastante justo. Tenemos muchas más preguntas. Pero los dejaré ir, porque casi es hora del almuerzo y tengo que hacer algunos anuncios más.

Una última cosa, ¿hay algún recurso que recomendarías para que las personas aprendan más sobre 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í. Comparten sus lecciones aprendidas en su blog. Están a la vanguardia. Parece que están cinco, diez años por delante del resto. Mantente atento a Signal. Buen signal.

Pero sí. 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 lo encontrarás. Nickgraf.com.

Muchas gracias por tu tiempo, Nick. Ha sido un placer tenerte aquí. Por favor, aplaudan a Nick.