DEV Community: Ronny Cruz

Explain X Like I'm Five

Ronny Cruz — Thu, 06 Aug 2026 23:12:34 +0000

How to learn to use node.js?

Candor Trust and Safety

Ronny Cruz — Mon, 03 Aug 2026 12:31:47 +0000

Most "trust and safety" pages are a paragraph of promises. We built ours differently.

This week we launched Candor Trust & Safety — the public home for every safety system behind Candor: The Open Feed Network. Not a marketing page. An evidence page.

A few things that make it different:

🔑 Our cryptographic keys are published, not just claimed. Every adult-verification we issue is signed with a key you can look up yourself — no account, no API, no trusting our word for it.

🧾 Every consent record is independently checkable. Paste a receipt into our verifier and your own browser — not our servers — confirms it's real. If we ever get it wrong, anyone can catch it. That's the point.

🧒 Your Voice, our youth platform, now requires ID-verified adult consent for every account — enforced in the code, not just in policy. No verified adult, no account. Full stop.

🛡️ We red-team our own systems and publish what we find. This week our internal adversarial testing tool caught a real gap in our own consent flow — we fixed it, then proved the fix twice: once against the exact attack that found it, once confirming real users were never affected.

None of this is because regulation forced our hand (though it's coming fast — the UK, the EU, half of US states). It's because "trust us" was never going to be good enough, and we'd rather build something you don't have to.

Take a look: candortrustandsafety.com

TrustAndSafety #OnlineSafety #AgeVerification #BuildInPublic #ChildSafety

The Compatibility Claim I Hadn't Earned

Ronny Cruz — Fri, 24 Jul 2026 19:20:54 +0000

By Ronny Cruz , founder of Open Feed Network (Candor Network). Solo founder, one production platform, and — as of this week — one very small Fediverse instance.

The line in my own README

Sentinel Signup is a registration-screening service for Fediverse instances. It reads your pending signup queue, scores each applicant, and approves or rejects through the admin API. I launched it during the July spam wave, when instance admins were drowning in fake approval requests.

Here's the setup instruction I shipped with it:

Mastodon: Preferences → Development → New application, scopes admin:read admin:write.

Read that again. The product says Fediverse. The documentation says Mastodon. Those are not the same word, and the gap between them was a claim I had no evidence for.

The Fediverse is not one piece of software. It's Mastodon and GoToSocial and Akkoma and Pleroma and Misskey and Sharkey and Iceshrimp and a dozen others, most of which implement "the Mastodon client API" to varying and undocumented degrees. My sidecar spoke four endpoints of that API. I had verified them against exactly zero servers, because I had never run an instance in my life.

I was selling anti-abuse tooling to a community I wasn't a member of. That's not a moral failing, but it is an epistemic one: everything I knew about how those servers behave, I knew from reading specifications. Specifications describe intent. Deployments have opinions.

So I built the testbed I should have had first

The constraint was that it had to cost nothing. Mastodon itself is a heavy tenant — Ruby, Sidekiq, Redis, its own Postgres — and the box I'd be putting it on already runs five production services. GoToSocial is a single Go binary with SQLite that idles in a couple hundred megabytes, and it implements the Mastodon client API. That's the whole reason it was the right choice: it's not Mastodon, which makes it a real test rather than a rehearsal.

Two things went wrong before it ever started, and both are worth writing down.

The CPU refused. GoToSocial's standard build runs its bundled ffmpeg and SQLite through wazero, a WebAssembly runtime, and wazero's compiler requires x86-64-v2 instructions. My VPS reports itself as a generic QEMU virtual CPU — no SSE4.2, no SSSE3, no POPCNT — because that's what many budget and older virtualized hosts advertise. GoToSocial doesn't degrade to interpreter mode; it panics on purpose, which I respect. The fix is an official nowasm build that uses the system's native ffmpeg instead. If you're self-hosting anything on inexpensive virtualization, check /proc/cpuinfo before you assume modern instruction sets. Mine had been quietly ancient for months.

The proxy lied about who was knocking. The instance sits behind Cloudflare, and my nginx config forwarded the client address the conventional way. Behind a CDN, that address is the CDN's — every signup on Earth would have arrived from the same handful of edge IPs.

That one is worth dwelling on, because of how it fails. Nothing errors. The screening service still returns verdicts. The logs still look healthy. It just silently becomes blind in the exact dimension it's most valuable in: IP reputation, subnet velocity, burst detection — all the signals that catch a bot farm — collapse into "one address, always." A safety system that reports success while measuring nothing is worse than one that's obviously broken, which is a lesson I keep relearning in new costumes. The fix was one nginx directive reading the CDN's real-client header. The habit is: after any infrastructure change, verify that your signals still carry information, not just that your requests still return 200.

What verification actually looked like

With the node running and reachable, I checked the four calls my sidecar makes, one at a time, against a server I'd never tested:

GET /api/v2/admin/accounts — 200
GET /api/v1/admin/accounts (the fallback path) — 200
GET /api/v2/instance — 200
POST /api/v1/admin/accounts/{id}/reject — 200

Then the question that actually determined whether the product is useful on GoToSocial at all: does the admin API expose the signup IP? Mastodon does. If GoToSocial didn't, then on GTS instances Sentinel would be running on username and application text alone — still something, but a fraction of the defense, and I'd have to say so out loud in the documentation.

It does. The ip field came back populated. Velocity, subnet, and reputation all function. The compatibility claim survives without a caveat, and — this is the part that matters — it survives because I ran it, not because I assumed it.

I also found two differences worth documenting. GoToSocial places a signup into the pending queue immediately, without waiting for email confirmation, which Mastodon doesn't. And its admin CLI has no delete for accounts at all — only disable, plus rejection through the API. Neither breaks anything. Both would have been surprises in front of a customer.

The first real signup

Then I registered a throwaway account on my own instance, in an incognito window, like a stranger would, and wrote a genuine sentence in the reason field.

Thirty seconds later the sidecar picked it out of the queue, sent it to the live screening service, and logged:

WOULD APPROVE: @[redacted] verdict=pass confidence=1 — Clean IP history and natural application language.

Dry run, so it did nothing, which is exactly what dry run is for. But the whole chain had run for the first time in its life: pending signup → admin API → screening engine → verdict → action decision. Every piece I'd built separately, working together, on a server type I'd never touched.

Rejecting the test account afterward returned 200 and cleared the queue to zero, which incidentally verified the last endpoint.

I left it in dry run, on purpose

The obvious next move is flipping it live so my own instance is auto-screened. I didn't.

My instance isn't a community — it's one account and a testbed. Turning on auto-approval means strangers get accounts, which means I'm hosting federated content, which means I've added a moderation surface to a machine already running five production services. That's a real decision with real obligations, not a config flag, and I'm not making it as a side effect of testing something.

So the sidecar runs continuously in dry run: every future signup gets screened and logged, giving me the observations, while approval stays a human decision. The testbed value is fully there. The obligation isn't taken on accidentally. I can flip it whenever I mean to.

Honest limitations

One instance, one signup, my own IP. This proves the plumbing connects. It is not a load test, not an adversarial test, and not evidence about accuracy. Nobody has attacked this instance, because nobody knows it exists yet.
One version. GoToSocial 0.22.1. API coverage moves between releases; a claim verified today is a claim about today.
"Fediverse-compatible" is still an overclaim, and I'm retiring it. What I can now say is: Mastodon and GoToSocial, verified. Akkoma, Pleroma, Misskey, Sharkey, Iceshrimp — untested. If you run one of those and want to find out with me, I'll do the work with you.
The nowasm build is officially unsupported for media processing. Fine for a testbed. Worth knowing before you put it under a real community.
I use AI tooling heavily — Claude, mostly — to build and to write, including this post. The screening engine itself is deliberately heuristic and rule-based with no model in the loop, because it has to run at effectively zero marginal cost for instances that can't pay for spam protection. Where the machines helped, they helped; where the evidence comes from, it's my own server's logs.

The point of being customer zero

"Built for ourselves, available to you" has been the pitch since the safety modules were extracted from my own platform. This week it got more literal: my platform's registration is screened by this product, and now a second server type is too, on infrastructure I run.

The reason that matters isn't marketing. It's that every gap I just described — the CPU, the blinded IPs, the queue behavior, the missing CLI verb — would otherwise have been found by an admin under attack, at the worst possible moment, in a system they'd trusted on my word. Finding them cost me an evening and zero dollars. Finding them the other way costs someone their instance.

If you run a Fediverse instance of any flavor and your signup queue is full of garbage, Sentinel Signup is free during beta: signup.candortheopenfeednetwork.com. If you run something I haven't verified, tell me and let's test it properly — tips@candortheopenfeednetwork.com. I answer everything myself.
(https://candortheopenfeednetwork.com/sentinel-signup)
(https://app.candortheopenfeednetwork.com)

El Formulario de Registro Que No Tiene Nada Que Filtrar

Ronny Cruz — Thu, 23 Jul 2026 20:32:36 +0000

Por Ronny Cruz, fundador de Open Feed Network (Candor Network). Fundador solo, una plataforma en producción, y un flujo de registro que deliberadamente no sabe casi nada de ti.

El problema que me creé yo mismo

El registro de Candor no recoge correo electrónico. Ni teléfono. Ni cuenta de CAPTCHA, ni identidad de OAuth, nada que verificar porque no hay nada contra qué verificar. Instalas la app, eliges un nombre de usuario, pones un PIN, y el navegador genera un par de llaves ECDSA P-256 en tu dispositivo. El servidor recibe exactamente dos cosas: el nombre de usuario y la llave pública. Las doce palabras semilla y el archivo de recuperación se quedan contigo. Ese es el registro completo.

Lo construí así a propósito. Registro sin datos personales significa que no hay base de datos de correos que filtrar, ni lista de teléfonos que citar judicialmente, ni grafo de identidad que vender. Para una plataforma cuya tesis completa es que tu voz no debería depender de confiar en mí, es el diseño correcto.

También es, desde la perspectiva de la defensa contra spam, una pesadilla que me entregué a mí mismo. Cada señal en la que la industria se apoya para filtrar registros —dominios de correo desechable, reputación de correo, verificación de ida y vuelta— asume que existe un correo. El mío no. Y el flujo es rápido por diseño, lo cual significa que un script también puede serlo. El viernes pasado, una revisión de código con IA lo dijo sin rodeos: nada impedía que un bot hiciera un bucle sobre el endpoint de registro y creara cincuenta mil cuentas, inundando el feed con identidades que no cuestan nada crear.

La revisión tenía razón. Nada lo impedía.

La ironía era que yo vendo la solución

La semana anterior había lanzado Sentinel Signup — un servicio de filtrado de registros para instancias del Fediverso golpeadas por exactamente ese tipo de ola. Seis capas: reputación de IP y de dominio, velocidad por subred, patrones de tiempo, análisis de contenido, todo.

Mi propia plataforma no lo estaba usando. Los hijos del zapatero, descalzos como siempre.

Peor: no podía usarlo. La API de filtrado exigía un correo en cada petición, porque todos los clientes que había imaginado tenían uno. Mi propio flujo de registro —el más respetuoso con la privacidad que conozco— estaba estructuralmente excluido de mi propio producto de seguridad. Y el motor iba más lejos que solo exigirlo: un correo ausente sumaba una penalización de +30 por "correo inválido". Pasa a mis propios usuarios honestos por mi propio filtro, y todos empiezan pareciendo sospechosos. Una función de privacidad leída como señal de fraude.

Vale la pena detenerse ahí, porque no es una peculiaridad de mi código. Es lo que pasa en toda esta industria cuando los sistemas anti-abuso asumen señales de identidad que las plataformas respetuosas con la privacidad deliberadamente no recogen. La postura por defecto de la defensa contra spam es que saber menos de un usuario lo hace más sospechoso. Si queremos que existan plataformas que preserven la privacidad, las herramientas de seguridad tienen que dejar de castigarlas por ello.

La solución: ausencia no es malformación

El cambio fue pequeño y filosóficamente importante. El motor ahora distingue dos cosas que antes confundía:

Correo presente pero mal formado — se sigue penalizando. Alguien mandó basura en un campo de correo; eso es una señal real.
Correo no proporcionado en absoluto — se registra como un hecho neutral, peso cero. Una plataforma sin datos personales no tiene nada que enviar, y ser honesta sobre eso no debería costarle nada a sus usuarios.
Cada verificación que se activa cuando el correo sí está presente —listas de dominios desechables, patrones de correos temporales— se activa exactamente igual que antes. La batería de pruebas comprueba ambas direcciones: ninguna penalización por ausencia, ninguna suavización ante la basura.

Con eso, mi registro por fin pudo ser filtrado por mi propio producto, usando solo lo que realmente existe: nombre de usuario, IP real del cliente (desde la cabecera reenviada por el CDN — el servicio nunca ve conexiones directas), agente de usuario y tiempo. Sin correo, sin marcador de posición sintético contaminando el análisis. Lo que es real se analiza; lo que no existe no se inventa.

La pregunta de postura que nadie hace hasta que hay una caída

Conectar el filtro al manejador de registro obligó a una decisión que la mayoría de las integraciones se saltan: ¿qué pasa cuando el filtrado mismo falla?

Para mis clientes administradores de Mastodon, la respuesta es falla-a-cola — un error de filtrado envía al solicitante a la cola de aprobación humana, donde decide un moderador. Nunca admitido en silencio, nunca rechazado en silencio.

Mi flujo de registro no tiene cola. No hay moderador entre una persona y su cuenta, por diseño. Así que falla-a-cola no significa nada aquí, y las dos opciones de manual están mal: fallar-cerrado significa que un tropiezo de dos segundos deja fuera a personas reales; fallar-abierto en silencio significa que los bots pasan y nadie se entera.

La postura que desplegué: bloquear solo ante un veredicto duro de bloqueo; ante una marca o cualquier error, permitir — pero en voz alta. Cada registro marcado y cada fallo de filtrado queda en los logs con su razón. Una ráfaga que se cuele durante una caída es visible y atribuible en minutos. Una persona real bloqueada por un fallo de dependencia sería invisible para siempre — simplemente se iría. Entre esos dos costos, la decisión no está reñida.

Qué le hizo la barrera al escenario del bot

Después de desplegar, corrí el ataque contra mi propio servidor de producción. Primero, un registro legítimo — pasó limpio, token emitido, indistinguible de antes. Luego la versión en miniatura del escenario de las cincuenta mil cuentas: registros a toda velocidad desde una sola IP, par de llaves nuevo cada vez.

La escalera de escalado, directo de los logs:

Registros 1–2: pasaron.
Registro 3: marcado — múltiples cuentas desde una IP, alta velocidad de subred — permitido, registrado.
Registro 4: bloqueado — umbral de velocidad superado.
Registros 5 al 15: bloqueados al instante — "IP previamente bloqueada". La barrera recordó. Cada intento posterior murió sin siquiera ser evaluado de nuevo.
Un bot que quería cincuenta mil cuentas consiguió cuatro. Y la persona que se registró primero nunca notó que pasara nada.

Limitaciones honestas

Mi prueba fue desde una sola IP. Un adversario real rota por proxies residenciales, y la velocidad desde la misma IP se debilita frente a eso. La velocidad por subred atrapa la versión perezosa; una botnet bien distribuida es un problema más difícil, y no pretendo haberlo cerrado.
Las señales que quedan son delgadas por diseño. Nombre de usuario, IP, agente de usuario, tiempo — ese es todo el conjunto cuando te niegas a recoger identidad. Considero que el intercambio vale la pena, pero es un intercambio, y quien te diga que puede reemplazar por completo la reputación de correo con cuatro campos te está vendiendo algo.
Los umbrales se quedan privados. Ya escribí antes sobre por qué los mensajes de rechazo nunca deben enseñarle al atacante qué lo delató; la misma regla aplica aquí. Un registro bloqueado ve "temporalmente no disponible", no qué capa se activó ni con qué conteo.
Esto es una plataforma, con días en producción. La evidencia son mis propios logs, fechados, de mi propio servidor. No es un estudio a escala de flota.
Por qué el punto era comernos nuestra propia comida

La propuesta de Sentinel Signup a los administradores de Mastodon siempre ha sido "construido para nosotros, disponible para ti" — los módulos se extrajeron de las defensas de la propia plataforma. Desde esta semana eso es cierto en el sentido más pleno: el mismo motor de filtrado, la misma API, el mismo sistema de inquilinos que recibe cualquier cliente es lo que está entre mi propio endpoint de registro y la próxima ola de creación masiva. El cliente cero soy yo. Cuando se rompa, se me rompe a mí primero — que es exactamente el arreglo que mantiene honesto a un producto de seguridad.

Si administras una plataforma con un flujo de registro —especialmente una que recoge menos de lo que la industria asume que deberías— Sentinel Signup es gratis durante la beta en signup.candortheopenfeednetwork.com, y el soporte sin datos personales descrito aquí está activo para todos los inquilinos. Si crees que mi postura ante fallos está equivocada, quiero escucharlo especialmente: tips@candortheopenfeednetwork.com. Respondo todo yo mismo.

La Compatibilidad Que No Me Había Ganado

Ronny Cruz — Thu, 23 Jul 2026 20:28:34 +0000

Por Ronny Cruz, fundador de Open Feed Network (Candor Network). Fundador solo, una plataforma en producción y —desde esta semana— una instancia muy pequeña del Fediverso.

La línea en mi propio README

Sentinel Signup es un servicio de filtrado de registros para instancias del Fediverso. Lee tu cola de solicitudes pendientes, evalúa a cada solicitante, y aprueba o rechaza a través de la API de administración. Lo lancé durante la ola de spam de julio, cuando los administradores de instancias se estaban ahogando en solicitudes falsas.

Esta era la instrucción de configuración que envié con él:

Mastodon: Preferencias → Desarrollo → Nueva aplicación, permisos admin:read admin:write.

Léelo otra vez. El producto dice Fediverso. La documentación dice Mastodon. No son la misma palabra, y la distancia entre ambas era una afirmación para la que no tenía evidencia.

El Fediverso no es un solo programa. Es Mastodon y GoToSocial y Akkoma y Pleroma y Misskey y Sharkey e Iceshrimp y una docena más, la mayoría de los cuales implementan "la API cliente de Mastodon" en grados variables y no documentados. Mi sidecar hablaba cuatro endpoints de esa API. Los había verificado contra exactamente cero servidores, porque nunca en mi vida había administrado una instancia.

Estaba vendiendo herramientas anti-abuso a una comunidad de la que no era miembro. No es un fallo moral, pero sí es uno epistémico: todo lo que sabía sobre cómo se comportan esos servidores lo sabía por leer especificaciones. Las especificaciones describen intenciones. Los despliegues tienen opiniones.

Así que construí el banco de pruebas que debí haber tenido primero

La restricción era que no podía costar nada. Mastodon es un inquilino pesado —Ruby, Sidekiq, Redis, su propio Postgres— y la máquina donde lo pondría ya corre cinco servicios en producción. GoToSocial es un solo binario en Go con SQLite que reposa en un par de cientos de megabytes, e implementa la API cliente de Mastodon. Esa es justo la razón por la que era la elección correcta: no es Mastodon, lo que lo convierte en una prueba real y no en un ensayo.

Dos cosas salieron mal antes de que llegara a arrancar, y ambas vale la pena anotarlas.

La CPU se negó. La compilación estándar de GoToSocial ejecuta su ffmpeg y su SQLite integrados a través de wazero, un runtime de WebAssembly, y el compilador de wazero requiere instrucciones x86-64-v2. Mi VPS se reporta como una CPU virtual genérica de QEMU —sin SSE4.2, sin SSSE3, sin POPCNT— porque eso es lo que anuncian muchos hosts virtualizados económicos o antiguos. GoToSocial no degrada a modo intérprete; lanza un pánico a propósito, cosa que respeto. La solución es una compilación oficial nowasm que usa el ffmpeg nativo del sistema. Si te autoalojas en virtualización barata, revisa /proc/cpuinfo antes de asumir instrucciones modernas. La mía llevaba meses siendo silenciosamente antigua.

El proxy mintió sobre quién tocaba la puerta. La instancia está detrás de Cloudflare, y mi configuración de nginx reenviaba la dirección del cliente de la forma convencional. Detrás de un CDN, esa dirección es la del CDN — cada registro del planeta habría llegado desde el mismo puñado de IPs de borde.

Ese merece detenerse, por cómo falla. Nada da error. El servicio de filtrado sigue devolviendo veredictos. Los logs siguen viéndose sanos. Simplemente se vuelve ciego en exactamente la dimensión donde más vale: reputación de IP, velocidad por subred, detección de ráfagas — todas las señales que atrapan una granja de bots colapsan en "una dirección, siempre". Un sistema de seguridad que reporta éxito mientras no mide nada es peor que uno que está obviamente roto, lección que sigo reaprendiendo con disfraces nuevos. La solución fue una directiva de nginx leyendo la cabecera de cliente real del CDN. El hábito es: después de cualquier cambio de infraestructura, verifica que tus señales sigan llevando información, no solo que tus peticiones sigan devolviendo 200.

Cómo se vio la verificación de verdad

Con el nodo corriendo y accesible, revisé las cuatro llamadas que hace mi sidecar, una por una, contra un servidor que nunca había probado:

GET /api/v2/admin/accounts — 200
GET /api/v1/admin/accounts (la ruta de respaldo) — 200
GET /api/v2/instance — 200
POST /api/v1/admin/accounts/{id}/reject — 200

Luego la pregunta que realmente determinaba si el producto sirve de algo en GoToSocial: ¿expone la API de administración la IP del registro? Mastodon sí. Si GoToSocial no lo hiciera, entonces en instancias GTS Sentinel estaría funcionando solo con el nombre de usuario y el texto de la solicitud — algo, pero una fracción de la defensa, y tendría que decirlo en voz alta en la documentación.

Sí la expone. El campo ip volvió con valor. Velocidad, subred y reputación funcionan. La afirmación de compatibilidad sobrevive sin matices y —esto es lo que importa— sobrevive porque la ejecuté, no porque la asumí.

También encontré dos diferencias que vale documentar. GoToSocial coloca una solicitud en la cola pendiente de inmediato, sin esperar confirmación de correo, cosa que Mastodon no hace. Y su CLI de administración no tiene delete para cuentas en absoluto — solo disable, más el rechazo vía API. Ninguna de las dos rompe nada. Ambas habrían sido sorpresas frente a un cliente.

El primer registro real

Después registré una cuenta desechable en mi propia instancia, en una ventana de incógnito, como lo haría un desconocido, y escribí una frase genuina en el campo de motivo.

Treinta segundos más tarde, el sidecar la sacó de la cola, la envió al servicio de filtrado en vivo y registró:

APROBARÍA: @[redactado] veredicto=pass confianza=1 — Historial de IP limpio y lenguaje de solicitud natural.

Modo de prueba, así que no hizo nada, que es exactamente para lo que sirve el modo de prueba. Pero la cadena completa había corrido por primera vez en su vida: solicitud pendiente → API de administración → motor de filtrado → veredicto → decisión de acción. Cada pieza que había construido por separado, funcionando junta, en un tipo de servidor que nunca había tocado.

Rechazar la cuenta de prueba después devolvió 200 y dejó la cola en cero, lo que de paso verificó el último endpoint.

Lo dejé en modo de prueba, a propósito

El siguiente movimiento obvio es activarlo para que mi propia instancia se filtre automáticamente. No lo hice.

Mi instancia no es una comunidad — es una cuenta y un banco de pruebas. Encender la aprobación automática significa que desconocidos consiguen cuentas, lo que significa que estoy alojando contenido federado, lo que significa que le he añadido una superficie de moderación a una máquina que ya corre cinco servicios en producción. Esa es una decisión real con obligaciones reales, no una bandera de configuración, y no la voy a tomar como efecto secundario de probar algo.

Así que el sidecar corre continuamente en modo de prueba: cada registro futuro se filtra y se registra, dándome las observaciones, mientras la aprobación sigue siendo una decisión humana. El valor del banco de pruebas está completo. La obligación no se asume por accidente. Puedo activarlo cuando lo decida de verdad.

Limitaciones honestas

Una instancia, un registro, mi propia IP. Esto prueba que la tubería conecta. No es una prueba de carga, ni una prueba adversaria, ni evidencia sobre precisión. Nadie ha atacado esta instancia, porque nadie sabe todavía que existe.
Una versión. GoToSocial 0.22.1. La cobertura de la API se mueve entre versiones; una afirmación verificada hoy es una afirmación sobre hoy.
"Compatible con el Fediverso" sigue siendo excesivo, y lo retiro. Lo que ahora puedo decir es: Mastodon y GoToSocial, verificados. Akkoma, Pleroma, Misskey, Sharkey, Iceshrimp — sin probar. Si administras alguno de esos y quieres averiguarlo conmigo, hago el trabajo contigo.
La compilación nowasm no tiene soporte oficial para procesamiento de medios. Bien para un banco de pruebas. Vale saberlo antes de ponerla bajo una comunidad real.
Uso herramientas de IA intensivamente —Claude, sobre todo— para construir y para escribir, incluido este texto. El motor de filtrado en sí es deliberadamente heurístico y basado en reglas, sin modelo en el ciclo, porque tiene que funcionar a un costo marginal efectivamente cero para instancias que no pueden pagar por protección contra spam. Donde las máquinas ayudaron, ayudaron; de donde viene la evidencia, son los logs de mi propio servidor.

El punto de ser el cliente cero

"Construido para nosotros, disponible para ti" ha sido la propuesta desde que los módulos de seguridad se extrajeron de mi propia plataforma. Esta semana se volvió más literal: el registro de mi plataforma está filtrado por este producto, y ahora un segundo tipo de servidor también, sobre infraestructura que yo administro.

La razón por la que eso importa no es de mercadeo. Es que cada hueco que acabo de describir —la CPU, las IPs cegadas, el comportamiento de la cola, el verbo faltante en la CLI— lo habría encontrado, de otro modo, un administrador bajo ataque, en el peor momento posible, en un sistema que había confiado por mi palabra. Encontrarlos me costó una tarde y cero dólares. Encontrarlos del otro modo le cuesta a alguien su instancia.

Si administras una instancia del Fediverso de cualquier sabor y tu cola de registros está llena de basura, Sentinel Signup es gratis durante la beta: signup.candortheopenfeednetwork.com. Si corres algo que no he verificado, dímelo y lo probamos como se debe — tips@candortheopenfeednetwork.com. Respondo todo yo mismo.

The Compatibility Claim I Hadn't Earned

Ronny Cruz — Thu, 23 Jul 2026 20:20:05 +0000

The Compatibility Claim I Hadn't Earned

By Ronny Cruz Alvarez, founder of Open Feed Network (Candor Network). Solo founder, one production platform, and — as of this week — one very small Fediverse instance.

The line in my own README

Here's the setup instruction I shipped with it:

Mastodon: Preferences → Development → New application, scopes admin:read admin:write.

Read that again. The product says Fediverse. The documentation says Mastodon. Those are not the same word, and the gap between them was a claim I had no evidence for.

So I built the testbed I should have had first

Two things went wrong before it ever started, and both are worth writing down.

What verification actually looked like

With the node running and reachable, I checked the four calls my sidecar makes, one at a time, against a server I'd never tested:

GET /api/v2/admin/accounts — 200
GET /api/v1/admin/accounts (the fallback path) — 200
GET /api/v2/instance — 200
POST /api/v1/admin/accounts/{id}/reject — 200

The first real signup

Then I registered a throwaway account on my own instance, in an incognito window, like a stranger would, and wrote a genuine sentence in the reason field.

Thirty seconds later the sidecar picked it out of the queue, sent it to the live screening service, and logged:

WOULD APPROVE: @[redacted] verdict=pass confidence=1 — Clean IP history and natural application language.

Rejecting the test account afterward returned 200 and cleared the queue to zero, which incidentally verified the last endpoint.

I left it in dry run, on purpose

The obvious next move is flipping it live so my own instance is auto-screened. I didn't.

Honest limitations

One instance, one signup, my own IP. This proves the plumbing connects. It is not a load test, not an adversarial test, and not evidence about accuracy. Nobody has attacked this instance, because nobody knows it exists yet.
One version. GoToSocial 0.22.1. API coverage moves between releases; a claim verified today is a claim about today.
"Fediverse-compatible" is still an overclaim, and I'm retiring it. What I can now say is: Mastodon and GoToSocial, verified. Akkoma, Pleroma, Misskey, Sharkey, Iceshrimp — untested. If you run one of those and want to find out with me, I'll do the work with you.
The nowasm build is officially unsupported for media processing. Fine for a testbed. Worth knowing before you put it under a real community.
I use AI tooling heavily — Claude, mostly — to build and to write, including this post. The screening engine itself is deliberately heuristic and rule-based with no model in the loop, because it has to run at effectively zero marginal cost for instances that can't pay for spam protection. Where the machines helped, they helped; where the evidence comes from, it's my own server's logs.

The point of being customer zero

The Signup Form With Nothing to Filter

Ronny Cruz — Thu, 23 Jul 2026 20:18:34 +0000

By Ronny Cruz, founder of Open Feed Network (Candor Network). Solo founder, one production platform, and a registration flow that deliberately knows almost nothing about you.

The problem I built for myself

Candor's registration collects no email. No phone number. No CAPTCHA account, no OAuth identity, nothing to verify because there is nothing to verify against. You install the app, choose a username, set a PIN, and the browser generates an ECDSA P-256 keypair on your device. The server receives exactly two things: the username and the public key. Twelve seed words and a recovery file stay with you. That's the entire signup.

I built it that way on purpose. Zero-PII registration means there is no email database to breach, no phone list to subpoena, no identity graph to sell. For a platform whose whole thesis is that your voice shouldn't depend on trusting me, it's the right design.

It is also, from a spam-defense perspective, a nightmare I handed to myself. Every signal the industry leans on for signup screening — disposable email domains, email reputation, verification round-trips — assumes an email exists. Mine doesn't. And the flow is fast by design, which means a script can be fast too. Last Friday an AI code review put it bluntly: nothing stopped a bot from looping the registration endpoint and minting fifty thousand accounts, flooding the feed with identities that cost nothing to create.

The review was right. Nothing did.

The irony was that I sell the fix

The week before, I had launched Sentinel Signup — a registration-screening service for Fediverse instances getting hammered by exactly this kind of wave. Six layers: IP and domain reputation, subnet velocity, timing patterns, content analysis, the works. Built for Mastodon admins drowning in fake approval requests.

My own platform wasn't using it. The cobbler's children, barefoot as usual.

Worse: it couldn't use it. The screening API required an email in every request, because every customer I'd imagined had one. My own registration flow — the most privacy-preserving one I know of — was structurally locked out of my own security product. And the engine went further than requiring email: an absent email scored a +30 "invalid email" penalty. Run my own honest users through my own filter, and every single one would start out looking suspicious. A privacy feature read as a fraud signal.

That's worth sitting with, because it isn't a quirk of my code. It's what happens across this industry when anti-abuse systems assume identity signals that privacy-respecting platforms deliberately don't collect. The default posture of spam defense is that knowing less about a user makes them more suspect. If we want privacy-preserving platforms to exist, the security tooling has to stop punishing them for the privacy.

The fix: absence is not malformation

The change was small and philosophically important. The engine now distinguishes two things it previously conflated:

Email provided but malformed — still penalized. Someone sent garbage in an email field; that's a real signal.
Email not provided at all — recorded as a neutral fact, weight zero. A zero-PII platform has nothing to send, and honesty about that costs its users nothing.

Every check that fires when an email is present — disposable-domain lists, throwaway-pattern matching — fires exactly as before. The test suite proves both directions: no penalty for absence, no softening for garbage.

With that, my registration could finally be screened by my own product, using only what genuinely exists: username, real client IP (from the CDN's forwarded header — the service itself never sees raw connections), user agent, and time. No email, no synthetic placeholder polluting the analysis. What's real gets analyzed; what doesn't exist isn't faked.

The posture question nobody asks until an outage

Wiring the screen into the registration handler forced a decision most integrations skip: what happens when screening itself fails?

For my Mastodon-admin customers, the answer is fail-to-queue — a screening error routes the applicant to the human approval queue, where a moderator decides. Never silently admitted, never silently rejected.

My registration flow has no queue. There is no moderator between a human and their account, by design. So fail-to-queue is meaningless here, and the two textbook options are both wrong: fail-closed means a two-second screening hiccup locks real humans out of joining the platform; fail-open with silence means bots stream through and nobody knows.

The posture I shipped: block only on a hard block verdict; on a flag or any error, allow — loudly. Every flagged registration and every screening failure lands in the logs with the reason. A burst that slips through during an outage is visible and attributable within minutes. A human locked out by a dependency failure would be invisible forever — they'd just leave. Between those two failure costs, the choice isn't close.

What the gate did to the bot scenario

After deploying, I ran the attack against my own production server. First, one legitimate registration — passed clean, token issued, indistinguishable from before. Then the miniature version of the fifty-thousand-account scenario: rapid-fire registrations from a single IP, fresh keypair each time.

The escalation ladder, straight from the logs:

Registrations 1–2: passed.
Registration 3: flagged — multiple accounts from one IP, high subnet velocity — allowed, logged.
Registration 4: blocked — velocity threshold crossed.
Registrations 5 through 15: blocked instantly — "previously blocked IP." The gate remembered. Every subsequent attempt died without even being re-scored.

A bot that wanted fifty thousand accounts got four. And the human who registered first never noticed anything happened at all.

Honest limitations

My test was a single IP. A real adversary rotates through residential proxies, and same-IP velocity weakens against that. Subnet velocity catches the lazy version; a well-distributed botnet is a harder problem, and I'm not claiming this closes it. Rate-limiting keypair minting per network is a floor, not a ceiling.
The remaining signals are thin by design. Username, IP, user agent, timing — that's the whole feature set when you refuse to collect identity. I consider that trade worth it, but it's a trade, and anyone telling you they can fully replace email reputation with four fields is selling something.
Thresholds stay private. I've written before about why rejection messages must never teach attackers what tripped them; the same rule applies here. A blocked registration sees "temporarily unavailable," not which layer fired or at what count. That's deliberate, and it means this article tells you the shape of the defense, not its numbers.
This is one platform, days old in production. The evidence is my own logs, dated, from my own server. It is not a fleet-scale study.

Why dogfooding was the point

Sentinel Signup's pitch to Mastodon admins has been "built for ourselves, available to you" — the modules were extracted from the platform's own defenses. As of this week that's true in the fullest sense: the same screening engine, the same API, the same tenant system any customer gets is what stands between my own registration endpoint and the next minting run. Customer zero is me. When it breaks, I'm the first one it breaks on — which is exactly the arrangement that keeps a safety product honest.

If you run a platform with a registration flow — especially one that collects less than the industry assumes you should — Sentinel Signup is free during beta at signup.candortheopenfeednetwork.com, and the zero-PII support described here is live for every tenant. If you think my failure posture is wrong, I especially want to hear that: tips@candortheopenfeednetwork.com. I answer everything myself.

The Social Network That Was Built Safety-First

Ronny Cruz — Thu, 23 Jul 2026 16:22:05 +0000

How Candor: The Open Feed Network rethinks what a platform owes the people on it

Most social platforms were built the same way: grow first, moderate later. Safety teams arrived years after the feed did, bolted onto architectures that were never designed to protect anyone. Candor: The Open Feed Network was built in the opposite order — and that inversion shapes everything about it.

Candor, which entered public beta on July 4, 2026, is a bilingual English/Spanish social feed and livestreaming platform created by founder Ronny Cruz of Open Feed Network, Inc. Its core feed is open source under the MIT license, published for anyone to inspect. What makes it unusual is what runs underneath: a suite of purpose-built safety systems that screen content before it ever reaches another user — not after someone reports it.

No email. No password. No profile to sell.

Candor's most radical choice is what it refuses to collect. There is no email signup, no password, no phone number. Instead, identity is cryptographic: when you join, your device generates a keypair secured by a recovery seed phrase, and a PIN-protected vault that never leaves your own device. The server never sees your private key and holds no personal information about you — because it was never given any.

This isn't privacy as a settings toggle. It's privacy as architecture: the platform cannot leak, sell, or be compelled to hand over data it does not possess.

The same principle governs where content lives. User posts are hosted in Iceland under GDPR, one of the strongest data-protection regimes in the world, while legally mandated safety reporting runs through U.S. infrastructure — a deliberate split that keeps user data under strong privacy law without compromising the platform's legal obligations to protect people.

Safety that runs before the harm, not after

The safety layer is where Candor departs most sharply from the industry norm. Every piece of content passes through screening at the moment it enters the platform. Candor is an approved reporting partner of the National Center for Missing & Exploited Children and a licensed user of Microsoft's PhotoDNA, which blocks known child sexual abuse material at upload — the gate fails closed, meaning if screening can't run, the content doesn't post.

Livestreams get the same treatment in real time. Candor's live pipeline transcribes streams as they happen and scores them for terrorist and violent extremist content within seconds — not minutes, not after a viewer files a report. It is an answer, in working code, to the question the industry has struggled with since the Christchurch attack was broadcast live in 2019: how do you stop a livestream being used as a weapon?

Alongside threat detection runs something rarer: care. Candor Beacon monitors for signs of mental-health crisis — and it's built to tell the difference between dark humor, ordinary venting, and genuine distress, responding only when someone may actually need help. The platform's own testing philosophy is blunt about the stakes: a system that cries wolf is as useless as one that stays silent.

A third layer, Truth Shield, is free and open source: an AI-powered disinformation detector that labels posts with a risk assessment readers can see, rather than silently deciding what they're allowed to read.

"Built for ourselves, available to you"

Every one of these systems was built first to protect Candor's own feed. Only afterward were they extracted as independent services that other platforms — community sites, streaming services, youth platforms — can license and run themselves. That ordering matters: these aren't compliance products designed to a sales deck. They're the actual defenses of a working platform, offered to anyone else who needs them.

It's a small operation making a large argument. Candor is built and run by a solo founder from Puerto Rico, operating infrastructure across three countries, screening two languages in real time. If one person building safety-first can do this, the argument goes, the platforms with thousands of engineers have run out of excuses.

What Candor is betting on

Candor's wager is that people are tired of the trade they've been offered — connection in exchange for surveillance, reach in exchange for safety. Its answer is a feed where you are not the product, where protection runs in the pipeline rather than the press release, and where the code making those promises is public enough to check.

The platform is live now at candortheopenfeednetwork.com. Bring nothing but a seed phrase.

Casi le Enseñamos a los Bots de Spam Cómo Vencernos

Ronny Cruz — Mon, 20 Jul 2026 18:53:38 +0000

Por Ronny Cruz, fundador de Open Feed Network (Candor Network). Fundador solo, una plataforma en producción, muchas opiniones sobre lo que un mensaje de rechazo tiene permitido decir.

El bug que me hizo pensar

Hace dos semanas, en medio de construir una herramienta de filtrado de registros durante la más reciente ola de spam en el Fediverso, encontré un bug en mi propio motor de detección que me enseñó algo que ya debí haber sabido: la salida de un sistema de seguridad es, en sí misma, una superficie de ataque.

El motor — Sentinel, el clasificador de defensa perimetral detrás de todo lo que construyo — marca texto de registro spam usando un banco de patrones. Ofertas de criptomonedas, aperturas genéricas tipo plantilla, ese tipo de cosas. Cuando un patrón coincidía, la razón de rechazo que regresaba a quien llamaba se veía así:

jsreason: spam phrase matched: /crypto|investment.{0,10}opportunity/i

Legible. Fácil de depurar. Y, si ese mensaje llegaba a la persona rechazada en vez de quedarse en un log privado de administrador — una especificación completa y legible por máquina de exactamente qué palabras evitar. No construí un filtro de spam. Construí un filtro de spam con sus propias instrucciones de cómo evadirlo impresas en la caja.

Nada se rompió. Nada se veía mal en las pruebas. El regex hacía su trabajo perfectamente, cada vez — mientras silenciosamente entregaba la respuesta correcta.

Este no es un error raro. Es el modo de fallo normal de construir sistemas de detección rápido: instrumentas para tu propia depuración, y olvidas que "útil para mí" y "útil para un atacante" muchas veces es el mismo texto.

El invariante

Lo arreglé el mismo día, pero el parche importó menos que la regla que escribí después, y esa regla es la que realmente gobierna Sentinel ahora:

La lógica de detección y la divulgación de la detección son sistemas distintos, y solo uno de los dos llega a quien hizo la solicitud.

Internamente, cada veredicto todavía lleva su razonamiento completo — qué capa se activó, qué patrón coincidió, el peso exacto. Ese detalle es esencial; un sistema de seguridad que no puedes auditar es un sistema que no puedes confiar, ni siquiera desde adentro. Pero nada interno es el mismo objeto que lo que ve un usuario rechazado o una respuesta pública de API. La razón pública se toma de un vocabulario fijo y genérico — "dominio de correo desechable," "frase de spam detectada," "patrón de registro marcado" — deliberadamente incapaz de nombrar un regex específico, un umbral específico, o una entrada específica de una lista. Un atacante que sondea la API puede aprender que algo se activó. No puede aprender qué cambiar para dejar de activarlo.

Esa distinción ahora sostiene todo lo que Sentinel hace, en los dos lugares donde corre.

Dos frentes, un solo motor

Sentinel empezó como defensa perimetral: puntuación a nivel de solicitud en el borde — reputación, velocidad, regularidad de tiempos — decidiendo qué se desafía o bloquea antes de que toque una aplicación. Sentinel Signup es el mismo motor de seis capas apuntando a un problema más específico: colas de registro del Fediverso, que la ola de spam de julio convirtió en una crisis real para instancias de Mastodon administradas por voluntarios. Correos desechables, IPs de centros de datos, texto tipo plantilla de "apruébame por favor," ráfagas de registro desde la misma subred, y — añadido esta semana, después de que un administrador de habla hispana describiera estar siendo golpeado por lo que parecía una ola coordinada en ruso — una señal de discordancia de escritura/idioma: texto de solicitud en una escritura que contradice el idioma declarado de la cuenta.

La misma regla de divulgación aplica a ambos. El guardia perimetral le dice a un cliente desafiado "solicitud marcada." No le dice cuál de las verificaciones de reputación, velocidad, o regularidad se activó, ni por cuánto. Sentinel Signup le dice a un administrador de instancia "bloqueado: dominio de correo desechable; IP de centro de datos; contenido tipo plantilla" — categorías, no la biblioteca de patrones subyacente. Un administrador recibe suficiente para confiar en el veredicto. Un operador de bots no recibe nada para evadirlo.

Falla-a-cola, no falla-abierto ni falla-cerrado

La otra regla que Sentinel Signup impone sin excepción: si el filtrado mismo falla — una dependencia se cae, una consulta falla, lo que sea — el veredicto es marcar para revisión, nunca aprobar y nunca bloquear.

Esa es una tercera opción deliberada que la mayoría de sistemas no construyen. Fallar-abierto en un filtro de spam significa que una caída se convierte en una puerta abierta. Fallar-cerrado significa que un percance de un martes por la tarde bloquea a los nuevos usuarios reales tan duro como a los bots — y cerrar los registros es exactamente la jugada perdedora que los administradores ya estaban haciendo antes de que esto existiera; automatizar esa pérdida no es una solución. Falla-a-cola significa que un error le cuesta a un moderador humano treinta segundos de juicio, y no le cuesta nada al solicitante. El fallo es visible, es barato, y nunca fabrica un veredicto falso en ninguna dirección.

La pieza complementaria es la misma disciplina de falla-ruidosa que uso en todas partes: una conexión de base de datos faltante al arrancar es una negativa a iniciar, no una caída silenciosa a memoria que pierde silenciosamente los datos de cada instancia en el próximo reinicio. Prefiero que el servicio no arranque a que arranque mintiendo sobre lo que puede garantizar.

Limitaciones honestas

Las partes de esto que todavía no están terminadas:

El límite de divulgación se impone hoy por convención a nivel de código — cada ruta de respuesta se revisa a mano para confirmar que toma del vocabulario genérico, no del conjunto de patrones interno. Todavía no se impone estructuralmente, de la forma en que la capa de almacenamiento del feed principal de Candor estructuralmente no puede aceptar contenido sin filtrar. Ese es el próximo paso de endurecimiento, y hasta que se construya, "solo genérico" es una disciplina que mantengo, no una garantía que la arquitectura me da.

El análisis de texto hoy es heurístico y basado en reglas, más la puntuación de contenido propia del motor. No hay un clasificador aprendido en el ciclo, y no hay ningún LLM en el ciclo para el filtrado de registros — lo cual es deliberado: esto necesita funcionar a un costo marginal efectivamente cero por evaluación, ya que las instancias que no pueden pagar por protección contra spam son exactamente las que están siendo golpeadas más duro. Un clasificador opcional, revelado por instancia, está diseñado pero no construido.

La señal de escritura/idioma es nueva — tiene días, un solo patrón de ataque real detrás de ella. Solo se activa cuando una cuenta declara un idioma y el texto del solicitante lo contradice de una forma específica, y una sola coincidencia gana revisión humana, nunca rechazo automático. Ese conservadurismo es intencional; prefiero que falle por defecto un tiempo a que aprenda una mala heurística con evidencia insuficiente.

Soy un fundador solo. Sentinel ha estado corriendo defensa perimetral en producción desde mayo. Sentinel Signup tiene una semana, está vivo, y actualmente es gratis mientras está en beta específicamente para que tráfico adversario real — no casos de prueba sintéticos — me diga dónde realmente está equivocado antes de que alguien pague por ello.

Por qué este orden importa

Todo sistema de detección eventualmente es sondeado por lo mismo que detecta. La pregunta no es si un atacante enviará tráfico de prueba y leerá tus respuestas — lo hará, inmediatamente, así es como descubrió que tu filtro existía. La pregunta es si tu respuesta le enseña algo. Un mensaje de rechazo no es un log privado de depuración. En el momento en que sale de tu proceso, es el reconocimiento gratuito más valioso que le puedes dar a la persona que construiste el sistema para detener.

Si administras una instancia de Mastodon, o cualquier cosa con una cola de registro que esté siendo golpeada ahora mismo, Sentinel Signup es gratis durante la beta en signup.candortheopenfeednetwork.com. Si quieres decirme dónde el límite de divulgación todavía tiene fugas — prefiero escucharlo de ti que de alguien usándolo. Estoy en tips@candortheopenfeednetwork.com, y respondo todo yo mismo.

We Almost Told the Spam Bots How to Beat Us

Ronny Cruz — Mon, 20 Jul 2026 18:19:41 +0000

By Ronny Cruz, founder of Open Feed Network (Candor Network). Solo founder, one production platform, a lot of opinions about what a rejection message is allowed to say.

The bug that convinced me

Two weeks ago, in the middle of building a registration-screening tool during the Fediverse's latest signup-spam wave, I found a bug in my own detection engine that taught me something I should have already known: a security system's output is an attack surface.

The engine — Sentinel, the perimeter-defense classifier behind everything I build — flags spam signup text using a bank of pattern matchers. Cryptocurrency pitches, generic templated openers, that kind of thing. When a pattern matched, the rejection reason returned to the caller looked something like this:

jsreason: spam phrase matched: /crypto|investment.{0,10}opportunity/i

Readable. Debuggable. And, if that message ever reached the person being rejected instead of staying in an admin's private log — a complete, machine-readable specification of exactly which words to avoid. I didn't build a spam filter. I built a spam filter with its own bypass instructions printed on the box.

Nothing crashed. Nothing looked wrong in testing. The regex did its job perfectly, every time — while quietly handing out the answer key.

This is not a rare mistake. It's the normal failure mode of building detection systems fast: you instrument for your own debugging, and you forget that "helpful to me" and "helpful to an attacker" are often the same string.

The invariant

I patched it the same day, but the patch mattered less than the rule I wrote afterward, and the rule is what actually governs Sentinel now:

Detection logic and detection disclosure are different systems, and only one of them ever faces the caller.

Internally, every verdict still carries its full reasoning — which layer fired, which pattern matched, the exact weight. That detail is essential; a safety system you can't audit is a safety system you can't trust, including from yourself. But nothing internal is the same object as what a rejected user or a public API response ever sees. The public reason is drawn from a fixed, generic vocabulary — "disposable email domain," "spam phrase detected," "signup pattern flagged" — deliberately incapable of naming a specific regex, a specific threshold, or a specific list entry. An attacker probing the API can learn that something tripped. They cannot learn what to change to stop tripping it.

That distinction is now load-bearing across both places Sentinel runs.

Two fronts, one engine

Sentinel started as perimeter defense: request-level scoring at the edge — reputation, velocity, timing regularity — deciding what gets challenged or blocked before it touches an application at all. Sentinel Signup is the same six-layer engine pointed at a narrower, more specific problem: Fediverse registration queues, which the July spam wave turned into a genuine crisis for volunteer-run Mastodon instances. Disposable emails, datacenter IPs, templated "please approve me" text, same-subnet signup bursts, and — added this week, after a Spanish-language admin described being hit by what looked like a coordinated Russian-language wave — a script/locale mismatch signal: application text in a script that contradicts the account's declared locale.

Same disclosure rule applies to both. The perimeter guard tells a challenged client "request flagged." It does not tell them which of the reputation, velocity, or timing checks fired, or by how much. Sentinel Signup tells an instance admin "block: disposable email domain; datacenter IP; templated content" — categories, not the underlying pattern library. An admin gets enough to trust the verdict. A bot operator gets nothing to route around.

Fail-to-queue, not fail-open or fail-closed

The other rule Sentinel Signup enforces without exception: if screening itself errors — a dependency times out, a lookup fails, anything — the verdict is flag, never pass and never block.

That's a deliberate third option most systems don't build. Fail-open on a spam filter means an outage becomes an open door. Fail-closed means a Tuesday-afternoon hiccup locks out real newcomers as hard as it locks out bots — and closing registrations is exactly the losing move admins were already making before any of this existed; automating that loss isn't a fix. Fail-to-queue means an error costs a human moderator thirty seconds of judgment, and costs the applicant nothing at all. The failure is visible, it's cheap, and it never manufactures a false verdict in either direction.

The companion piece is the same fail-loud discipline I use everywhere: a missing database connection at boot is a refusal to start, not a silent fallback to memory that quietly loses every tenant's data on the next restart. I'd rather the service not come up than come up lying about what it can guarantee.

Honest limitations

The parts of this that aren't finished yet:

The disclosure boundary is enforced by convention at the code layer today — every response path is hand-reviewed to confirm it draws from the generic vocabulary, not the internal pattern set. It is not yet enforced structurally, the way the storage layer in Candor's core feed structurally cannot accept unscreened content. That's the next hardening step, and until it's built, "generic-only" is a discipline I maintain, not a guarantee the architecture makes for me.

Text analysis today is heuristic and rule-based, plus the underlying engine's own content scoring. There's no learned classifier in the loop, and no LLM in the loop for signup screening at all — which is deliberate: this needs to work at effectively zero marginal cost per screening, since instances that can't pay for spam protection are exactly the ones getting hit hardest. An opt-in classifier, disclosed per-instance, is designed but not built.

The script/locale signal is new — days old, one real attack pattern behind it. It fires only when an account declares a locale and the applicant's text contradicts it in a specific way, and a lone match earns human review, never automatic rejection. That conservatism is intentional; I'd rather it under-fire for a while than teach itself a bad heuristic on thin evidence.

I'm a solo founder. Sentinel has been running perimeter defense in production since May. Sentinel Signup is one week old, live, and currently free while in beta specifically so real adversarial traffic — not synthetic test cases — can tell me where it's actually wrong before anyone pays for it.

Why this ordering matters

Every detection system eventually gets probed by the thing it's detecting. The question isn't whether an attacker will send test traffic and read your responses — they will, immediately, that's how you found out your filter existed. The question is whether your response teaches them anything. A rejection message is not a private debugging log. The moment it leaves your process, it's the most valuable free reconnaissance you can hand the person you built the system to stop.

If you run a Mastodon instance, or anything with a registration queue getting hit right now, Sentinel Signup is free during beta at signup.candortheopenfeednetwork.com. If you want to tell me where the disclosure boundary still leaks — I'd rather hear it from you than from someone using it. I'm at tips@candortheopenfeednetwork.com, and I answer everything myself.

Meet Channel and Zoe — The Faces of Candor Network

Ronny Cruz — Fri, 17 Jul 2026 22:00:09 +0000

Every safety platform needs someone watching the door.

We have two.

Channel — The Guardian

Channel is a dark brindle French Bulldog with a stare that could stop a Russian propaganda bot mid-registration. He doesn't bark much. He doesn't need to. He sits at the gate, watches everything that comes through, and nothing — nothing — gets past him without being screened first.

In the Candor architecture, Channel represents the embedded gateway: the layer where content screening isn't bolted alongside storage as an afterthought, but fused directly into the write path itself. No content enters the feed without passing Channel first. That's not a policy. That's a structural guarantee.

Role: Chief Security Officer
Superpower: Fail-closed by default
Vibe: Calm, serious, deeply unimpressed by your bypass attempt

Zoe — The Detector

Zoe is a merle French Bulldog with one brown eye and one blue wall eye. That mismatched gaze isn't a flaw — it's her whole character. One eye sees what everyone else sees. The other eye sees what's hidden.

She's the one who notices the crisis signal buried in a normal-looking post. The extremism pattern in a livestream transcript. The disinformation score that's just slightly too high. The thing that doesn't throw an error, doesn't crash anything, doesn't show up in any log — but is wrong, and she knows it.

In the Candor architecture, Zoe represents Beacon and the detection layer: the systems that watch the living feed for signals that matter, in English and in Spanish, because harmful content doesn't pick a language.

Role: Chief Detection Officer
Superpower: Sees what others miss — literally
Vibe: Alert, quick, that slightly alarmed look that means she just caught something

The real story

Channel and Zoe are real. They live in Tampa, Florida with the solo founder building all of this — one engineer, one platform, two dogs who apparently take content moderation very seriously.

The decision to make them the faces of Candor wasn't a branding exercise. It was simpler than that: I can't be in videos for legal reasons, and synthetic personas feel dishonest for a company whose name is literally Candor. Real dogs from a real household felt right. They have actual personalities. Channel really does have that stare. Zoe really does have that eye.

A mascot built on something true is harder to forget than one built on a stock photo.

What they're guarding

Candor Network is a social platform and a suite of content-screening APIs built around one architectural invariant:

The database accepts only screened content, because the database forgets nothing.

The feed store is append-only and cryptographically hash-chained. Screening runs before the write — not alongside it, not after it, before it. There is no write path that bypasses the gate. What Channel guards is structurally impossible to sneak past, not just policy-prohibited.

The individual screening modules — crisis detection, extremism classification, disinformation scoring, sextortion detection — are also available as standalone APIs, priced for operators who can't afford enterprise trust-and-safety tooling but can't afford to skip it either. Bilingual EN/ES by design, because the moderation industry's chronic underinvestment in Spanish isn't something we're replicating.

What comes next

Channel and Zoe will be here every week. Channel explains the architecture — the gateway, the hash-chain, the fail-closed matrix, the tombstone redaction. Zoe explains the detection — what the crisis classifier actually looks for, how disinformation scoring works at feed speed, what "bilingual by design" means in practice versus as a marketing claim.

They'll also catch me when I'm wrong. That's their job.

Nothing gets past them.

Candor Network is building safety infrastructure for platforms that can't afford to let things slip through. If you run a Mastodon instance, a Discourse forum, a Discord community, or any platform where harmful content is a real problem — Channel and Zoe are on duty. Reach us at candortheopenfeednetwork@gmail.com. We answer everything ourselves.

Follow Channel and Zoe on Mastodon: @candornetwork@mastodon.social

The Moderation System That Was Running Perfectly — On Nobody

Ronny Cruz — Fri, 17 Jul 2026 17:27:37 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The setup

I'm a solo founder building a social platform where content screening is the whole point. Livestreams get transcribed in real time and fanned out to AI analyzers — extremism detection, crisis detection — and the broadcaster's identity rides along so the system knows whose stream it's screening and can act on it.

Identity flows through a JWT. Client logs in, gets a token, token accompanies the broadcast session, screening pipeline attributes everything correctly. Standard stuff. It worked in every test I ran during development.

Here's the thing about this bug: there was no symptom. No crash, no error log, no user complaint. Streams worked. Screening worked — I could see the analyzers firing. Everything looked healthy. That's what makes this one worth writing up.

The hunt

I run my project under a rule I call §0: "designed," "coded," and "verified working end-to-end" are three different statements, and only probes against the running system count as evidence. It exists because I once caught my deployed system quietly diverging from its design, one easy shortcut at a time, and I decided never again.

So during a verification pass on the broadcast path, I wasn't asking "does streaming work?" — it obviously did. I was asking a more §0 question: prove to me that a logged-in broadcaster's session carries their verified identity into the screening pipeline. Show me the actual value, from the actual running system.

The probe came back wrong. The session that should have been my authenticated test user was attributed to anonymous.

One session, maybe a fluke. I logged in again, fresh. Anonymous. Every single post-login session was anonymous.

The dig

Tracing it backwards through the running system:

The client wasn't sending the token. The broadcast token request went out without an Authorization: Bearer header. The session token existed in the app — it just never got attached to this particular request.
The server didn't mind. The token route did no server-side JWT verification of its own. No token? No problem. It fell through to a default:

const broadcaster = verifiedUser || 'anonymous';

And there was a third layer: even when auth did work, the client wasn't hydrating the session from storage after a page reload — so any refreshed session lost its identity anyway and fell into the same anonymous path.

Three small, defensible-looking decisions. A missing header. A convenient fallback. A skipped hydration step. Each one written with good intentions, none of them logging anything, and together they meant: after login, every session silently fell back to anonymous.

Why does that matter beyond bookkeeping? Because anonymous sessions took a different code path — one that bypassed identity-attributed screening entirely. The moderation stack was deployed, healthy, and fully operational. It just wasn't in the loop for the sessions that mattered. A safety system in the "on" position, wired to nothing.

The fix

Three parts, matching the three failures:

Server-side JWT verification on the token route. The server now verifies the token itself, cryptographically, before issuing anything. Client claims are not trusted.
Client sends Authorization: Bearer <token> on the token request. The obvious missing piece, made explicit.
localStorage hydration on load, so a refreshed session recovers its verified identity instead of silently downgrading.

And then the part I care about most — the fix behind the fix:

The fallback died. Not just this one — the pattern. My platform now runs a fail-loud rule: no silent defaults on anything security- or safety-relevant, anywhere. A missing secret at boot is process.exit(1), not || 'change-me'. A verification failure is a refusal, not a downgrade to a friendlier identity. If the system can't establish who you are, it doesn't guess — it stops, loudly.

Verified after the fix the same way it was caught: probes against the live system, logged with dates. Authenticated session in, verified identity out, screening attributed correctly, on the running box — not in my head, not in the code review.

What this bug taught me

Silent fallbacks are camouflage. || 'anonymous' looks like defensive programming. It's actually a machine for converting failures into fake success. The system didn't degrade visibly — it degraded into something that looked identical to working.

"It works" and "I verified it works" are different sentences. Every test I ran during development passed, because development tests exercise the paths you thought of. The bug lived in the gap between the design in my head and the system on the box, and only a probe of the running system — asking it to prove its own behavior — could see into that gap.

The worst bugs don't throw. Sentry-style error monitoring is essential, but this class of bug never generates an error to monitor — every code path "succeeded." The only detection mechanism is refusing to let failure be expressible as success: fail loud, fail closed on the paths that matter, and make silence itself impossible.

This bug ultimately changed my platform's architecture — I rebuilt the write path so that this entire class of bypass can't exist, which I wrote up separately in How We Made Moderation Architecturally Impossible to Skip. But the architecture came second. First came the humbling: my safety system spent its early life running perfectly, on nobody, and nothing anywhere was ever going to tell me.

Now something does. Loudly.