DEV Community: Ronny Cruz

Parental Consent Without Storing Identity Documents

Ronny Cruz — Thu, 20 Aug 2026 19:18:50 +0000

Authorization is not permanent identification
The requirement may be to establish that parental authorization occurred. That does not
necessarily mean the application needs permanent access to passport images, driver licenses,
complete dates of birth, document numbers or addresses.
Minimize what survives the ceremony
A privacy-preserving workflow can separate the authorization ceremony from the application
record: parent/guardian -> authorization process -> required condition verified -> attestation/proof
-> child account.
Data minimization as engineering
Do not retain sensitive identity information merely because it passed through a verification
workflow. Retention should be tied to what the application actually needs and to applicable
obligations.
The platform still needs evidence
Cryptographic attestations and auditable records can preserve evidence of the authorization event
rather than unnecessarily preserving every piece of underlying personal information.
Connect parental consent to age assurance
Parental authorization can sit inside a larger safety architecture: age assurance -> minor? ->
parental ceremony -> authorized? -> continue or restrict.
Related concepts
Privacy-Preserving Age Assurance; Cryptographic Evidence Preservation.
DON'T TRUST US. VERIFY US.
Test the system, inspect the architecture, and decide whether it belongs in your safety
stack.
candortrustandsafety.com

From Safety Decision to Compliance Evidence: Building a Tamper-Evident Trust & Safety Ledger

Ronny Cruz — Thu, 20 Aug 2026 19:16:12 +0000

Logging is not automatically auditability
A stronger Trust & Safety record connects event -> policy version -> assurance/risk result ->
decision -> actor/system -> evidence reference -> timestamp -> cryptographic integrity.
Why tamper evidence matters
If historical safety records can be rewritten without detection, governance suffers. Cryptographic
chaining can make modification detectable by linking records so that changes disrupt subsequent
verification.
Candor Ledger
Candor Ledger is designed around verifiable decision history. The objective is not simply 'we
logged it.' It is to demonstrate the integrity and sequence of the record.
Policy changes matter
Historical decisions should remain associated with the policy context under which they were
actually made rather than silently appearing under a later policy version.
Accountability, not overclaiming
A tamper-evident ledger does not itself create legal compliance. It can provide stronger operational
foundations for reconstructing what happened, when, under which policy and with which evidence.
Related concepts
Cryptographic Evidence Preservation for Trust & Safety.
DON'T TRUST US. VERIFY US.
Test the system, inspect the architecture, and decide whether it belongs in your safety
stack.
candortrustandsafety.com

Cryptographic Evidence Preservation for Trust & Safety

Ronny Cruz — Thu, 20 Aug 2026 19:13:29 +0000

Storage and evidence are not the same thing

Traditional storage asks whether the file still exists. Evidence preservation asks whether the
organization can demonstrate that what it has is the same thing that was preserved. Cryptographic
hashing can provide a mechanism for detecting modification.
Separate custody and cryptographic control
Candor's architecture separates storage custody from cryptographic control: Candor controls the
storage vault; the customer controls the encryption key. Possessing encrypted material is not
equivalent to possessing the customer's decryption authority.
Preservation should fail loudly
A preservation attempt that silently fails can create serious problems later. A security-oriented
preservation system should make failure visible and auditable, with alerting or escalation rather
than silent continuation.
Evidence needs context
Preserving an object does not explain why it was preserved. Pairing Evidence Preservation with
Ledger can associate evidence with the event, policy, decision, timestamp and authorized actor or
system.
Related concepts
Tamper-Evident Trust & Safety Ledger.
DON'T TRUST US. VERIFY US.
Test the system, inspect the architecture, and decide whether it belongs in your safety
stack.
candortrustandsafety.com

Privacy-Preserving Age Assurance: Prove What Matters Without Collecting Everything

Ronny Cruz — Thu, 20 Aug 2026 19:08:32 +0000

The core problem

