DEV Community: Ronny Cruz

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.

#bugsmash tag

Ronny Cruz — Fri, 17 Jul 2026 17:15:43 +0000

Cómo hicimos que saltarse la moderación fuera arquitectónicamente imposible

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

Cómo hicimos que saltarse la moderación fuera arquitectónicamente imposible

Por Ronny Cruz Alvarez, fundador de Open Feed Network (Candor Network). Fundador en solitario, una plataforma en producción, y muchas opiniones sobre rutas de escritura.

El bug que me convenció

Hace unas semanas encontré un bug en mi propia plataforma que debería quitarle el sueño a cualquier ingeniero de confianza y seguridad (trust & safety).

Candor filtra las transmisiones en vivo. La identidad del transmisor viaja en un JWT para que el pipeline de filtrado sepa quién está transmitiendo. En algún punto de esa ruta, la verificación del token podía fallar — y cuando fallaba, el código recurría a una identidad por defecto. Algo así:

jsconst broadcaster = verifiedUser || 'anonymous';

Un solo ||. Escrito a la defensiva, con buenas intenciones, probablemente a la 1 de la madrugada. El efecto: después del login, cada sesión caía silenciosamente en "anonymous" — y las sesiones anónimas tomaban una ruta de código que evadía todo el sistema de filtrado. No un clasificador. Todos.

Nada se rompió. Nada registró un error. El sistema de moderación estaba completamente desplegado, completamente funcional, y no estaba corriendo.

Y aquí está lo importante: este no es un bug raro. Es el modo de fallo normal de cómo toda la industria conecta la moderación. Y es la razón por la que dejé de confiar en la arquitectura estándar y reconstruí la mía alrededor de un solo invariante.

La arquitectura estándar es una promesa, no una garantía

Casi todas las plataformas — sin importar qué proveedor de moderación usen — funcionan así:

contenido del usuario → código de aplicación → [llamar al API de moderación, ojalá] → base de datos → feed

El filtrado y el almacenamiento son dos sistemas separados, conectados por código de aplicación. Lo que significa que la garantía de "todo se filtra" es tan fuerte como cada ruta de código que pueda escribir en la base de datos. Cada endpoint. Cada trabajo en segundo plano. Cada script de migración. Cada fallback bien intencionado escrito a la 1 de la madrugada.

Esa garantía se degrada de maneras que nunca aparecen en un demo:

Un ingeniero agrega una nueva ruta de escritura y olvida la llamada al filtrado.
Una condición de carrera sirve el contenido antes de que regrese el filtrado asíncrono.
El servicio de moderación está caído y el código "falla abierto" para no bloquear a los usuarios.
Un fallback silencioso (ver arriba) le da la vuelta a la verificación por completo.

Cuando algo eventualmente se cuela y alguien pregunta "¿tu moderación corrió sobre esta publicación?", lo único que tienes es un log de aplicación afirmando que la verificación ocurrió. Los logs se contradicen con otros logs. Un log es una afirmación, no una prueba.

El invariante

El feed de Candor está construido sobre una sola oración, y cada decisión arquitectónica se verifica contra ella:

La base de datos acepta únicamente contenido filtrado, porque la base de datos no olvida nada.

Dos propiedades, y una fuerza a la otra:

El almacén es de solo-anexar (append-only) e inmutable. Las entradas del feed forman una cadena criptográfica de hashes: cada entrada compromete el hash de la anterior. Alterar cualquier entrada pasada rompe todos los hashes subsiguientes. La manipulación no está prohibida por política — es matemáticamente detectable.
Como no existe el "lo borro después", el filtrado tiene que correr antes de la escritura. En un almacén inmutable, guardar-y-luego-filtrar no es un orden peor. Es un orden prohibido, por definición. La puerta es la guardiana de un acto irreversible.

Así que la arquitectura no es "llama al API de moderación antes de guardar, y con code review nos aseguramos de que todos lo hagan". Es: la puerta de filtrado y la ruta de escritura al almacén son el mismo sistema. No existe ruta de escritura hacia el almacén del feed que no haya pasado ya por la puerta — no como convención, como propiedad estructural. La clase de bug del || 'anonymous' ya no puede evadir el filtrado, porque no hay nada del otro lado del filtrado a donde caer.

"Espera — ¿inmutable? ¿Y las órdenes legales de eliminación?"

