Nostr como sistema de cache en redes federadas
El protocolo nostr ha demostrado ser exponencialmente útil en diferentes campos. Aunque creo que la comunidad debería seguir priorizando las aplicaciones nativas que aprovechan completamente el protocolo, hay un área que aún vale la pena explorar: Nostr como un sistema de soporte secundario, especialmente en redes descentralizadas.
Federación Light
Al crear la federación de Robosats, nuestro objetivo principal fue mantener la máxima independencia entre los coordinadores. Como resultado, los coordinadores no se comunicaban entre sí; en cambio, la agrupación de datos ocurría a nivel del cliente.
Sin embargo, al requerir que el cliente descargue datos de los coordinadores de manera independiente, la federación presenta problemas de escalabilidad a medida que se unan más coordinadores: aumentando el número de solicitudes que el cliente tenía que gestionar, lo que resultaba en una mala experiencia de usuario y penalizaba a los coordinadores con infraestructura de nivel inferior.
Una solución es agrupar la información de todos los coordinadores en un sistema de caché. Este enfoque asegura que, independientemente del número de coordinadores disponibles, los clientes puedan conectarse a una fuente centralizada, reduciendo el trabajo para los clientes y aligerando la carga para los coordinadores.
Caché descentralizada
Si estás leyendo este documento en esta plataforma, es probable que el término "centralizada" te haya hecho fruncir el ceño. Nosotros buscamos evitar puntos únicos de falla; en su lugar, preferimos que la información sea fácilmente accesible pero descentralizada.
Nuestro concepto se basaba en que los coordinadores operaran sus propios sistemas de caché y establecieran una red de federación, garantizando que los nodos recibieran datos actualizados dinámicamente.
Nostr como sistema de caché
Mientras explorábamos diversas tecnologías, nostr surgió como la opción adecuada. Aquí están las principales razones para nuestra decisión:
Verificación: Todas las notas de nostr están firmadas, permitiendo a los clientes verificar la autenticidad de los datos recibidos y descartar cualquier información no confiable.
Mantenimiento: Robosats puede delegar el mantenimiento de este sistema a otros proyectos de código abierto diseñados para este propósito. Específicamente, optamos por STRFRY (https://github.com/hoytech/strfry) debido a sus robustas capacidades de sincronización de datos utilizando el protocolo negentropy.
Extensión: La flexibilidad de nostr facilita la integración de características adicionales como mensajería privada o notificaciones, aprovechando la infraestructura ya establecida para la federación.
Aislamiento: Nostr opera como una red independiente, permitiendo que el sistema de caché funcione por separado del resto de Robosats. Esta configuración solo requiere un canal de comunicación entre el coordinador y el relay, minimizando las vulnerabilidades a exploits o errores.
Estandarización: Establecer un protocolo de datos permite una integración directa fuera de la federación, permitiendo a otros mercados P2P incluir los órdenes actualizadas de Robosats en sus listados sin preocuparse por modificaciones no autorizadas en los datos o en el servicio.
Nostr como sistema de soporte secundario
Y aún así, Robosats no tiene planes de ser nativo de nostr. Creo que no debería serlo. Robosats sigue comprometido con mantener la independencia de sus coordinadores entre sí y garantizar el más alto nivel de privacidad para el usuario, algo que puede ser difícil de lograr solo a través de nostr.
Esto no implica que Robosats no pueda aprovechar las características únicas de nostr en escenarios específicos o necesidades secundarias, emergiendo hacia algo mejor que la combinación de sus partes.
Containing:Federación LightCaché descentralizada Nostr como sistema de caché Nostr como sistema de soporte secundario
Published:2 mo. ago Tuesday, July 23rd, 2024
Author:
Z
z6MkhZDb...yhteqdn7First Version
Powered by Mintter + The Hypermedia Protocol