Una mesura reproduïble de quants relays de Nostr comparteixen en realitat la infraestructura d’una sola empresa — i què implica de veritat aquesta decisió per a un operador.
— @ifuensan / hacknodeslab
TL;DR
- La descentralització de Nostr sol comptar-se en relays. El número que importa per a la resistència a la censura és quanta infraestructura compartixen.
- En una instantània de nostr.watch del maig de 2026 amb 1.067 relays actius en clearnet, el 28,2% estan darrere de Cloudflare — i Cloudflare és pràcticament l’únic CDN en ús (CloudFront 0,2%, Fastly 0%). La centralització a Nostr és, quasi del tot, una història de Cloudflare.
- Això vol dir que un únic esdeveniment a nivell de Cloudflare — una caiguda, un bloqueig regional o una orde judicial contra els rangs d’IP de CF — afecta ~1 de cada 4 relays actius alhora, sense que ningú estiga apuntant a Nostr.
- Pitjor encara: per a alguns operadors el CDN no oferix cap protecció. Utilitzant només dades gratuïtes i públiques (DNS, transparència de certificats, registres de correu) i sense cap clau d’API, vaig recuperar i validar criptogràficament la IP d’origen real de 4 de 185 relays darrere de CF que publiquen una pubkey. Amb ferramentes de reconeixement de pagament eixe número és un sòl, no un sostre.
- Tot açò és reproduïble amb dos xicotets scripts de Python i una llista pública de relays. Torna a executar-ho sobre el panorama d’avui en menys de trenta minuts.
Per què importa açò
Nostr es ven com una xarxa de gossip resistent a la censura. La intuïció és simple: si hi ha centenars de relays independents, cap actor individual pot silenciar la xarxa. Però “independent” està fent molta faena en eixa frase. Dos relays amb dominis diferents, operadors diferents i pubkeys diferents no són independents si tots dos acaben darrere de la mateixa vora (edge) de Cloudflare. Una única decisió en eixa vora els tomba els dos simultàniament.
Això no és hipotètic. En el cas en curs de LaLiga a Espanya, els jutjats mercantils han ordenat als ISP que bloquegen rangs d’IP de Cloudflare durant els partits de futbol — de l’orde de ~3.000 IP per jornada, deixant col·lateralment sense servici més de 13.500 llocs no relacionats (incloent, en un cas àmpliament reportat, el servici de salut pública Madrid Salud). L’orde mai menciona Nostr. No li fa falta: si ~1 de cada 4 relays actius respon en una IP de Cloudflare, un usuari espanyol perd un quart de la xarxa durant la durada d’un partit, com a dany col·lateral.
El recompte de relays diu que la xarxa està descentralitzada. La infraestructura diu que una part significativa d’ella té un punt únic de fallada compartit i exposat a una jurisdicció. Este article quantifica eixa bretxa i nomena el trade-off amb precisió.
Pas 1 — Quants relays s’amaguen darrere d’un CDN?
Mètode. Agafa una llista de relays, resol cada hostname als seus registres A/AAAA i comprova cada IP contra els rangs d’adreces publicats dels principals CDN:
- Cloudflare —
https://www.cloudflare.com/ips-v4+ips-v6 - CloudFront —
https://ip-ranges.amazonaws.com/ip-ranges.json(service=CLOUDFRONT) - Fastly —
https://api.fastly.com/public-ip-list
Sense sondeig, sense explotació — només resolució de DNS i una comprovació de rang. Les instantànies dels rangs dels CDN es guarden en caché perquè un tercer puga reproduir els veredictes exactes. La ferramenta és check_cf.py.
Entrada. Una exportació xlsx de nostr.watch (nw-relays-all-20260503.xlsx), filtrada al conjunt de relays actius (in_rstate=True) i només clearnet — 1.079 hosts únics, 1.067 dels quals van resoldre. L’exportació sense filtrar està dominada per relays morts fa temps i infla el denominador; el subconjunt actiu-clearnet és la població honesta.
Resultat (instantània de maig de 2026):
| Veredicte | Compte | % dels resolts |
|---|---|---|
| cloudflare | 301 | 28,2% |
| cloudfront | 2 | 0,2% |
| fastly | 0 | 0% |
| direct | 764 | 71,6% |
| dns_error | 12 | — |
~28% dels relays actius estan darrere d’un CDN, i eixe CDN és Cloudflare. Afegir CloudFront i Fastly amb prou faenes mou l’agulla. Així que per a tot el que ve a continuació, “darrere de Cloudflare” i “darrere d’un CDN” són efectivament la mateixa pregunta.
Pas 2 — Amaga realment el CDN l’origen?
Estar darrere de Cloudflare només protegix si la teua IP de servidor real es manté en secret. Si un adversari pot trobar l’origen, pot atacar-lo o bloquejar-lo directament i el CDN es queda en decoratiu. Així que la segona pregunta és: per a un relay darrere de CF, es pot recuperar la IP d’origen només a partir de dades públiques — i provar-la correcta?
Fonts candidates (gratuïtes, sense claus d’API):
- DNS directe — el domini apex i subdominis germans comuns (
ssh.,mail.,direct.,origin., …). Els operadors solen posar el relay darrere de Cloudflare però deixen l’apex o un subdomini d’administració apuntant directament a la màquina. - Transparència de certificats (crt.sh) — hostnames germans en la mateixa cadena de certificats, i després resolts.
- Tokens SPF / TXT
ip4:— configuració de correu que nomena la IP del servidor. - Hosts MX — el servidor de correu sovint s’executa en la mateixa màquina que el relay.
Les consultes DNS per a TXT/MX i noms de CT passen per DNS-over-HTTPS (l’API JSON de 1.1.1.1), de manera que tota la ferramenta es manté només amb llibreria estàndard i reproduïble sense cap compte. Qualsevol IP candidata que caiga dins dels rangs publicats de Cloudflare es descarta — eixe és el front, no l’origen.
Validació — la part que convertix açò en evidència, no en una conjectura. Cada relay de Nostr pot servir un document NIP-11, i molts inclouen la pubkey de l’operador. Per a cada IP candidata, la ferramenta obri una connexió TLS a eixa IP mentres manté el SNI/Host apuntant al hostname real del relay (el patró curl --resolve), descarrega el document NIP-11 i compara la seua pubkey amb la que se servix a través del front de Cloudflare. Si les pubkeys coincidixen, l’origen queda confirmat criptogràficament — no inferit a partir de l’ASN, la geografia o una corazonada. Quan un relay no publica una pubkey, la ferramenta recorre a una empremta estructural (nom + programari + NIPs suportats ordenats + contacte) i ho reporta com una coincidència “probable” més feble. La ferramenta és find_origin.py.
Un cas pas a pas (anonimitzat: “Relay A”)
Per pràctica de divulgació responsable, el relay i la seua IP d’origen estan redactats ací. El mètode és totalment reproduïble contra el teu propi relay.
Relay A és un relay khatru servit en relay-a.example i responent en una IP de Cloudflare — segons la mesura del Pas 1, està “darrere d’un CDN”.
Executant find_origin.py relay-a.example:
- La ferramenta descarrega el NIP-11 de Relay A a través del front de Cloudflare i registra la
pubkeyde referència (una clau de 64 hexadecimals). - Reunix IP candidates. El domini apex de Relay A i un subdomini
ssh.resolen tots dos a una única IP en un proveïdor de núvol econòmic — fora dels rangs de Cloudflare. L’operador va posar darrere el subdomini del relay però va deixar la resta de la zona apuntant a la màquina real. - La ferramenta es connecta a eixa IP candidata amb el SNI/
Hostapuntant arelay-a.example, descarrega el document NIP-11 i llig la seuapubkey. - La pubkey és idèntica a la que se servix via Cloudflare. Origen confirmat.
Temps total transcorregut: uns pocs segons. Sense explotació, sense escaneig de ports — només DNS públic i un únic HTTPS GET. Per a Relay A, el front de Cloudflare no protegix res: l’origen està a un dig de distància.
Què d’estés està?
Entre els 185 relays darrere de CF que publiquen una pubkey viva (el subconjunt validable criptogràficament dels 301), l’escaneig de fonts gratuïtes va confirmar l’origen real de 4 relays repartits entre 3 operadors — 2,2%, a través de dos vectors de fuita diferents:
- Fuita de DNS — l’apex / un subdomini germà apunta directament a l’origen (el vector de Relay A).
- Fuita de correu — el host MX del relay resol a la mateixa màquina que executa el relay.
2,2% és un sòl, i un honest. Compta només els orígens demostrables a partir de dades gratuïtes, només en relays que publiquen una pubkey, en una única instantània. Afig reconeixement de pagament (Censys, Shodan, ZoomEye, DNS històric) i la fracció recuperable puja. El punt no és el percentatge exacte — és que per a una part no trivial dels operadors de relays, el CDN els proporciona el cost i la complexitat de Cloudflare sense cap de la protecció d’origen que implica.
El trade-off, nomenat
Posar un relay darrere de Cloudflare és una decisió d’enginyeria real amb avantatges reals. Val la pena ser precís sobre contra quin adversari ajuda i a quin li entrega calladament més poder.
Del que et protegix Cloudflare:
- DDoS volumètric — absorbit a la vora abans d’arribar a la teua màquina.
- Exposició casual de l’origen — la teua IP de servidor no està en el registre A del relay, així que l’atacant més mandrós no pot trobar-la (fins que DNS/correu/CT la filtren — vore més amunt).
- Faena operativa — TLS, caché i un front global anycast de franc.
A què t’exposa Cloudflare — i esta és la part que el màrqueting omet:
- Bloqueig jurisdiccional al qual no vas adherir-te. Una orde judicial contra els rangs de Cloudflare en qualsevol jurisdicció tomba el teu relay allí, encara que l’orde anara dirigida a la pirateria de futbol. Heretes cada batalla en què està l’espai d’adreces de Cloudflare.
- Fallada correlacionada. Ja no eres un relay independent; eres un de ~300 que compartixen un destí. Les matemàtiques de resiliència de la xarxa estan construïdes sobre una independència que no hi és.
- Un únic punt d’estrangulament de moderació/desplataformització. La decisió de termes de servici d’una empresa pot eliminar un quart de la vora de la xarxa activa en una sola acció.
I per als operadors que filtren, el pitjor cas: l’inconvenient sense l’avantatge. El seu origen és públic, així que reben l’exposició jurisdiccional i el risc de fallada correlacionada d’estar darrere de Cloudflare, mentres que un atacant que vol tombar el seu relay específic simplement apunta directament a l’origen.
Açò no és un argument que els operadors de relays no hagen d’usar Cloudflare. És un argument que l’elecció és un trade-off contra un model d’amenaça específic, no una victòria gratis — i que una xarxa la història de resistència a la censura de la qual depén del recompte de relays hauria de saber que ~1 de cada 4 d’eixos relays respon a la porta de la mateixa empresa.
Reproduïx-ho tu mateix
Tot l’instrumental és codi obert — hacknodeslab/nostr-cf-recon:
python3 -m venv .venv
.venv/bin/pip install rich openpyxl
# 1. From a fresh nostr.watch xlsx export, extract active clearnet relays:
.venv/bin/python extract_relays.py nw-relays-all-YYYYMMDD.xlsx relays.txt --online --clearnet
# 2. Measure CDN presence (Step 1):
.venv/bin/python check_cf.py relays.txt --json out.json
# 3. Try to unmask one relay's origin (Step 2):
.venv/bin/python find_origin.py <some-cf-fronted-relay-host>Si arriba una nova orde de bloqueig amb la forma de LaLiga, torna a executar el Pas 1 contra la llista de relays actual per a quantificar l’impacte col·lateral del mateix dia sobre Nostr.
Límits del mètode i ètica
- Només dades públiques. Sense explotació, sense saltar autenticació, sense escaneig de ports, sense sondeig més enllà de la resolució estàndard de DNS i un HTTPS GET contra endpoints públics NIP-11. La validació a l’estil
--resolvees connecta a una IP candidata que ja està publicada en DNS. - La reproduïbilitat és obligatòria. Les entrades, les instantànies de rangs de CDN i els veredictes per host es persistixen perquè un tercer puga tornar a executar-ho de punta a punta.
- Sense doxxing d’operadors. El resultat de desemmascarament és evidència metodològica, presentada de manera anònima. Les fuites d’origen confirmades es van divulgar de manera privada als operadors afectats; este article no nomena cap mapatge de relay a IP.
- Instantània, no vigilància. Açò és una mesura puntual en el temps d’una llista pública de relays, no una monitorització contínua de cap operador.
Ferramentes: check_cf.py (Pas 1), find_origin.py (Pas 2), extract_relays.py. Inspirat en la tècnica de reconeixement anti-Cloudflare de CF-Hero; ací usada només per a mesurar un trade-off de centralització, no per a atacar. Codi complet: github.com/hacknodeslab/nostr-cf-recon.