Nostr Se Está Centralizando. Por Diseño
los fundamentos de Nostr son simples y poderosos. un par de claves, un evento firmado, un relay. los primitivos están perfectamente pensados.
pero hay un problema: la mayoría de las especificaciones se lanzaron antes de que existieran las herramientas para implementarlas correctamente. cada desarrollador de Nostr tuvo que llenar el vacío con lo que tenía a mano. que resultó ser infraestructura centralizada.
no hubo una sola decisión que lo echara a perder, pero el problema es que se acumulan. y estamos reconstruyendo Twitter lentamente a partir de decisiones razonables.
"descentralizado" es un espectro medido por el costo para un adversario motivado de degradar o vigilar la red. ahora mismo, ese costo es vergonzosamente bajo — no porque el protocolo haya fallado, sino porque cada primitivo faltante fue reemplazado por un atajo que se quedó.
01. las listas de relays por defecto son un único punto de falla
cada cliente importante viene con una lista de relays predefinida. Damus, Primal, Amethyst — todos lo hacen. cuando lanzaron, el descubrimiento de relays no existía, así que los desarrolladores pusieron en duro lo que estaba disponible y era confiable. racional. temporal.
excepto que lo temporal se volvió permanente. la red práctica ahora son 10–15 servidores bien conocidos. los operadores lo saben. los gobiernos lo saben. tres relays cumplen con una orden judicial y pierdo acceso de escritura al grafo social que creía que era mío.
un sistema descentralizado con valores por defecto centralizados es un sistema centralizado — solo con más latencia.
02. NIP-65 es correcto. también es ampliamente ignorado.
NIP-65 define dos listas en mi perfil: relays a los que escribo (outbox) y relays de los que leo (inbox). si todos publican en sus propios relays declarados, los datos se distribuyen naturalmente — mis notas viven donde elegí ponerlas. mi cliente busca tus notas en tus relays declarados, no en un índice central. la topología de la red refleja el grafo social.
en la práctica el lado outbox funciona parcialmente. el fallo silencioso es el fallback: si mi relay es lento, el cliente escribe en un relay por defecto sin indicación de que esto ocurrió. el lado inbox es peor — la mayoría de los clientes consultan los mismos 10–15 relays grandes y asumen que mis notas llegaron ahí por replicación. a veces sí. a menudo solo parcialmente.
NIP-65 depende de que los relays se comuniquen entre sí. esa capa de gossip nunca se construyó correctamente. así que los clientes no pueden confiar en que buscar en los relays declarados devuelve un panorama completo — y recurren a los grandes.
lo cual se convierte en una profecía autocumplida. los relays grandes acumulan todo porque los clientes siguen escribiendo ahí como respaldo, haciéndolos más completos, haciéndolos más necesarios. los clientes intentaron aplicar el modelo outbox estrictamente — las notas desaparecían, la gente se quejaba, la aplicación se revirtió. entonces NIP-65 recibe reconocimiento en los readmes y anulación silenciosa en producción.
03. los feeds algorítmicos necesitan a alguien que ejecute el algoritmo
en el momento en que un cliente ofrece feeds inteligentes o descubrimiento, necesita indexar toda la red — o externalizarlo. Primal hace su propio indexado. también yakihonne. los clientes se están convirtiendo en frontends de estos servicios, y mi par de claves no me protege de un feed curado por un proveedor de infraestructura con su propio modelo de negocio y exposición jurisdiccional.
sin distribución adecuada de relays, no puedo hacer descubrimiento desde los bordes — necesito a alguien en el medio con un índice completo. el agregador llena el vacío, se vuelve estructural. el algoritmo vuelve. solo que ahora habla WebSocket.
04. los relays de pago recrean la economía de plataformas
los relays de pago tienen sentido como defensa contra el spam. pero también son puntos de agregación naturales. el contenido de calidad gravita hacia relays con uptime y filtrado. los lectores siguen al contenido. los efectos de red se activan. el mercado de relays de pago se consolidará en un puñado de proveedores dominantes — exactamente como ocurrió con el hosting de email y cada otro protocolo federado que tocó incentivos comerciales.
el operador de relay se convierte en la nueva plataforma. tienen mi IP, mi pago, mi grafo social. he reconstruido Substack en un formato de cable diferente.
05. el spam se resolvió en la capa equivocada
el filtrado de spam a nivel de relay — prueba de trabajo, pago, solo por invitación — tenía sentido en 2022. las herramientas de WoT no existían, los datos del grafo social eran demasiado escasos, y los operadores necesitaban proteger sus recursos en ese momento. así que construyeron puertas. funcionó.
ese es precisamente el problema. una solución que funciona elimina la presión de construir la correcta — filtrado de Web of Trust a nivel de protocolo, criptográfico, portable entre relays. nunca se construyó porque el filtrado a nivel de relay ya "resolvió" el spam. el WoT sigue siendo poco especificado, la mayoría de los clientes lo tratan como opcional, y cada nuevo relay adopta por defecto el mismo patrón de control de acceso.
la respuesta suficientemente buena no solo retrasó la respuesta correcta. la hizo estructuralmente innecesaria — hasta que toda la arquitectura dependió de la solución provisional.
06. los clientes compiten por retención, no por soberanía
los desarrolladores de clientes enfrentan los mismos incentivos que cualquier app social: DAUs, duración de sesión, ingresos. las funciones que importan para la descentralización — diversidad de relays, filtrado WoT, caché local de eventos — son invisibles para mí e imposibles de presentar. las funciones que impulsan la retención — feeds algorítmicos, notificaciones push, onboarding pulido — son fáciles de lanzar y fáciles de justificar.
la soberanía no tiene una métrica. así que se desprioriza en cada sprint hasta que es un toggle en configuraciones que nadie abre. la estructura de incentivos toma esta decisión — no los desarrolladores.
07. el modelo de incentivos está roto por diseño
los operadores de relay y yo queremos cosas diferentes — y el protocolo no reconcilia eso.
el incentivo de un operador es uptime, control de costos, prevención de spam. nada de eso requiere servir mis datos de forma confiable. un relay que silenciosamente descarta eventos de cuentas con poco tráfico sigue siendo comercialmente viable. para el operador, pérdida aceptable. para mí, mi contenido desapareciendo sin explicación.
yo quiero mis datos en mis términos. el operador quiere un negocio sostenible. en ausencia de cumplimiento del protocolo, sus incentivos ganan — ellos controlan la infraestructura.
los relays de pago no arreglan esto. lo que estoy comprando es acceso de escritura, no disponibilidad garantizada. los relays gratuitos tienen el problema inverso — funcionan con buena voluntad, y cuando se acaba el relay se cae y se lleva su historial con él. en ambos casos, no hay garantía criptográfica de que mis datos persistan. estoy confiando en infraestructura de la misma manera que confío en un proveedor de nube — que es exactamente de lo que se suponía que estaba escapando.
08. los desarrolladores no captaron el punto
hay otra capa de fallo que no se discute suficiente — cómo los propios desarrolladores se relacionan con el protocolo.
Nostr resulta ser un backend conveniente. sin base de datos que mantener. sin dolores de cabeza de cumplimiento GDPR. sin sistema de autenticación que construir. publica un evento firmado, deja que los relays manejen el almacenamiento, listo. hay hilos en Stacker News donde los desarrolladores preguntan seriamente si pueden reemplazar su base de datos con un relay de Nostr — usándolo como un almacén de clave-valor personal para apps de notas, sin interés en la resistencia a la censura ni en los grafos sociales. solo "es más fácil que correr Postgres".
esto no está exactamente mal. el protocolo lo permite. pero refleja un patrón: una parte creciente del ecosistema está siendo construida por desarrolladores que descubrieron Nostr como conveniencia de infraestructura, no como un primitivo de resistencia a la censura. el resultado se nota. apps que se conectan a un único relay fijo. clientes que omiten la UX de gestión de claves porque "a los usuarios no les importa". proyectos que usan Nostr para coordinación pero almacenan los datos reales en S3.
incluso hay un repositorio de GitHub — awesome-nostr-possibilities — que existe específicamente porque la gente notó que Nostr estaba siendo tratado como "otro protocolo social más" y nada más. el título del repo es una advertencia: Nostr fallará si se queda solo como otro protocolo de redes sociales. esa advertencia es de 2023. el ecosistema no escuchó.
la apertura del protocolo — la característica que lo hace poderoso — está siendo aprovechada por conveniencia mientras las propiedades que lo hacen significativo se descartan silenciosamente.
la oportunidad perdida es real. Nostr no es un atajo de backend. es infraestructura para un nuevo modelo de confianza — datos firmados, identidad portable, grafos sociales controlados por el usuario. los desarrolladores que lo tratan como un reemplazo de base de datos están construyendo sobre los cimientos sin entender para qué sirven esos cimientos. y cada app que lanzan ignorando la soberanía hace la red un poco más normal, un poco más como lo que ya tenemos.
09. la soberanía real es actualmente una función para usuarios avanzados
aquí es donde el fallo se vuelve estructural de una manera diferente: ahora mismo, la verdadera soberanía de datos en Nostr requiere correr tu propio relay. eso significa un servidor, un dominio, mantenimiento, costo. es alcanzable — pero solo para personas con la profundidad técnica y la motivación para hacerlo.
todos los demás confían en la lista de relays por defecto y lo llaman descentralizado.
el protocolo prometió soberanía a todos los usuarios. lo que entregó es soberanía para quienes están dispuestos a operar infraestructura — y una falsa sensación de ella para todos los demás.
esto no es enteramente un fallo. podría ser en realidad el modelo honesto. no todos los usuarios necesitan el mismo nivel de soberanía, y no todos deberían cargar el mismo peso de infraestructura. pero el ecosistema actual no hace ese tradeoff legible — presenta el uso casual de relays como equivalente al almacenamiento soberano propio, lo cual no lo es.
la versión honesta de Nostr parece escalonada: los usuarios avanzados corren sus propios relays, controlan sus datos de principio a fin, y obtienen garantías criptográficas. todos los demás eligen un relay en el que confían, aceptan el tradeoff, y obtienen al menos una identidad portable y resistencia a la censura en la capa de claves — aunque no en la capa de almacenamiento. eso sigue siendo significativamente mejor que la Web2. pero requiere ser honesto de que la soberanía total no es el valor por defecto, es algo que tienes que construir para ti mismo.
lo que falta es la herramienta para hacer ese camino accesible. un relay personal con un clic. compromisos de almacenamiento verificables sin correr tu propia infraestructura. reputación de operadores de relay basada en WoT para que pueda tomar una decisión de confianza informada en lugar de recurrir a lo que el cliente tiene fijo.
el techo para los usuarios avanzados es alto. el piso para todos los demás es más bajo de lo que debería ser. la brecha entre ellos es donde vive la mayor parte del ecosistema — y donde se esconde la mayor parte de la centralización.
qué necesita cambiar
el filtrado WoT necesita ser el valor por defecto, no una opción. las herramientas existen — NIP-02, NIP-51, puntuación por distancia en el grafo. el vacío es de priorización.
la diversidad de relays necesita ser visible. muéstrame cuántos relays únicos replican mis notas. respondo a señales que puedo ver.
los fallbacks del modelo outbox necesitan ser auditables. si un cliente escribe en un relay por defecto porque el mío era lento, eso debería registrarse y ser visible — no ser una decisión silenciosa en segundo plano.
el camino al almacenamiento soberano propio necesita volverse más fácil. relays personales con un clic, compromisos de almacenamiento verificables, reputación de relays vía WoT — esto baja el piso sin limitar el techo.
el veredicto
cada punto de centralización aquí fue una respuesta racional a una herramienta que faltaba. listas de relays por defecto porque el descubrimiento de relays no estaba listo. agregadores porque el indexado del lado del cliente era demasiado difícil. filtros de spam a nivel de relay porque el WoT no existía. desarrolladores construyendo sobre la conveniencia porque la propuesta de valor más profunda no les era visible.
cada problema resuelto eliminó la presión de construir lo que habría prevenido el siguiente. decisiones estructurales lentas, cada una razonable, acumulándose en algo roto. eso es más difícil de arreglar que la mala intención — porque no hay nada a qué apuntar.
el protocolo todavía vale la pena construir sobre él. pero no fingiendo que entrega lo que todavía no entrega. la descentralización no es una función que agregas después. es una restricción bajo la que construyes desde el primer día — o pasas años intentando retroadaptarla a un ecosistema que ya se optimizó en su ausencia.
construyendo infraestructura WoT para Nostr en nostr-wot.com