El nuevo año de las redes sociales: principios de Nostr y cuestiones clave de gestión
Durante años se han explorado nuevos diseños de redes sociales bajo la Quinta Derecha, sin signos de adopción masiva. El año pasado, con el desarrollo continuo de la tecnología de cifrado y las preocupaciones sobre la adquisición de Twitter por parte de Musk, la red social descentralizada abrió nuevas oportunidades.
Los problemas que estas redes sociales están tratando de resolver podrían incluir fortalecer la censura, hacer más flexible la moderación de contenidos y reducir el poder de las grandes empresas de redes sociales para dar forma y rastrear lo que la gente habla en línea, entre otras cosas.
A medida que surgen y crecen nuevas plataformas, la elección de redes sociales alternativas a menudo conlleva consideraciones políticas. Sitios como Getr, Parler, Gab y Truth Social atienden a la derecha al promocionarse como alternativas de libertad de expresión a Twitter.
Lo que vamos a discutir hoy es Nostr-damus, un nuevo protocolo de redes sociales que ha recibido mucha atención recientemente y es algo innovador. Estos incluyen los principios técnicos de Nostr, las cuestiones de gestión clave que deben resolverse y cómo incentivar al relevo para que siga funcionando.
Descripción general de Nostr
Lanzado en 2020, Nuestra es un protocolo descentralizado que permite a los usuarios poseer sus identidades y verificar publicaciones mediante firmas digitales mediante cifrado de clave pública-privada. Luego, estas publicaciones se propagan a una red interconectada de servidores. El protocolo no utiliza una cadena de bloques, que en los primeros experimentos se descubrió que era demasiado lenta para las redes sociales. Pero existen similitudes estructurales, y Nostr encontró un nicho temprano en el mundo de las criptomonedas con su espíritu libertario y de código abierto.
Mastodonte contra Nostr
El protocolo Nostr y el primer servidor de retransmisión fueron creados por el desarrollador fiatjaf a finales de 2020. Antes de ganar una atención generalizada, Nostr era un protocolo de nicho silencioso que pretendía ser una solución ligera a los problemas de Twitter y Mastodon.
Mastodon, una red de código abierto fundada en 2016, permite a cualquiera configurar un servidor. El diseño a menudo se describe como “federado” y puede o no caer dentro de la línea borrosa de “Web3”, dependiendo de cómo se defina. Mastodon permite a los usuarios unirse a comunidades seleccionadas con reglas de moderación de contenido personalizadas. En la actualidad, el número de usuarios registrados ha alcanzado los 200w+ y se ha convertido en un refugio seguro para liberales, periodistas y académicos.
In Twitter y Mastodonte sistemas, las identidades/nombres de usuario están controlados por quien ejecuta el servidor.
La principal diferencia en Nostr es que cada usuario usa un par de claves pública/privada para manejar la función en lugar de usar un nombre de usuario propiedad del operador del servidor, lo que hace que Nostr sea resistente a la censura. Este es uno de los pilares básicos para construir todo el protocolo Nostr.
Evento: Este es el tipo de objeto/datos básico utilizado por los clientes y los servidores de retransmisión a los que se conectan para enviar y recuperar mensajes. La idea general del protocolo es que los clientes envían eventos a un servidor de retransmisión, que luego los almacena e indexa, y otros clientes pueden comunicarse con el servidor de retransmisión para solicitar los eventos que han recibido y almacenado. En el original PIN 01, se definieron tres tipos de eventos diferentes:
- Enviar metadatos sobre el usuario, como nombre de usuario, imagen, biografía, etc.
- Enviar SMS y contenido básico
- Recomendar el servidor de retransmisión para que las personas que siguen al creador del evento se conecten.
Todos los eventos están estructurados de una manera específicamente definida. Incluye la clave pública del creador, la marca de tiempo de creación, el tipo (o tipo en especificación), la carga útil del contenido y la firma del creador del evento. Alternativamente, puede haber etiquetas que hagan referencia a otros eventos o usuarios y que tengan un valor de ID que sea un hash de todo excepto la firma del creador (similar al TXID de una transacción de Bitcoin).
Esto permite a los usuarios verificar la firma (y quién es el propietario de la clave, si no ha sido comprometida) para garantizar que el mensaje fue realmente creado por el propietario de la clave pública que contiene y que el mensaje no ha sido alterado desde que firmaron. él.
Así como una transacción de Bitcoin no se puede cambiar después de haber sido firmada sin invalidarla, un usuario no puede cambiarla después de que el creador de la transacción haya sido firmada. Nuestra evento lo ha firmado sin que sea un fraude evidente.
El sistema de tipo de evento se ha ampliado considerablemente desde el original. PNI. Existe un tipo de evento para mensajes cifrados directos que crean un secreto compartido al combinar la clave privada del remitente con la clave pública del receptor, cuyo resultado es el mismo que se obtiene al combinar la clave pública del remitente con la clave privada del receptor. son iguales (así es como funcionan BIP 47 y los pagos silenciosos).
También hay tipos de eventos reemplazables y efímeros. En el caso de los eventos reemplazables (obviamente), están diseñados para que el creador original del evento pueda firmar un nuevo evento para reemplazar el anterior. Los servidores de retransmisión que sigan esta especificación eliminarán automáticamente los eventos antiguos de su almacenamiento y comenzarán a ofrecer versiones más nuevas a los clientes al recibirlos.
Los eventos efímeros están diseñados de tal manera que cuando se envían a un repetidor, se transmitirán a cualquiera que se suscriba a su creador, pero el servidor de repetidor no debe almacenarlos. Esto crea la posibilidad de que sólo aquellos que estén en línea vean el mensaje durante su transmisión. Incluso hay un tipo de evento para representar reacciones a los eventos de otras personas (como me gusta o emojis).
Hablando de la última pregunta, los eventos también pueden contener etiquetas. Actualmente, existen tipos de etiquetas para el Evento (refiriéndose a un evento exacto de Nostr), Llave pública (para etiquetar o referir a otro usuario), y Tema (para imitar la funcionalidad, como el asunto de un correo electrónico).
Todos estos pueden incluir punteros a servidores de retransmisión específicos desde los cuales se obtienen datos para que los usuarios puedan realmente interactuar en diferentes servidores, es decir, un usuario publica su contenido en un servidor de retransmisión, contenido con el que puede interactuar y hacer referencia otro usuario en un servidor de retransmisión diferente. servidor de retransmisión para que cualquier usuario pueda obtener de forma coherente todo el hilo de interacción en el orden adecuado sin tener que averiguar dónde se encuentran los datos relevantes en una gran cantidad de operaciones complejas.
En el original PNI, se proporcionó una especificación de cómo un cliente interactúa con un servidor de retransmisión suscribiéndose a una estructura de mensajes/datos que incluye filtros para qué eventos el cliente está interesado en recibir. Estos filtros pueden especificar la clave pública del usuario, el evento exacto, el tipo de evento o incluso un período de tiempo específico en el que desean basarse en criterios previos.
Los usuarios pueden incluso enviar claves públicas o prefijos de ID de eventos, como “1xjisj…” y recibir uno o más eventos de una clave pública que comience con esa cadena corta (esto es útil para ocultar a los servidores de retransmisión lo que realmente desea ver). .
En general, el protocolo es un esquema general muy simple para pasar mensajes entre usuarios, que cubre cosas importantes como garantizar la integridad de los mensajes y usar identidades de clave pública para enviar mensajes, al mismo tiempo que facilita la infraestructura final. Los servidores de retransmisión pueden estar altamente centralizados o permitir que los usuarios ejecuten sus propios servidores de retransmisión personales mientras interactúan perfectamente entre sí y sin causar un caos masivo en caso de que a los usuarios se les prohíba usar un servidor de retransmisión.
Pueden mudarse a otro servidor o ejecutar el suyo propio, y no perderán sus identidades digitales ni sus seguidores al desconectarse de la plataforma de su servidor anterior, ya que aún mantienen el control de sus claves privadas y los usuarios pueden usarlas en otro lugar para autenticarse. ellos cuando los encuentren.
Los servidores de retransmisión también pueden ejecutar lo que quieran: funcionamiento gratuito, cobrar una pequeña tarifa por publicar o descargar mensajes e incluso tener un NIP que requiere prueba de trabajo estilo hash cash para enviar mensajes.
Pueden ser un servidor de retransmisión único que aloja publicaciones y las pone a disposición solo de otros usuarios o un servidor que opera a escala, como Twitter o Reddit (los clientes pueden mostrar y organizar la información como deseen, lo que permite simular cualquier red social). Todos estos interoperan a la perfección sin bloquear a los usuarios.
Cuestiones clave de gestión que abordará Nostr
Las claves públicas/privadas del usuario son una parte integral de cómo funciona Nostr como protocolo. Esto actúa como un vínculo estrecho entre el usuario real y cómo otros lo identifican, evitando que cualquier servidor de retransmisión desvincule esas dos cosas, es decir, dando el identificador de alguien a otro usuario. También soluciona uno de los mayores problemas de la plataforma: la falta de control sobre la propia identidad del usuario.
Pero esto también introduce nuevos problemas: la clave se puede perder, la clave puede verse comprometida y, si ocurre tal evento, el usuario no podrá pedir ayuda.
Esto inevitablemente requerirá un esquema para que los usuarios cambien de un par de claves a otro de manera verificable y detectable y para que interactúen con otros usuarios a través del protocolo. Todo el protocolo se basa en demostrar que un evento provino de un usuario específico (clave de identidad), por lo que una vez que la clave de alguien se ve comprometida, todas esas garantías se lanzan por el aire.
Nostr requiere un esquema criptográfico real que vincule la rotación de una clave con otra. El desarrollador fiatjaf ha propuesto una solución básica que podría solucionar este problema. La idea básica es tomar una larga lista de direcciones derivadas de una única semilla maestra y crear un conjunto de claves "ajustadas", similar a cómo los árboles Taproot se comprometen con las claves de Bitcoin.
Taproot toma la raíz Merkle del árbol Taproot y la "agrega" a la clave pública para crear una nueva clave pública. Esto se puede replicar agregando esa raíz de Merkle a la clave privada para obtener una clave privada que coincida con la nueva clave pública. La idea de Fiatjaf es encadenar los compromisos de principio a fin para que cada clave ajustada contenga realmente pruebas de que la siguiente clave ajustada se utilizó para crearla.
Entonces, imagina comenzar con la tecla Z, la última de la cadena. Puedes modificarlo con algo, luego regresar y crear una versión ajustada de la tecla Y usando la tecla ajustada Z (Z' + Y = Y'). Desde aquí, puedes tomar Y' y usarlo para ajustar X (Y' + X = X'). Harías esto hasta la clave A, obtendrías A' y usarías esa clave desde allí. Cuando se rompe, el usuario puede transmitir un evento que contiene la clave A no ajustada y la clave B' ajustada.
Esto contendrá todos los datos necesarios para mostrar que B' se usó para generar A', y el usuario puede dejar de seguir inmediatamente a A' y seguir a B'. Sabrían sin ambigüedades que B' es la siguiente clave para ese usuario y, en su lugar, seguirían esa clave.
Sin embargo, todavía hay algunos problemas con esta propuesta. En primer lugar, todas las claves que se utilizarán deben generarse con anticipación y no hay forma de rotar a un conjunto de claves completamente nuevo. Esto se puede resolver comprometiendo una clave maestra en este esquema que pueda certificar ante notario esta rotación o simplemente generando un conjunto muy grande de claves desde el principio.
Cualquiera de las dos opciones es factible, pero en última instancia requiere mantener seguro la clave raíz o el material de clave y exponer solo las teclas de acceso rápido individuales (Hotkeys) a los clientes de Nostr.
Sin embargo, este esquema no protege a los usuarios ni proporciona mecanismos para la recuperación de la identidad en caso de que el material de clave raíz se pierda o se vea comprometido.
Para analizar las posibles soluciones aquí, otra forma de pensarlo es ajustar una clave a una clave fría maestra que también debe usarse para firmar eventos de una clave a otra rotación. Tiene la clave A', que se obtiene sumando A y M (clave maestra); el evento de rotación será A, M y B' (generado sumando B y M) y la firma de M. M puede ser una clave de umbral de firmas múltiples: dos tercios, tres quintos, etc.
Esto puede agregar redundancia contra pérdidas y proporcionar un mecanismo seguro para la rotación de claves. Esto también abre la puerta al uso de servicios para ayudar con la recuperación o para difundir algunas de estas claves entre amigos de confianza. Ofrece la misma flexibilidad que multifirma en el propio Bitcoin.
PIN26 También es una propuesta que podría resultar muy útil para abordar este problema. Esto especifica una extensión de protocolo para eventos que permite que una firma de una clave autorice a otra clave a publicar eventos en su nombre. El “token” o prueba de firma delegada se incluirá entonces en todos los eventos publicados por la segunda clave pública en nombre de la primera. Incluso puede tener una duración limitada, por lo que los tokens de delegación caducan automáticamente y deben renovarse.
La cuestión de la gestión de claves y la seguridad es un problema muy grande con un espacio de diseño muy grande lleno de compensaciones y puntos débiles. Sin embargo, si Nostr no puede proteger y mantener la integridad de estas identidades para los usuarios, no se adoptará a gran escala un protocolo basado enteramente en pares de claves públicas/privadas utilizadas como identidades.
Ampliación frente a Nostr
Todo el protocolo Nostr depende de que alguien en algún lugar ejecute un servidor de retransmisión. No existe una “red Nostr”, solo relés y clientes conectados a los relés. Es necesario incentivar a las personas para que ejecuten retransmisiones y, en última instancia, esto será una gran parte de hasta qué punto pueden escalar las retransmisiones a largo plazo. A menos que un repetidor de Nostr pueda ser rentable o al menos generar suficiente dinero para cubrir sus propios costos operativos, nunca habrá un repetidor del mismo tamaño que el servidor de Twitter.
Publicidad
Dada la forma en que Nostr funciona como protocolo, bloquear anuncios por completo sería trivial, lo que lo convierte en una solución inviable. Los servidores de retransmisión pueden intentar utilizar la publicidad como modelo de ingresos, que aparentemente es el principal modelo de ingresos para casi todos los servicios gratuitos en línea, pero el problema es que los usuarios básicamente tienen que optar por participar. Los servidores de retransmisión pueden inyectar fácilmente anuncios en los eventos que envían a los clientes. , pero los clientes también pueden filtrar fácilmente eventos publicitarios desde su interfaz de usuario si no fueron creados por la clave pública a la que pretendían suscribirse.
Micropago
Los micropagos son otra solución obvia, especialmente dados los intentos en curso de integrar la Lightning Nuestra red más estrechamente en la aplicación Nostr. Este modelo ofrece mucha flexibilidad en la forma de cargar. Los repetidores pueden cobrar solo por publicar eventos allí, por descargar lecturas de eventos, o una combinación de ambos, ajustando el precio de cada uno en función de la cantidad de recursos que consumen. Sin embargo, es dudoso que este modelo pueda ampliarse a la escala de Twitter.
Los micropagos de contenidos han demostrado su viabilidad en muchos productos de nicho basados en la Lightning Nuestra red, pero hay dos problemas fundamentales a la hora de escalar verdaderamente a una escala global.
En primer lugar, todavía no hay suficiente adopción de Bitcoin. Incluso si todos aceptaran mágicamente pagar por cada pequeña interacción de servicio en Nostr, no habría suficientes personas con bitcoins para respaldar algo tan masivo como Twitter. Los retransmisiones pueden cobrar tarifas de suscripción en moneda fiduciaria, pero estos métodos de pago no permitirán pagar una pequeña tarifa por cada evento publicado o descargado.
En segundo lugar, la gente está realmente acostumbrada a este tipo de servicio gratuito. Esto es exactamente lo que uno esperaría. No creo que los micropagos puedan realmente respaldar la retransmisión a gran escala.
Hay una manera de hacer que los micropagos sean “más estrictos” o más sostenibles sin imponerlos a todas las clases de usuarios que utilizan el relé. Se ha hablado mucho sobre la creación de varias aplicaciones sobre Nostr, excepto el clon de Twitter. GitHub, Wikipedia e incluso Uber.
El último es clave: las expectativas económicas. La gente está muy acostumbrada a pagar una tarifa cuando se anuncia un trabajo en algún lugar o a pagar una tarifa a un operador de mercado cuando piden algo en línea, pero no sirven cosas que creen que deberían ser gratuitas: Google, Twitter. Esto podría proporcionar una manera para que los retransmisores creen un pilar de ingresos sólido para sus usuarios sin crear mucha fricción ni romper las expectativas del usuario potencial promedio.
Si los micropagos también van a ser un factor, los operadores de retransmisión tendrán que ejecutar un nodo Lightning para poder recibir fondos de los usuarios primero. Esto podría potencialmente aumentar los ingresos si se logra una sinergia adecuada con cualquier modelo de micropago implementado por el relevo.
Cuantos más ingresos obtenga un servidor de retransmisión, más liquidez necesitará en Lightning Network para facilitarlo. Si los operadores planifican correctamente cómo implementan o distribuyen la liquidez en la red, el mero hecho de ejecutar un nodo de enrutamiento podría convertirse en sí mismo en un importante generador de ingresos, además de cualquier tarifa cobrada por recibir o transmitir datos a través de retransmisiones.
Conclusión
Proyectos sociales Web3, además de los mencionados Nuestra y Mastodonte, también incluyen proyectos como teleyector y Lente, que no reemplazará rápidamente las plataformas de redes sociales existentes. Según las estadísticas, Twitter tiene cientos de millones de usuarios activos, Facebook tiene miles de millones, pero Mastodonte Sólo tiene 2.5 millones de usuariosy Nuestra solo tiene aproximadamente 220,000 identidades de usuario únicas. Muchos proyectos sociales Web3 enfrentan obstáculos de usabilidad que frenan la adopción masiva.
Los medios y la política son inseparables. A medida que proliferan los proyectos sociales Web3 y la conversación pública se fragmenta en diferentes aplicaciones y protocolos, puede haber resultados políticos. Incluso Messina, que ha abogado durante mucho tiempo por la descentralización de las redes sociales, teme que la descentralización alimente aún más un discurso público que ha estado marcado por la hostilidad mutua y los malentendidos en los últimos años.
EXENCIÓN DE RESPONSABILIDADES: La información de este sitio web se proporciona como un comentario general del mercado y no constituye un consejo de inversión. Le animamos a que haga su propia investigación antes de invertir.
Únase a nosotros para estar al tanto de las novedades: https://linktr.ee/coincu
Harold
Coincú Noticias
Autor
Conocimiento
El nuevo año de las redes sociales: principios de Nostr y cuestiones clave de gestión
Durante años se han explorado nuevos diseños de redes sociales bajo la Quinta Derecha, sin signos de adopción masiva. El año pasado, con el desarrollo continuo de la tecnología de cifrado y las preocupaciones sobre la adquisición de Twitter por parte de Musk, la red social descentralizada abrió nuevas oportunidades.
Los problemas que estas redes sociales están tratando de resolver podrían incluir fortalecer la censura, hacer más flexible la moderación de contenidos y reducir el poder de las grandes empresas de redes sociales para dar forma y rastrear lo que la gente habla en línea, entre otras cosas.
A medida que surgen y crecen nuevas plataformas, la elección de redes sociales alternativas a menudo conlleva consideraciones políticas. Sitios como Getr, Parler, Gab y Truth Social atienden a la derecha al promocionarse como alternativas de libertad de expresión a Twitter.
Lo que vamos a discutir hoy es Nostr-damus, un nuevo protocolo de redes sociales que ha recibido mucha atención recientemente y es algo innovador. Estos incluyen los principios técnicos de Nostr, las cuestiones de gestión clave que deben resolverse y cómo incentivar al relevo para que siga funcionando.
Descripción general de Nostr
Lanzado en 2020, Nuestra es un protocolo descentralizado que permite a los usuarios poseer sus identidades y verificar publicaciones mediante firmas digitales mediante cifrado de clave pública-privada. Luego, estas publicaciones se propagan a una red interconectada de servidores. El protocolo no utiliza una cadena de bloques, que en los primeros experimentos se descubrió que era demasiado lenta para las redes sociales. Pero existen similitudes estructurales, y Nostr encontró un nicho temprano en el mundo de las criptomonedas con su espíritu libertario y de código abierto.
Mastodonte contra Nostr
El protocolo Nostr y el primer servidor de retransmisión fueron creados por el desarrollador fiatjaf a finales de 2020. Antes de ganar una atención generalizada, Nostr era un protocolo de nicho silencioso que pretendía ser una solución ligera a los problemas de Twitter y Mastodon.
Mastodon, una red de código abierto fundada en 2016, permite a cualquiera configurar un servidor. El diseño a menudo se describe como “federado” y puede o no caer dentro de la línea borrosa de “Web3”, dependiendo de cómo se defina. Mastodon permite a los usuarios unirse a comunidades seleccionadas con reglas de moderación de contenido personalizadas. En la actualidad, el número de usuarios registrados ha alcanzado los 200w+ y se ha convertido en un refugio seguro para liberales, periodistas y académicos.
In Twitter y Mastodonte sistemas, las identidades/nombres de usuario están controlados por quien ejecuta el servidor.
La principal diferencia en Nostr es que cada usuario usa un par de claves pública/privada para manejar la función en lugar de usar un nombre de usuario propiedad del operador del servidor, lo que hace que Nostr sea resistente a la censura. Este es uno de los pilares básicos para construir todo el protocolo Nostr.
Evento: Este es el tipo de objeto/datos básico utilizado por los clientes y los servidores de retransmisión a los que se conectan para enviar y recuperar mensajes. La idea general del protocolo es que los clientes envían eventos a un servidor de retransmisión, que luego los almacena e indexa, y otros clientes pueden comunicarse con el servidor de retransmisión para solicitar los eventos que han recibido y almacenado. En el original PIN 01, se definieron tres tipos de eventos diferentes:
- Enviar metadatos sobre el usuario, como nombre de usuario, imagen, biografía, etc.
- Enviar SMS y contenido básico
- Recomendar el servidor de retransmisión para que las personas que siguen al creador del evento se conecten.
Todos los eventos están estructurados de una manera específicamente definida. Incluye la clave pública del creador, la marca de tiempo de creación, el tipo (o tipo en especificación), la carga útil del contenido y la firma del creador del evento. Alternativamente, puede haber etiquetas que hagan referencia a otros eventos o usuarios y que tengan un valor de ID que sea un hash de todo excepto la firma del creador (similar al TXID de una transacción de Bitcoin).
Esto permite a los usuarios verificar la firma (y quién es el propietario de la clave, si no ha sido comprometida) para garantizar que el mensaje fue realmente creado por el propietario de la clave pública que contiene y que el mensaje no ha sido alterado desde que firmaron. él.
Así como una transacción de Bitcoin no se puede cambiar después de haber sido firmada sin invalidarla, un usuario no puede cambiarla después de que el creador de la transacción haya sido firmada. Nuestra evento lo ha firmado sin que sea un fraude evidente.
El sistema de tipo de evento se ha ampliado considerablemente desde el original. PNI. Existe un tipo de evento para mensajes cifrados directos que crean un secreto compartido al combinar la clave privada del remitente con la clave pública del receptor, cuyo resultado es el mismo que se obtiene al combinar la clave pública del remitente con la clave privada del receptor. son iguales (así es como funcionan BIP 47 y los pagos silenciosos).
También hay tipos de eventos reemplazables y efímeros. En el caso de los eventos reemplazables (obviamente), están diseñados para que el creador original del evento pueda firmar un nuevo evento para reemplazar el anterior. Los servidores de retransmisión que sigan esta especificación eliminarán automáticamente los eventos antiguos de su almacenamiento y comenzarán a ofrecer versiones más nuevas a los clientes al recibirlos.
Los eventos efímeros están diseñados de tal manera que cuando se envían a un repetidor, se transmitirán a cualquiera que se suscriba a su creador, pero el servidor de repetidor no debe almacenarlos. Esto crea la posibilidad de que sólo aquellos que estén en línea vean el mensaje durante su transmisión. Incluso hay un tipo de evento para representar reacciones a los eventos de otras personas (como me gusta o emojis).
Hablando de la última pregunta, los eventos también pueden contener etiquetas. Actualmente, existen tipos de etiquetas para el Evento (refiriéndose a un evento exacto de Nostr), Llave pública (para etiquetar o referir a otro usuario), y Tema (para imitar la funcionalidad, como el asunto de un correo electrónico).
Todos estos pueden incluir punteros a servidores de retransmisión específicos desde los cuales se obtienen datos para que los usuarios puedan realmente interactuar en diferentes servidores, es decir, un usuario publica su contenido en un servidor de retransmisión, contenido con el que puede interactuar y hacer referencia otro usuario en un servidor de retransmisión diferente. servidor de retransmisión para que cualquier usuario pueda obtener de forma coherente todo el hilo de interacción en el orden adecuado sin tener que averiguar dónde se encuentran los datos relevantes en una gran cantidad de operaciones complejas.
En el original PNI, se proporcionó una especificación de cómo un cliente interactúa con un servidor de retransmisión suscribiéndose a una estructura de mensajes/datos que incluye filtros para qué eventos el cliente está interesado en recibir. Estos filtros pueden especificar la clave pública del usuario, el evento exacto, el tipo de evento o incluso un período de tiempo específico en el que desean basarse en criterios previos.
Los usuarios pueden incluso enviar claves públicas o prefijos de ID de eventos, como “1xjisj…” y recibir uno o más eventos de una clave pública que comience con esa cadena corta (esto es útil para ocultar a los servidores de retransmisión lo que realmente desea ver). .
En general, el protocolo es un esquema general muy simple para pasar mensajes entre usuarios, que cubre cosas importantes como garantizar la integridad de los mensajes y usar identidades de clave pública para enviar mensajes, al mismo tiempo que facilita la infraestructura final. Los servidores de retransmisión pueden estar altamente centralizados o permitir que los usuarios ejecuten sus propios servidores de retransmisión personales mientras interactúan perfectamente entre sí y sin causar un caos masivo en caso de que a los usuarios se les prohíba usar un servidor de retransmisión.
Pueden mudarse a otro servidor o ejecutar el suyo propio, y no perderán sus identidades digitales ni sus seguidores al desconectarse de la plataforma de su servidor anterior, ya que aún mantienen el control de sus claves privadas y los usuarios pueden usarlas en otro lugar para autenticarse. ellos cuando los encuentren.
Los servidores de retransmisión también pueden ejecutar lo que quieran: funcionamiento gratuito, cobrar una pequeña tarifa por publicar o descargar mensajes e incluso tener un NIP que requiere prueba de trabajo estilo hash cash para enviar mensajes.
Pueden ser un servidor de retransmisión único que aloja publicaciones y las pone a disposición solo de otros usuarios o un servidor que opera a escala, como Twitter o Reddit (los clientes pueden mostrar y organizar la información como deseen, lo que permite simular cualquier red social). Todos estos interoperan a la perfección sin bloquear a los usuarios.
Cuestiones clave de gestión que abordará Nostr
Las claves públicas/privadas del usuario son una parte integral de cómo funciona Nostr como protocolo. Esto actúa como un vínculo estrecho entre el usuario real y cómo otros lo identifican, evitando que cualquier servidor de retransmisión desvincule esas dos cosas, es decir, dando el identificador de alguien a otro usuario. También soluciona uno de los mayores problemas de la plataforma: la falta de control sobre la propia identidad del usuario.
Pero esto también introduce nuevos problemas: la clave se puede perder, la clave puede verse comprometida y, si ocurre tal evento, el usuario no podrá pedir ayuda.
Esto inevitablemente requerirá un esquema para que los usuarios cambien de un par de claves a otro de manera verificable y detectable y para que interactúen con otros usuarios a través del protocolo. Todo el protocolo se basa en demostrar que un evento provino de un usuario específico (clave de identidad), por lo que una vez que la clave de alguien se ve comprometida, todas esas garantías se lanzan por el aire.
Nostr requiere un esquema criptográfico real que vincule la rotación de una clave con otra. El desarrollador fiatjaf ha propuesto una solución básica que podría solucionar este problema. La idea básica es tomar una larga lista de direcciones derivadas de una única semilla maestra y crear un conjunto de claves "ajustadas", similar a cómo los árboles Taproot se comprometen con las claves de Bitcoin.
Taproot toma la raíz Merkle del árbol Taproot y la "agrega" a la clave pública para crear una nueva clave pública. Esto se puede replicar agregando esa raíz de Merkle a la clave privada para obtener una clave privada que coincida con la nueva clave pública. La idea de Fiatjaf es encadenar los compromisos de principio a fin para que cada clave ajustada contenga realmente pruebas de que la siguiente clave ajustada se utilizó para crearla.
Entonces, imagina comenzar con la tecla Z, la última de la cadena. Puedes modificarlo con algo, luego regresar y crear una versión ajustada de la tecla Y usando la tecla ajustada Z (Z' + Y = Y'). Desde aquí, puedes tomar Y' y usarlo para ajustar X (Y' + X = X'). Harías esto hasta la clave A, obtendrías A' y usarías esa clave desde allí. Cuando se rompe, el usuario puede transmitir un evento que contiene la clave A no ajustada y la clave B' ajustada.
Esto contendrá todos los datos necesarios para mostrar que B' se usó para generar A', y el usuario puede dejar de seguir inmediatamente a A' y seguir a B'. Sabrían sin ambigüedades que B' es la siguiente clave para ese usuario y, en su lugar, seguirían esa clave.
Sin embargo, todavía hay algunos problemas con esta propuesta. En primer lugar, todas las claves que se utilizarán deben generarse con anticipación y no hay forma de rotar a un conjunto de claves completamente nuevo. Esto se puede resolver comprometiendo una clave maestra en este esquema que pueda certificar ante notario esta rotación o simplemente generando un conjunto muy grande de claves desde el principio.
Cualquiera de las dos opciones es factible, pero en última instancia requiere mantener seguro la clave raíz o el material de clave y exponer solo las teclas de acceso rápido individuales (Hotkeys) a los clientes de Nostr.
Sin embargo, este esquema no protege a los usuarios ni proporciona mecanismos para la recuperación de la identidad en caso de que el material de clave raíz se pierda o se vea comprometido.
Para analizar las posibles soluciones aquí, otra forma de pensarlo es ajustar una clave a una clave fría maestra que también debe usarse para firmar eventos de una clave a otra rotación. Tiene la clave A', que se obtiene sumando A y M (clave maestra); el evento de rotación será A, M y B' (generado sumando B y M) y la firma de M. M puede ser una clave de umbral de firmas múltiples: dos tercios, tres quintos, etc.
Esto puede agregar redundancia contra pérdidas y proporcionar un mecanismo seguro para la rotación de claves. Esto también abre la puerta al uso de servicios para ayudar con la recuperación o para difundir algunas de estas claves entre amigos de confianza. Ofrece la misma flexibilidad que multifirma en el propio Bitcoin.
PIN26 También es una propuesta que podría resultar muy útil para abordar este problema. Esto especifica una extensión de protocolo para eventos que permite que una firma de una clave autorice a otra clave a publicar eventos en su nombre. El “token” o prueba de firma delegada se incluirá entonces en todos los eventos publicados por la segunda clave pública en nombre de la primera. Incluso puede tener una duración limitada, por lo que los tokens de delegación caducan automáticamente y deben renovarse.
La cuestión de la gestión de claves y la seguridad es un problema muy grande con un espacio de diseño muy grande lleno de compensaciones y puntos débiles. Sin embargo, si Nostr no puede proteger y mantener la integridad de estas identidades para los usuarios, no se adoptará a gran escala un protocolo basado enteramente en pares de claves públicas/privadas utilizadas como identidades.
Ampliación frente a Nostr
Todo el protocolo Nostr depende de que alguien en algún lugar ejecute un servidor de retransmisión. No existe una “red Nostr”, solo relés y clientes conectados a los relés. Es necesario incentivar a las personas para que ejecuten retransmisiones y, en última instancia, esto será una gran parte de hasta qué punto pueden escalar las retransmisiones a largo plazo. A menos que un repetidor de Nostr pueda ser rentable o al menos generar suficiente dinero para cubrir sus propios costos operativos, nunca habrá un repetidor del mismo tamaño que el servidor de Twitter.
Publicidad
Dada la forma en que Nostr funciona como protocolo, bloquear anuncios por completo sería trivial, lo que lo convierte en una solución inviable. Los servidores de retransmisión pueden intentar utilizar la publicidad como modelo de ingresos, que aparentemente es el principal modelo de ingresos para casi todos los servicios gratuitos en línea, pero el problema es que los usuarios básicamente tienen que optar por participar. Los servidores de retransmisión pueden inyectar fácilmente anuncios en los eventos que envían a los clientes. , pero los clientes también pueden filtrar fácilmente eventos publicitarios desde su interfaz de usuario si no fueron creados por la clave pública a la que pretendían suscribirse.
Micropago
Los micropagos son otra solución obvia, especialmente dados los intentos en curso de integrar la Lightning Nuestra red más estrechamente en la aplicación Nostr. Este modelo ofrece mucha flexibilidad en la forma de cargar. Los repetidores pueden cobrar solo por publicar eventos allí, por descargar lecturas de eventos, o una combinación de ambos, ajustando el precio de cada uno en función de la cantidad de recursos que consumen. Sin embargo, es dudoso que este modelo pueda ampliarse a la escala de Twitter.
Los micropagos de contenidos han demostrado su viabilidad en muchos productos de nicho basados en la Lightning Nuestra red, pero hay dos problemas fundamentales a la hora de escalar verdaderamente a una escala global.
En primer lugar, todavía no hay suficiente adopción de Bitcoin. Incluso si todos aceptaran mágicamente pagar por cada pequeña interacción de servicio en Nostr, no habría suficientes personas con bitcoins para respaldar algo tan masivo como Twitter. Los retransmisiones pueden cobrar tarifas de suscripción en moneda fiduciaria, pero estos métodos de pago no permitirán pagar una pequeña tarifa por cada evento publicado o descargado.
En segundo lugar, la gente está realmente acostumbrada a este tipo de servicio gratuito. Esto es exactamente lo que uno esperaría. No creo que los micropagos puedan realmente respaldar la retransmisión a gran escala.
Hay una manera de hacer que los micropagos sean “más estrictos” o más sostenibles sin imponerlos a todas las clases de usuarios que utilizan el relé. Se ha hablado mucho sobre la creación de varias aplicaciones sobre Nostr, excepto el clon de Twitter. GitHub, Wikipedia e incluso Uber.
El último es clave: las expectativas económicas. La gente está muy acostumbrada a pagar una tarifa cuando se anuncia un trabajo en algún lugar o a pagar una tarifa a un operador de mercado cuando piden algo en línea, pero no sirven cosas que creen que deberían ser gratuitas: Google, Twitter. Esto podría proporcionar una manera para que los retransmisores creen un pilar de ingresos sólido para sus usuarios sin crear mucha fricción ni romper las expectativas del usuario potencial promedio.
Si los micropagos también van a ser un factor, los operadores de retransmisión tendrán que ejecutar un nodo Lightning para poder recibir fondos de los usuarios primero. Esto podría potencialmente aumentar los ingresos si se logra una sinergia adecuada con cualquier modelo de micropago implementado por el relevo.
Cuantos más ingresos obtenga un servidor de retransmisión, más liquidez necesitará en Lightning Network para facilitarlo. Si los operadores planifican correctamente cómo implementan o distribuyen la liquidez en la red, el mero hecho de ejecutar un nodo de enrutamiento podría convertirse en sí mismo en un importante generador de ingresos, además de cualquier tarifa cobrada por recibir o transmitir datos a través de retransmisiones.
Conclusión
Proyectos sociales Web3, además de los mencionados Nuestra y Mastodonte, también incluyen proyectos como teleyector y Lente, que no reemplazará rápidamente las plataformas de redes sociales existentes. Según las estadísticas, Twitter tiene cientos de millones de usuarios activos, Facebook tiene miles de millones, pero Mastodonte Sólo tiene 2.5 millones de usuariosy Nuestra solo tiene aproximadamente 220,000 identidades de usuario únicas. Muchos proyectos sociales Web3 enfrentan obstáculos de usabilidad que frenan la adopción masiva.
Los medios y la política son inseparables. A medida que proliferan los proyectos sociales Web3 y la conversación pública se fragmenta en diferentes aplicaciones y protocolos, puede haber resultados políticos. Incluso Messina, que ha abogado durante mucho tiempo por la descentralización de las redes sociales, teme que la descentralización alimente aún más un discurso público que ha estado marcado por la hostilidad mutua y los malentendidos en los últimos años.
EXENCIÓN DE RESPONSABILIDADES: La información de este sitio web se proporciona como un comentario general del mercado y no constituye un consejo de inversión. Le animamos a que haga su propia investigación antes de invertir.
Únase a nosotros para estar al tanto de las novedades: https://linktr.ee/coincu
Harold
Coincú Noticias
Otras publicaciones
Artículos Relacionados
Noticias
Pantera Capital TON Investment es el fondo más grande de la empresa de capital riesgo en el espacio Web3
Noticias
El cierre de BlockFi se llevará a cabo en mayo, los usuarios deberán retirar sus activos antes del 28 de abril
Noticias
El ETF Grayscale Spot Ethereum es ahora la principal prioridad de la empresa
Noticias
El mensaje de phishing de TON engaña a los usuarios con 5000 USDT baratos
Noticias
zkLogin de Sui ahora agrega recuperación de firmas múltiples y soporte para cuentas de Apple
Noticias
El caso de la caja de DEUDA se está volviendo cada vez más complicado con los encubrimientos de la SEC
Noticias
Inversión de Pantera Capital TON impulsada para mejorar las capacidades de pago P2P
Noticias
El 90% de los volúmenes de transacciones de Stablecoin no cuentan con la participación de usuarios reales
Noticias
Un error de dirección provoca una pérdida de 68 millones de dólares para el WBTC y la víctima cae en una estafa de phishing
Noticias
Pantera Capital TON Investment es el fondo más grande de la empresa de capital riesgo en el espacio Web3
Conocimiento
Minería de Bitcoin: ¿Cuánto tiempo se tarda en extraer 1 Bitcoin?
Conocimiento
Posibles candidatos a las elecciones estadounidenses de 2024: ¿quién ganará?
Conocimiento
Predicciones electorales en Estados Unidos: los efectos y la importancia del nuevo presidente de Estados Unidos
Conocimiento
