El objetivo de este fork es mantener y documentar los cambios que utilizamos en la infraestructura de Escuela Común mientras estos todavía no estén incorporados en la receta oficial.

No buscamos mantener una versión independiente de la receta. La intención es seguir de cerca el desarrollo de Co-op Cloud y retirar nuestros parches cuando upstream incorpore una solución equivalente.

Organización de las ramas

`main`

Es un espejo del desarrollo oficial de:

coop-cloud/mastodon:main

No realizamos modificaciones propias directamente sobre esta rama.

`escuela-comun`

Contiene únicamente las modificaciones que Escuela Común todavía necesita mantener encima de la receta oficial.

Cambios mantenidos actualmente

Ejecutar Rails/Puma como usuario `mastodon`

La configuración compose.character-limit.yml necesita ejecutar inicialmente algunas tareas como root para modificar archivos de Mastodon mediante sed.

La receta oficial termina iniciando Rails/Puma mediante:

su -c "RAILS_ENV=production bundle exec rails s -p 3000"

En este contexto Rails/Puma continúa ejecutándose como root.

En nuestra instalación observamos que esto provocaba que algunos archivos multimedia fueran creados como:

root:root

mientras Sidekiq procesa los adjuntos utilizando el usuario mastodon.

El problema se manifestó especialmente durante el procesamiento de videos: Sidekiq podía encontrar archivos creados con permisos incompatibles y fallar durante el postprocesamiento.

Nuestra modificación mantiene como root solamente la preparación inicial y posteriormente inicia Rails/Puma explícitamente como el usuario mastodon:

exec su -s /bin/sh -c \
  "RAILS_ENV=production bundle exec rails s -p 3000" \
  mastodon

Después de aplicar este cambio comprobamos que:

Rails/Puma se ejecuta como mastodon;
los archivos multimedia nuevos son creados con permisos compatibles;
Sidekiq puede realizar el postprocesamiento;
la carga y procesamiento de videos funciona correctamente.

Existe un seguimiento relacionado en upstream:

coop-cloud/mastodon#63

Este parche debe retirarse cuando la receta oficial incorpore una solución equivalente.

Mitigación temporal contra solicitudes automatizadas `“Boom Protocol” / “BoomProtocolProbe”`

Contexto

Durante septiembre de 2026 observamos una campaña automatizada de solicitudes de registro contra Mastodon.

Las solicitudes presentan nombres con un patrón similar a:

bp60...
bp129...
bp...

y utilizan como motivo de registro:

Automated protocol deliverability probe

Las solicitudes llegan desde múltiples direcciones IP y utilizan diferentes proveedores de correo.

En nuestro caso, la rotación de IP y dominios hizo que el bloqueo individual por IP o por proveedor de correo no fuera una solución suficiente.

Impacto observado

Estas solicitudes pueden:

llenar la cola de solicitudes de registro;
generar actividad innecesaria en Mastodon;
provocar envíos repetidos de correos de confirmación;
dificultar distinguir solicitudes legítimas;
generar carga innecesaria en Rails, PostgreSQL, Sidekiq y el servicio de correo.

Mitigación utilizada

Se añadió una restricción CHECK sobre la tabla:

public.user_invite_requests

La restricción rechaza nuevas filas cuyo campo text sea:

Automated protocol deliverability probe

La restricción utilizada es:

CHECK (
  text IS NULL
  OR text NOT ILIKE 'Automated protocol deliverability probe'
)

Inicialmente se crea como:

NOT VALID

Esto permite que existan solicitudes antiguas que ya contienen el texto bloqueado, pero hace que los nuevos INSERT y UPDATE tengan que cumplir la restricción desde el momento en que se instala.

Aplicar la mitigación

El script se encuentra en:

scripts/mitigacion-bp-spam.sql

Puede aplicarse desde el directorio de la receta ~/.abra/recipes/mastodon con:

abra aplicacion lanzar medialibre.social db -- \
  psql \
    -U mastodon \
    -d mastodon_production \
  < scripts/mitigacion-bp-spam.sql

Antes de modificar el esquema se recomienda crear un respaldo de la tabla:

abra aplicacion lanzar medialibre.social db -- \
  pg_dump \
    -U mastodon \
    -d mastodon_production \
    -t user_invite_requests \
    -Fc \
  > /home/yanadmin/user_invite_requests_pre_bp_filter.dump

Comprobar la restricción

abra aplicacion lanzar medialibre.social db -- \
  psql \
    -U mastodon \
    -d mastodon_production \
    -c "
SELECT
  conname,
  convalidated,
  pg_get_constraintdef(oid)
FROM pg_constraint
WHERE conname = 'invite_block_boom_protocol';
"

Mientras existan solicitudes antiguas que violan la regla, convalidated aparecerá como:

Esto es esperado cuando la restricción fue creada con NOT VALID.

Aunque todavía no esté validada contra todas las filas históricas, las filas nuevas y las actualizaciones sí quedan sujetas a la restricción.

Validar definitivamente la restricción

Primero se rechazan todas las solicitudes a través de la interfaz de adminsitración web. Una vez que ya no existan filas antiguas incompatibles, puede desde la carpeta de la receta ~/.abra/recipes/mastodon validarse utilizando:

scripts/validar-mitigacion-bp-spam.sql

Puede aplicarse con:

abra aplicacion lanzar medialibre.social db -- \
  psql \
    -U mastodon \
    -d mastodon_production \
  < scripts/validar-mitigacion-bp-spam.sql

Si todavía existen filas antiguas que violan la restricción, PostgreSQL rechazará la validación.

El estado esperado es:

invite_block_boom_protocol | t

Retirar la mitigación

La mitigación debe considerarse temporal.

Si la campaña termina, cambia de comportamiento o Mastodon incorpora una solución adecuada, puede retirarse desde la carpeta de la receta ~/.abra/recipes/mastodon utilizando:

scripts/quitar-mitigacion-bp-spam.sql

Ejemplo:

abra aplicacion lanzar medialibre.social db -- \
  psql \
    -U mastodon \
    -d mastodon_production \
  < scripts/quitar-mitigacion-bp-spam.sql

La restricción también puede retirarse manualmente mediante:

ALTER TABLE public.user_invite_requests
DROP CONSTRAINT IF EXISTS invite_block_boom_protocol;

Limitaciones de esta mitigación

Esta regla reconoce específicamente el texto:

Automated protocol deliverability probe

Si la campaña cambia el contenido de las solicitudes, esta regla dejará de reconocerlas.

Por esta razón no debe considerarse una solución general contra bots.

Tampoco se ejecuta automáticamente durante un despliegue de la receta, porque modifica el esquema interno de la base de datos de Mastodon fuera de sus migraciones oficiales.

La decisión de aplicarla o retirarla debe ser explícita y documentada.

README.md

Mastodon — adaptaciones de Escuela Común