Nostr ha recibido mucha atención y entusiasmo desde su reciente incorporación a la lista de plataformas sociales alternativas cuya promoción está prohibida en Twitter. Y también está ganando terreno a medida que queda claro que la compra de Twitter por parte de Elon Musk no ha cambiado nada fundamentalmente sobre la libertad de expresión en la plataforma: los usuarios son sigue siendo prohibido por razones inconsistentes y arbitrarias, y la gente está buscando una alternativa descentralizada que sea No es algo como Mastodon, donde un operador de servidor todavía tiene la capacidad de controlar tu identidad.
A pesar de la atención reciente, el protocolo Nostr y la implementación del primer servidor de retransmisión fueron creados a fines de 2020 por el desarrollador fiatjaf. Antes del gran estallido de atención, era solo un protocolo de nicho silencioso que simplemente intentaba ser una solución ligera a los problemas de Twitter y Mastodon. En ambos sistemas, su identidad/nombre de usuario es simplemente algo controlado por quien ejecuta el servidor. El hecho de que Mastodon sea un sistema federado con múltiples servidores diferentes que se comunican entre sí no cambia fundamentalmente esa realidad. Cualquiera que sea el servidor que use para alojar una cuenta tiene el control total de si puede usarlo o no. Incluso ejecutando su propio servidor, otros operadores de servidores pueden incluir en la lista blanca o negra qué servidores podrán comunicarse con los suyos. Esto ha llevado a una gran cantidad de particiones en el”Fediverso”de diferentes servidores Mastodon y hace que la idea de simplemente ejecutar su propio servidor no tenga sentido. En última instancia, aún puede ser censurado por otros operadores de servidores, evitando que sus usuarios vean su contenido en su feed.
El principal diferenciador entre Nostr y algo como Mastodon es que, en lugar de usar un nombre de usuario propiedad de un operador de servidor, cada usuario utiliza un par de claves pública/privada para manejar esa función. Eso es algo que un operador de servidor no puede simplemente arrebatarte o bloquearte. Este es uno de los componentes básicos sobre los cuales se construye el protocolo general de Nostr.
El siguiente es”eventos”. Este es el tipo de objeto/dato básico utilizado por los clientes y los servidores de retransmisión a los que se conectan los clientes para enviar y recuperar mensajes. La idea general del protocolo es que los clientes envían eventos a los servidores de retransmisión, quienes a su vez los almacenan y los indexan, y otros clientes pueden comunicarse con los servidores de retransmisión para solicitar los eventos que han recibido y almacenado. En el NIP 01 original, se definen tres tipos de eventos diferentes:
0: envía metadatos sobre un usuario, como nombre de usuario, imagen, biografía, etc. 1: envía mensajes de texto y contenido básico 2: recomienda servidores de retransmisión para que las personas que siguen al creador del evento se conecten a
Todos los eventos son estructurado de una manera específicamente definida. Incluyen la clave pública del creador, una marca de tiempo de cuándo se crearon, su tipo (o tipo en la especificación), la carga útil del contenido y una firma del creador del evento. También pueden tener etiquetas que hagan referencia a otros eventos o usuarios, y tener un valor de ID que es un hash de todo excepto la firma del creador (similar a un TXID para transacciones de Bitcoin). Esto le permite garantizar que el propietario de la clave pública dentro de este realmente creó un mensaje al verificar la firma (y la persona que posee esa clave si no está comprometida), y garantizar que el mensaje no se modificó después ellos lo firmaron Al igual que no puede alterar una transacción de Bitcoin después de que se haya firmado sin anularla, no puede alterar un evento de Nostr después de que el creador lo haya firmado sin que sea un fraude evidente.
El sistema de tipos de eventos se amplió sustancialmente desde ese NIP original. Hay un tipo de evento para mensajes directos cifrados, que establece una clave compartida al combinar la clave privada del remitente con la clave pública del receptor, lo que da como resultado la misma clave que obtendría al combinar la clave pública del remitente con la clave privada del receptor (así es como BIP 47 y Silent Payments funcionan). También hay tipos para eventos reemplazables y eventos efímeros. En el caso de un evento reemplazable (obviamente), están diseñados para que el creador original del evento pueda firmar uno nuevo para reemplazar al anterior. Los servidores de retransmisión que sigan la especificación eliminarán automáticamente el evento anterior de su almacenamiento y comenzarán a entregar las versiones más nuevas a los clientes una vez que las reciban. Los eventos efímeros están diseñados para que se transmitan a cualquier persona que se suscriba a su creador cuando se envían a la retransmisión, pero se supone que los servidores de retransmisión no los almacenan. Esto crea la posibilidad de que los mensajes sean vistos solo por personas cuando están en línea durante su transmisión. Incluso hay un tipo de evento para indicar una reacción (como me gusta o emojis) a los eventos de otras personas.
Hablando de esto último, los eventos también pueden contener etiquetas. Actualmente existen tipos de etiquetas para eventos (para hacer referencia a un evento Nostr exacto), claves públicas (para etiquetar o hacer referencia a otros usuarios) y asuntos (para emular funciones, como asuntos de correo electrónico). Todos estos pueden incluir punteros a servidores de retransmisión específicos desde los que se pueden obtener los datos para que los usuarios puedan interactuar entre servidores, es decir, un usuario que publica su contenido en un servidor de retransmisión puede interactuar y hacer referencia al contenido creado por otro usuario que publica en un servidor de retransmisión diferente de una manera que permite a cualquier usuario obtener coherentemente todo el hilo de interacciones en el orden correcto y sin una gran complejidad para averiguar dónde encontrar los datos relevantes.
Dentro del NIP original, se especifica cómo deben interactuar los clientes con los servidores de retransmisión a través de una estructura de datos/mensaje de suscripción que incluye filtros para los eventos que el cliente está interesado en recibir. Esos filtros pueden especificar las claves públicas de los usuarios, eventos exactos, tipos de eventos e incluso períodos de tiempo específicos en los que los quieren según los criterios anteriores. Incluso puede enviar prefijos de claves públicas o ID de eventos, como”1xjisj…”. y recibir cualquier evento o eventos de una clave pública que comience con esa cadena corta (esto puede ser útil para ocultar de un servidor de retransmisión lo que realmente desea ver).
En general, el protocolo es un esquema generalizado muy básico para pasar mensajes entre usuarios que cubre aspectos importantes, como garantizar la integridad de los mensajes y quién los envió con el uso de identidades de clave pública, mientras también facilita la infraestructura en el back-end para servidores de retransmisión que pueden ser extremadamente centralizados o permitir que un usuario ejecute su propio servidor de retransmisión personal, todo mientras interactúan sin problemas entre sí y no causan un caos masivo en caso de que un usuario sea expulsado de un servidor de retransmisión. Pueden pasar a otro o ejecutar el suyo propio y su eliminación de la plataforma del servidor anterior no les hace perder su identidad digital o seguidores porque aún mantienen el control sobre su clave privada y los usuarios pueden autenticar eso cuando los encuentran en otro lugar.
Los servidores de retransmisión también pueden funcionar como quieran. Pueden operar de forma gratuita, pueden cobrar micropagos para publicar o descargar mensajes, y hay incluso un NIP por requerir una prueba de trabajo estilo hashcash para enviar un mensaje. Pueden ser un único servidor de retransmisión para alojar y entregar solo sus publicaciones a otros usuarios, o pueden ser un servidor que se ejecuta a gran escala, como Twitter o Reddit (los clientes pueden mostrar y organizar la información como quieran, lo que permite emular esencialmente cualquier red social). plataforma de medios que existe hoy en día). Todo esto puede interoperar sin problemas y sin poder excluir a un usuario. Puede evitar que publiquen contenido en su servidor de retransmisión, pero, en última instancia, no puede evitar que vean el contenido que aloja en su servidor de retransmisión ni impedir que otros usuarios encuentren su contenido en otros servidores.
Es un protocolo muy simple con un gran espacio de diseño abierto para que las personas lo construyan, lo que garantiza que los usuarios siempre puedan interactuar entre sí, independientemente de qué operadores de servidores de retransmisión individuales elijan alojar o no. Esta es a la vez su mayor fortaleza y su mayor debilidad. Si bien garantiza la libertad para que los desarrolladores construyan sin restricciones estrictas por un protocolo complicado, también hay muchos problemas con los que se encontrará inherentemente que no son manejados por el protocolo en sí.
En el próximo artículo que escribo, abordaré algunos de los problemas que veo que ocurren y las posibles soluciones, pero por ahora, solo diré que en términos de la simplicidad del diseño y las posibilidades que se abre para que la gente lo construya, Nostr ha hecho un muy buen trabajo, considerando que es la creación de una persona y solo un puñado de personas realmente han contribuido a la especificación del protocolo hasta ahora.
Esta es una publicación invitada de Shinobi. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.