Esta es la primera objeción que todo el mundo levanta, y es buena. El derecho al olvido del GDPR, las órdenes judiciales y los contenidos que genuinamente se cuelan son reales. Un feed inmutable que no puede cumplir con la ley de remoción de contenido no sirve.

La respuesta es la redacción por lápida (tombstone redaction). Cada entrada almacena permanentemente hash(contenido) — un compromiso de contenido — separado del contenido mismo. Cuando la remoción es legalmente requerida, el contenido se elimina, pero el espacio de la entrada, su hash comprometido y sus enlaces de cadena permanecen, reemplazados por una lápida: aquí existió una entrada; removida por la razón X; fecha Y; autoridad Z.

La validación de la cadena corre contra el hash comprometido, así que redactar una entrada nunca rompe la verificabilidad de ninguna otra. Obtienes ambas cosas: el contenido desaparece de verdad, y el registro de que existió, fue filtrado y fue removido bajo autoridad declarada es permanente y demostrable. Este fue el componente más delicado de construir.

Fallar cerrado — pero no en todo, y ese es el punto

"Fallar cerrado" (fail-closed) es un gran eslogan y una pésima política universal. Si cada error de filtrado bloqueara cada publicación, una sola dependencia inestable tumbaría la plataforma, y el arreglo de la guardia terminaría siendo… un parche que falla abierto. Felicidades: reinventaste el bypass silencioso, ahora con pasos extra.

Así que la puerta tiene una matriz de fallos por severidad:

Ruta de filtradoAnte un errorPor quéContenido terrorista / extremismo violentoFalla cerrado — no se almacenaRuta de daño catastróficoCSAM (comparación de hashes)Falla cerrado — no se almacenaLegal + catastróficoPuntuación de credibilidadPuede fallar abierto — se almacena sin puntuaciónUna puntuación faltante degrada una función; no daña a nadieVerificación de discurso protegidoSolo-degrada — puede reducir la severidad de un veredicto, nunca puede bloquear, nunca puede saltarse el filtradoPreviene la sobre-censura y evita que "la propaganda disfrazada" use la verificación de contexto como bypass

Una puntuación de credibilidad perdida y una verificación de CSAM perdida no son el mismo fallo. Tratarlas igual es como terminas siendo o inusable o inseguro.

La regla compañera es fallar ruidosamente (fail-loud): en Candor, un secreto faltante al arrancar es process.exit(1), nunca un valor por defecto. Nada de || 'change-me'. Nada de || 'anonymous'. Esa regla me ha atrapado personalmente bugs que de otra forma habrían sido invisibles — incluyendo uno donde un manejador de errores devolvía un valor con apariencia segura de "ninguna señal detectada" que en realidad estaba enmascarando fallos del API upstream. Un falso "todo despejado" es la peor salida posible de un sistema de seguridad, y la única defensa confiable que he encontrado es negarse a que cualquier ruta de código pueda fabricar uno.

Limitaciones honestas

Algunas cosas que esta arquitectura no resuelve mágicamente, porque los artículos de arquitectura que declaran victoria total están mintiendo:

Las transmisiones en vivo no se pueden pre-filtrar. No puedes poner una puerta a audio/video en vivo antes de que exista. Los streams corren un modelo distinto: transcripción en tiempo real distribuida a los analizadores, con detección en línea y respuesta a nivel del stream. La garantía de inmutabilidad-en-ingreso aplica al feed y a los mensajes; el contenido en vivo se gobierna por velocidad de detección, y sigo activamente reduciendo esa latencia.
La garantía es estructural, y la prueba criptográfica externa está en desarrollo. La cadena de hashes hace la manipulación internamente detectable hoy; publicar los hashes de la cabeza de la cadena en un ancla externa — para que la prueba sea verificable por terceros que no confían en mí — está diseñado y en progreso, no terminado.
La calidad del filtrado sigue siendo un problema de clasificadores. Esta arquitectura garantiza que el filtrado corrió; no hace al clasificador perfecto. Lo que cambia es la clase de fallo: de "la verificación silenciosamente no ocurrió" a "la verificación ocurrió y aquí está el registro".
Soy un fundador en solitario con un solo despliegue en producción — mi propia plataforma, que lleva corriendo esto en producción con una beta en vivo desde el 4 de julio. Esa es la escala honesta de la evidencia hoy. Cada capacidad que afirmo está verificada contra el sistema corriendo, con sondas fechadas, no inferida del código ni de la intención; esa disciplina existe porque una vez atrapé a mi propio sistema desplegado desviándose de su diseño, silenciosamente, un atajo fácil a la vez. El análisis de patente sobre la arquitectura está en curso con asesoría legal.