Platforms need enough information to make age-appropriate decisions, but collecting more
personal information can itself create risk. The objective should be to establish the minimum fact
required for the decision.
Privacy as a design requirement
Instead of asking how to collect someone's identity, ask what fact the application actually needs.
The application may need to know that an age threshold has been satisfied rather than retaining a
complete identity record.
Separate proof from identity
Candor's privacy-oriented approach minimizes personal information retained by the platform.
Conceptually: age assurance process -> required condition established -> assurance result ->
application decision.
Gaming context
Games often serve mixed-age populations. A platform may need to determine whether a player is
a minor, which communications are permitted, whether parental authorization is required and
whether additional safeguards should apply.
Related concepts
Gaming Trust & Safety Infrastructure; Parental Consent Without Identity-Document Storage.
DON'T TRUST US. VERIFY US.
Test the system, inspect the architecture, and decide whether it belongs in your safety
stack.
candortrustandsafety.com

Trust & Safety for Indie Game Studios Without Building a Trust & Safety Department

Ronny Cruz — Thu, 20 Aug 2026 18:59:49 +0000

Trust & Safety for Indie Game Studios Without
Building a Trust & Safety Department
The build-everything-yourself trap
Once a game adds chat, messaging, user-generated content, player accounts or social interaction,
a small studio may need to consider age signals, parental authorization, reporting, escalation,
policy enforcement, recordkeeping, evidence preservation and privacy. Building every layer
internally consumes engineering capacity.
Start with the actual risk surface
Ask what players can actually do. Can minors use the service? Can adults and minors
communicate? Can players communicate privately? Can they upload content? Can they contact
strangers? Can serious incidents require evidence preservation? These questions produce a more
useful architecture than starting with a vendor list.
Don't build a department before you need one
Infrastructure can allow a smaller studio to adopt capabilities incrementally. Age and authorization
signals can feed Ceremony and Assurance. Later social interaction can add Ledger and Evidence
Preservation as the risk surface grows.
The Candor Founder approach
The approach is not 'buy the biggest safety stack possible.' It is: identify the risk -> establish the
required control -> preserve the evidence -> expand when necessary.
Related concepts
Privacy-Preserving Age Assurance; Parental Consent Without Identity Documents; Ledger;
Evidence Preservation.
DON'T TRUST US. VERIFY US.
Test the system, inspect the architecture, and decide whether it belongs in your safety
stack.
candortrustandsafety.com

Gaming Trust & Safety Infrastructure: Building Safety Into the Platform, Not Around It

Ronny Cruz — Thu, 20 Aug 2026 18:54:43 +0000

Moderation is only one part of the system
Online games are social environments. Players communicate, create content, form communities,
establish identities, make purchases and report one another. Modern Trust & Safety architecture
therefore has to address more than post-event moderation: assurance signals, applicable policy,
decision provenance, supporting evidence and the ability to reconstruct what happened later.
The Candor Catalyst approach
Candor separates this lifecycle into complementary capabilities. Ceremony establishes governed
assurance and authorization workflows. Assurance applies safety and risk decisions. Ledger
creates an auditable history of those decisions. Evidence Preservation protects critical evidence
when an incident requires preservation. Conceptually: player event -> assurance -> safety
decision -> auditable record -> evidence preservation.
Preserve developer control
Operational rules may differ by title, population, jurisdiction, interaction type and risk level. Certain
security properties should remain difficult to accidentally configure away, including evidence
integrity, tenant isolation, auditable decision history and reliable preservation behavior.
Privacy belongs inside the architecture
Safety systems can create new privacy risks if they collect excessive information. Candor treats
privacy-preserving age assurance as an architectural problem rather than simply an
identity-verification problem.
After the safety decision
A serious player-safety event may need to be reconstructed months later. Ledger and Evidence
Preservation address what happened, what policy applied, what decision was made, when it
happened and what evidence supported it.
Related concepts
Indie Game Studio Safety; Privacy-Preserving Age Assurance; Tamper-Evident Trust & Safety
Ledger; Cryptographic Evidence Preservation.
DON'T TRUST US. VERIFY US.
Test the system, inspect the architecture, and decide whether it belongs in your safety
stack.
candortrustandsafety.com

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