Una nota más, específica para esta versión: la plataforma se construyó bilingüe, inglés y español, desde el diseño — la detección de crisis y la transcripción de streams operan en ambos idiomas. La moderación en español es una carencia documentada de toda la industria; para nosotros no es una traducción añadida después, es parte del sistema.

Por qué creo que este orden gana

La regulación se está moviendo de "¿moderaste?" a "demuestra que moderaste". La Ley de Servicios Digitales (DSA) de la Unión Europea ya apunta en esa dirección. Cuando esa pregunta llegue a tu plataforma, un log de aplicación es una respuesta débil. Una capa de almacenamiento que estructuralmente no puede aceptar contenido sin filtrar — con una cadena a prueba de manipulación mostrando exactamente qué se filtró, cuándo, y qué se removió bajo qué autoridad — es otro tipo de respuesta.

Guardar-y-luego-filtrar tenía sentido cuando el almacenamiento era mutable y la moderación era una idea de último momento. En un almacén inmutable, filtrar-antes-de-guardar no es una preferencia. Es el único orden legal. Esa restricción resultó ser la decisión de diseño más clarificadora que he tomado.

Candor Network es el despliegue de referencia. Los módulos individuales de filtrado (detección de crisis, clasificación de extremismo, puntuación de desinformación, detección de sextorsión) también están disponibles como APIs independientes — en inglés y español. Si administras una plataforma o comunidad y algo de esto se parece a un problema que tienes — o quieres decirme por qué estoy equivocado sobre la matriz de fallos — escríbeme a candortheopenfeednetwork@gmail.com. Contesto todo yo mismo, en el idioma que prefieras.

How We Made Moderation Architecturally Impossible to Skip

Ronny Cruz — Fri, 17 Jul 2026 13:14:16 +0000

How We Made Moderation Architecturally Impossible to Skip

By Ronny Cruz Alvarez, founder of Open Feed Network (Candor Network). Solo founder, one production platform, a lot of opinions about write paths.

The bug that convinced me

A few weeks ago I found a bug in my own platform that should keep every trust-and-safety engineer up at night.

Candor screens livestream broadcasts. The broadcaster's identity flows through a JWT so the screening pipeline knows who's streaming. Somewhere in that path, a token verification could fail — and when it did, the code fell back to a default identity. Something like:

jsconst broadcaster = verifiedUser || 'anonymous';

One ||. Written defensively, with good intentions, probably at 1am. The effect: after login, every session silently fell back to anonymous — and anonymous sessions took a code path that bypassed the entire screening stack. Not one classifier. All of them.

Nothing crashed. Nothing logged an error. The moderation system was fully deployed, fully functional, and not running.

Here's the part that matters: this is not an unusual bug. It's the normal failure mode of how the entire industry wires up moderation. And it's why I stopped trusting the standard architecture and rebuilt mine around a single invariant.

The standard architecture is a promise, not a guarantee

Almost every platform — regardless of which moderation vendor they use — works like this:

user content → application code → [call the moderation API, hopefully] → database → feed

Screening and storage are two separate systems, connected by application code. Which means the guarantee "everything gets screened" is only as strong as every code path that could ever write to the database. Every endpoint. Every background job. Every migration script. Every well-intentioned fallback written at 1am.

That guarantee degrades in ways that never show up in a demo:

An engineer adds a new write path and forgets the screening call.
A race condition serves content before the async screen returns.
The moderation service is down and the code "fails open" so users aren't blocked.
A silent fallback (see above) routes around the check entirely.

When something eventually slips through and someone asks "did your moderation run on this post?", all you have is an application log claiming a check happened. Logs get contradicted by other logs. A log is a claim, not a proof.

The invariant

Candor's feed is built on one sentence, and every architectural decision is checked against it:

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

Two properties, and they force each other:

The store is append-only and immutable. Feed entries form a cryptographic hash-chain: each entry commits the hash of the previous one. Altering any past entry breaks every subsequent hash. Tampering isn't forbidden by policy — it's mathematically detectable.
Because there is no "remove it later," screening must run before the write. On an immutable store, store-then-screen isn't a worse ordering. It's a prohibited one, by definition. The gate is the gatekeeper of an irreversible act.

So the architecture is not "call the moderation API before saving, and we'll code-review to make sure everyone does." It's: the screening gate and the storage write path are the same system. There is no write path into the feed store that hasn't already passed the gate — not as a convention, as a structural property. The || 'anonymous' class of bug can't bypass screening anymore, because there's nothing on the other side of screening to fall through to.

"Wait — immutable? What about legal takedowns?"

This is the first objection everyone raises, and it's a good one. GDPR erasure, court orders, and genuine slip-throughs are real. An immutable feed that can't comply with removal law is a non-starter.

The answer is tombstone redaction. Every entry permanently stores hash(content) — a content commitment — separately from the content payload. When removal is legally required, the payload is deleted, but the entry's slot, its committed hash, and its chain links remain, replaced with a tombstone: entry existed here; removed for reason X; date Y; authority Z.

Chain validation runs against the committed hash, so redacting one entry never breaks verifiability for any other entry. You get both: the content is genuinely gone, and the record that it existed, was screened, and was removed under stated authority is permanent and provable. This was the single most delicate component to build, and it was built and tested first, before anything depended on it.

Fail-closed — but not everywhere, and that's the point

"Fail closed" makes a great slogan and a terrible universal policy. If every screening error blocked every post, one flaky dependency would take the platform down, and the on-call fix would inevitably be… a fail-open patch. Congratulations, you've reinvented the silent bypass, now with extra steps.

So the gate has a severity-tiered failure matrix instead:

Screening pathOn errorWhyTerrorism/violent-extremism contentFail closed — do not storeCatastrophic-harm pathCSAM (hash-matching)Fail closed — do not storeLegal + catastrophicCredibility scoringMay fail open — store without a scoreA missing score degrades a feature; it harms no oneProtected-speech context checkDowngrade-only — can reduce a verdict's severity, can never block, can never skip screeningPrevents over-censorship and prevents "propaganda in costume" from using the context check as a bypass

A missed credibility score and a missed CSAM check are not the same failure. Treating them the same is how you end up either unusable or unsafe.

The companion rule is fail-loud: on Candor, a missing secret at boot is process.exit(1), never a default value. No || 'change-me'. No || 'anonymous'. That rule has personally caught bugs for me that would otherwise have been invisible — including one where an error handler returned a safe-looking "no signal detected" value that was actually masking upstream API failures. A fake all-clear is the worst possible output of a safety system, and the only reliable defense I've found is refusing to let any code path manufacture one.

Honest limitations

A few things this architecture does not magically solve, because architecture posts that claim total victory are lying:

Livestreams can't be pre-screened. You cannot gate live audio/video before it exists. Streams run a different model: real-time transcription fanned out to analyzers, with in-line detection and stream-level response. The immutable-at-ingress guarantee applies to the feed and messages; live media is governed by detection speed, and I'm still actively working that latency down.
The guarantee is structural, and the cryptographic external proof is in development. The hash-chain makes tampering internally detectable today; publishing chain-head hashes to an external anchor — so the proof is verifiable by third parties who don't trust me — is designed and in progress, not done.
Screening quality is still a classifier problem. This architecture guarantees screening ran; it does not make the classifier perfect. What it changes is the failure class: from "the check silently didn't happen" to "the check happened and here's the record."
I'm a solo founder with one production deployment — my own platform, which has been running this in production with a live beta since July 4th. That's the honest scale of the evidence today. Every capability claim I make is verified against the running system with dated probes, not inferred from code or intent; that discipline exists because I once caught my own deployed system diverging from its design, silently, one easy shortcut at a time. Patent analysis on the architecture is underway with counsel.

Why I think this ordering wins

Regulation is moving from "did you moderate?" to "prove you moderated." The EU's DSA already points that way. When that question arrives at your platform, an application log is a weak answer. A storage layer that structurally cannot accept unscreened content — with a tamper-evident chain showing exactly what was screened, when, and what was removed under what authority — is a different kind of answer.

Store-then-screen made sense when storage was mutable and moderation was an afterthought. On an immutable store, screen-before-store isn't a preference. It's the only legal ordering. That constraint turned out to be the most clarifying design decision I've made.

Candor Network is the reference deployment. The individual screening modules (crisis detection, extremism classification, disinformation scoring, sextortion detection) are also available as standalone APIs. If you run a platform or community and any of this maps to a problem you have — or you want to tell me why I'm wrong about the failure matrix — I'm at candortheopenfeednetwork@gmail.com, and I answer everything myself.