Planet Debian Spanish – Planeta UNPLUG

Una vez configurados Prosody y Jicofo, el siguiente elemento (y último necesario para usar Jitsi Meet) será el Videobridge. El Videobridge es un Selective Forwarding Unit (SFU), esto significa que no hace ningún tipo de procesamiento de los flujos de vídeo, simplemente recoje el vídeo de cada participante y lo hace llegar al resto. Esto se traduce en:

Gran uso de ancho de banda, cada señal de vídeo que llega debe ser multiplicada por el número de participantes (menos uno, su origen). Si tenemos 5 participantes con cámaras activas, pongamos a 500kbps cada flujo. Tendremos 2.5Mbps de entrada en el videobrige y casi 10Mbps de salida de éste a los clientes. Podemos limitar este tráfico a los clientes con el parámetro channelLastN en la configuración de Jitsi Meet que comentaré más adelante, aliviando la carga en los navegadores.
Uso comedido de RAM y CPU. Al no tener que procesar los vídeos, el uso de estos recursos no es alto. Para conferencias con menos de 30-40 participantes, y un número razonable de cámaras abiertas, 1-2 cores y 2-3GB de RAM serán suficientes. Atención: por defecto el Videobridge podría reclamar hasta 3GB de RAM. Podemos limitar esa cantidad (si tenemos menos de 4GB de RAM) usando el parámetro VIDEOBRIDGE_MAX_MEMORY=XXXXm con los megas que queramos, por defecto 3072m, en el fichero /etc/jitsi/videobridge/config.

Dicho esto, podemos correr tantos Videobridge como deseemos, lo que permite escalar en horizontal. Podemos partir de un Videobridge en la misma máquina que Prosody y Jicofo, o dejar éstos en un servidor (con muy pocos requisitos de memoria y CPU) y luego ir añadiendo máquinas con Videobridge.

Configuración de un Videobridge

Al igual que pasaba con Jicofo, tenemos dos ficheros principales de configuración para un Videobridge. De hecho, hay información redundante en ellos. El motivo es que existen varios mecanismos de comunicación (APIs) de los Videobridge con el mundo exterior. Hasta no hace mucho la conexión entre Videobridge y Prosody se hacía registrando el Videobridge como un componente (servicio) en Prosody. Hoy la preferencia es el uso de MUCs (canales). Y de ahí los rastros que van quedando por su configuración.

Empecemos por /etc/jitsi/videobridge/config, donde encontramos parámetros de arranque del proceso y configuración de XMPP como componente:

# Configuración componente XMPP
JVB_HOSTNAME=EXAMPLE.NET
JVB_HOST=MI_SERVIDOR_PROSODY
JVB_PORT=5347
JVB_SECRET=CLAVE_DE_COMPONENTE
# Opciones arranque
JVB_OPTS="--apis=,"
JAVA_SYS_PROPS=".......

El primer grupo de opciones no serían necesarias si no registramos Videobridge como componente. No hay mucho que explicar de ellas y la tendencia del proyecto es usar MUCs.

Si es digna de mención la opción JVB_OPTS. En versiones actuales lleva el valor "--apis=,", que levantará el cliente XMPP (como usuario normal, no componente) por defecto. Antiguamente era necesario especificarlo (con el valor xmpp). También podemos activar un API REST u otro llamado Colibri del que se pueden sacar estadísticas del Videobridge. Por eso es frecuente ver en documentación no muy actual el valor "--apis=rest,xmpp". Salvo que queramos el API REST activo, no es necesario modificar esta variable. Por el MUC, que ahora configuraremos, también se obtienen estadísticas del Videobridge e incluso hay un exportador para prometheus que usa este mecanismo.

El fichero en el que realmente hay que configurar Videobridge en sus versiones más modernas (videobridge2) es /etc/jitsi/videobridge/sip-communicator.properties:

org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc
org.jitsi.videobridge.STATISTICS_INTERVAL=5000
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=MI_SERVIDOR_PROSODY
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.EXAMPLE.NET
org.jitsi.videobridge.xmpp.user.shard.USERNAME=USUARIO_XMPP
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=CLAVE_XMPP
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=NOMBRE_DEL_JVB
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=lospuentes@internal.auth.EXAMPLE.NET
org.jitsi.videobridge.AUTHORIZED_SOURCE_REGEXP=lospuentes@internal.auth.EXAMPLE.NET/focus.*$
org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

Las dos primeras opciones (DISABLE_AWS_HARVESTER y STUN_MAPPING_HARVESTER_ADDRESSES) están relacionada con el protocolo ICE desarrollado por Jitsi y que sirve para gestionar las conexiones que atraviesan NAT. La primera no es relevante salvo que tengamos el servidor en AWS y la segunda deberemos especificarla si nuestro videobridge está detrás de algún NAT (es decir, no tiene una IP pública pero se usará con clientes de fuera de su red local). El servidor especificado en este ejemplo (meet-jit-si-turnrelay.jitsi.net:443) es el que pone la configuración del paquete, pero podríamos usar uno bajo nuestro control para no depender de este servicio externo.

A continuación vienen tres opciones (ENABLE_STATISTICS, STATISTICS_TRANSPORT y STATISTICS_INTERVAL) que indican que queremos las estadísticas, y con que frecuencia (en milisegundos) por el MUC de comunicación con Jicofo. Estas, además de poder exportarse a Prometheus u otra herramienta, permiten que Jicofo tenga conocimiento de la carga en cada uno de los Videobridges permitiendo que balancee correctamente las nuevas conferencias entre ellos.

Luego tenemos toda la configuración del Videobridge como cliente XMPP. La opción HOSTNAME apuntará al servidor XMPP y podrá ser localhost si corre en la misma máquina o tener la IP o nombre de la máquina donde se encuentre Prosody. DOMAIN indica el Virtualhost de Prosody donde se autentican los elementos que conforman Jitsi Meet, normalmente auth.DOMINIO_PRINCIPAL. USERNAME y PASSWORD son las credenciales para registrarse en Prosody, recordar que hay que crear el usuario como vimos anteriormente. Varios, o todos, los videobridge pueden usar el mismo USERNAME y PASSWORD, y la opción MUC_NICKNAME permitirá diferenciarlos posteriormente. Así que podemos crear un usuario por videobridge y usar el mismo nombre como nick, o crear un sólo usuario y que cada videobridge use un nick diferente. Esto último facilitaría la configuración de nuevos videobridge (no sería necesario crear un usuario en Prosody por cada uno). MUC_JIDS indica el nombre del canal (lospuentes) y el componente de MUC (internal.auth.EXAMPLE.NET) donde se comunicaran los videobridges con Jicofo, así que atención a que sea el mismo en Jicofo y todos los videobridge. La última opción importante en esta sección es AUTHORIZED_SOURCE_REGEXP, que indica de donde puede recibir órdenes en videobridge. Cuidado con esta opción, porque una expresión regular errónea no permitiría la creación de conferencias en el videobridge. Casi toda la documentación hasta ahora ponía como ejemplo algo tipo: focus@auth.EXAMPLE.NET./.* Esta sintáxis sólo es válida si se usan componentes XMPP. Ya no es correcta con el uso de MUCs, pese a no estar muy documentado (esto es todo lo que encontré al respecto), y deberemos usar la sintaxis: lospuentes@internal.auth.EXAMPLE.NET/focus.*$, donde lospuentes es el ya sabido nombre del canal, internal.auth.EXAMPLE.NET es el nombre del componente MUC y focus es el nick de Jicofo en XMPP.

Para terminar con la configuración del cliente XMPP del videobride, la opción DISABLE_CERTIFICATE_VALIDATION, como su nombre indica, permite desactivar la validación del certificado SSL que presenta Prosody. Como ya comenté, la instalación del paquete jitsi-meet-prosody, crear unos certificados autofirmados para el dominio auth.DOMINIO_PRINCIPAL. Si no queremos copiar dichos certificados en los videbridge, y su conexión al Prosody es local, podemos usar esta opción para ahorrarnos la tarea.

Con esto terminamos la configuración del videobridge. Para probarlo por completo recomiento una conferencia con al menos tres participantes. El motivo es que con 2 participantes el videobridge «no es realmente necesario», el vídeo irá entre los participantes directamente. Sólo la entrada de un tercer usuario hará que el videbridge se ponga a trabajar de verdad. Y es en ese momento, la entrada del tercero, cuando veremos si está todo OK. Si al entrar el tercer participante las imágenes de todos quedan en negro, hay algo mal configurado. Revisad el log del Videobridge (/var/log/jitsi/jvb.log) y de Jicofo (/var/log/jitsi/jicofo.log) en busca de problemas de comunicación entre ellos. En el del videobrige deberíamos ver algo como:

2020-05-20 12:33:34.980 INFO: [20] [hostname=localhost id=shard] MucClient$MucWrapper.join#751: Joined MUC: lospuentes@internal.auth.EXAMPLE.NET
# Seguido (si habilitamos las estadísticas) de estos:
2020-05-20 12:35:54.636 INFO: [19] AbstractHealthCheckService.run#171: Performed a successful health check

En el de Jicofo, a la entrada del Videobridge, veremos:

org.jitsi.jicofo.bridge.BridgeSelector.log() Added new videobridge: Bridge[jid=lospuentes@internal.auth.EXAMPLE.NET/JVB_NICK, relayId=null, region=null, stress=0.00]

En caso de no verse esta línea «Added new videobridge«, revisa que el nombre del canal sea igual en ambos (Jicofo y videobridge) y que el videobridge se está registrando («Joined MUC«) correctamente. Si todo va correctamente, ya tienes la base. En próximas entradas hablaré del front-end web (Jitsi Meet), Jibri y los famosos tokens.

$ exit

Una vez tenemos configurado el servidor XMPP, con o sin autenticación, veamos el siguiente componente a configurar: Jicofo. Encargado de repartir las conferencias entre los videobridges disponibles, podemos decir que, junto con Prosody, Jicofo es la pieza central de la arquitectura Jitsi Meet. Además ambas son bastante ligeras y pueden correr juntas, junto con nginx y Jitsi Meet (el cliente web), en una máquina con una CPU y poco más de 1GB de RAM.

Configuración de Jitsi Conference Focus(Jicofo)

Jicofo tiene dos ficheros principales de configuración. El primero, /etc/jitsi/jicofo/config, lleva las opciones que se pasan al demonio en su ejecución (JAVA_SYS_PROP y JICOFO_OPTS) y las de autenticación de Jicofo en Prosody. Son estas últimas las que normalmente tocaremos (o tocará el paquete Debian en su instalación). Se trata de:

JICOFO_HOST=localhost
JICOFO_HOSTNAME=EXAMPLE.NET
JICOFO_SECRET=SECRETO
JICOFO_PORT=5347
JICOFO_AUTH_DOMAIN=auth.EXAMPLE.NET
JICOFO_AUTH_USER=focus
JICOFO_AUTH_PASSWORD=CLAVE

JICOFO_HOST, yo hubiera usado otro nombre para esta variable, es el servidor XMPP al que se conectará Jicofo. «localhost» será el valor de esta variable si ejecutamos Prosody en la misma máquina que Jicofo. En otro caso será el nombre o IP del servidor Prosody y, salvo que uses en Prosody un certificado SSL válido universalmente, tendrás que copiar los certificados de Prosody para tu dominio (normalmente en /var/lib/prosody/EXAMPLE.NET.crt y auth.EXAMPLE.NET.crt) al directorio /usr/local/share/ca-certificates/ del servidor con Jicofo y ejecutar update-ca-certificates en él para que sea reconocido por Jicofo.

Jicofo se registra, a día de hoy, de dos maneras en el servidor XMPP:

1.- Como un usuario normal. Cuyos datos son JICOFO_AUTH_DOMAIN, el dominio donde se registran todos los componentes (auth.EXAMPLE.NET), JICOFO_AUTH_USER y JICOFO_AUTH_PASSWORD. Estos datos, así como la creación del usuario en Prosody, suelen cumplimentarse por la instalación del paquete Debian. Si lo haces manualmente, puedes comprobar que son correctos, o crearlos como se indica, en el directorio de usuarios de Prosody. Si decidieras cambiar el nombre de usuario, «focus» por defecto, ten en cuenta que es el administrador de algunos componentes en Prosody y tendrás que corregir esa configuración.

2.- Como un «componente», un servicio dentro del propio servidor XMPP. El nombre del servicio será focus.EXAMPLE.NET (no confundir con el usuario: focus.auth.EXAMPLE.NET). Los datos de este registro son JICOFO_HOSTNAME (al que añadirá focus. para el nombre del servicio) y JICOFO_SECRET. Que deberán de coincidir con la configuración en Prosody:

Component "focus.EXAMPLE.NET"
  component_secret = "SECRETO"

El segundo de los ficheros de configuración, /etc/jitsi/jicofo/sip-communicator.properties, indica el nombre «del canal» o sala donde se reunirán los diferentes componentes (videobridges y Jibris):

org.jitsi.jicofo.BRIDGE_MUC=lospuentes@internal.auth.EXAMPLE.NET
# OPCIONALES, sólo si se usan Jibris:
org.jitsi.jicofo.jibri.BREWERY=losgrabadores@internal.auth.EXAMPLE.NET
org.jitsi.jicofo.jibri.PENDING_TIMEOUT=90

internal.auth.EXAMPLE.NET es un componente MUC (Multi-User Chat) de Prosody que ya vimos. Cuando configuremos los videobridges y Jibris, deberemos indicar estos nombres de canales en su configuración, sólo así sabrá Jicofo de su existencia.

Una nota importante. Como podréis deducir de quién se registra dónde, es importante el orden en el que se arrancan (o reinician en caso de cambios de configuración) los servicios. El primero en arrancar debe ser Prosody, seguido de Jicofo y por último el resto de componentes. De no hacerlo así se pueden sufrir comportamientos extraños.

$ exit

Posiblemente uno de los motivos de mayor peso para instalar una instancia propia de Jitsi Meet es poder controlar/limitar quien accede a ella. Veremos en este artículo como requerir autenticación a los usuarios que se conectan usando LDAP para ello.

Autenticación de usuarios con LDAP (PAM, SQL, …)

Existen varias alternativas para la autenticación de usuarios con LDAP: mod_auth_ldap, mod_auth_ldap2 y el elegido por Jitsi en su paquetería: cyrus. Cyrus es una implementación del estándar SASL que abstrae el servicio de autenticación (LDAP en este caso) del consumidor del mismo (Prosody), por lo que en realidad usando SASL podríamos usar cualquier tipo de «backend» para validar usuarios (PAM, SQL,…). Los cambios necesarios en la configuración de nuestro VirtualHost principal (EXAMPLE.NET) serían:

Donde dice:
  authentication = "anonymous"

Dirá:
  authentication = "cyrus"
  cyrus_application_name = "xmpp"
  allow_unencrypted_plain_auth = true

Además añadiremos está línea en el bloque "modules_enabled":
  "auth_cyrus";

La opción cyrus_application_name indicará la configuración a usar por saslauthd para autenticar los usuarios. Mientras que la opción allow_unencrypted_plain_auth = true permite un mecanismo de autenticación inseguro (claves en claro) que sospecho es necesaria para dar soporte al cliente (javascript) de Jitsi Meet que no soporta otros mecanismos SASL como CRAM-MD5 o GSSAPI. Si configurasteis c2s_require_encryption = true, no debería ser un problema. En otro caso podrían viajar contraseñas en claro entre el servidor web y Prosody.

Lo siguiente será configurar saslauthd para prestar servicio a Prosody. Para ello instalaremos los siguientes paquetes (o sus correspondientes en distribuciones no Debian):

apt install sasl2-bin libsasl2-modules-ldap lua-cyrussasl

En el fichero de configuración de arranque de saslauthd (/etc/default/saslauthd) activaremos el arranque y configuraremos LDAP como «backend» para la autenticación:

START=yes
MECHANISMS="ldap"

Luego editaremos la configuración LDAP del saslauthd (/etc/saslauthd.conf). Por ejemplo para usar Autenticación Simple (conectar con el servidor LDAP usando las credenciales proporcionadas por el cliente):

ldap_servers: ldaps://IP_O_NOMBRE_SERVIDOR_LDAP/
ldap_search_base: ou=people,dc=EXAMPLE,dc=NET
ldap_filter: (uid=%u)
ldap_version: 3
ldap_auth_method: bind

Por último crearemos el fichero de configuración SASL para el servicio xmpp, el nombre de este fichero debe coincidir con el especificado en Prosody como cyrus_application_name. En este caso será /etc/sasl/xmpp.conf y su contenido será:

pwcheck_method: saslauthd
mech_list: PLAIN

Además debemos añadir al usuario prosody en el grupo sasl para que tenga acceso al socket de comunicación con el demonio saslauthd (en /run/saslauthd/):

# adduser prosody sasl

Después de editar todos estos ficheros será necesario reiniciar tanto Prosody como saslauthd:

# systemctl restart saslauthd
# systemctl restart prosody

Antes de seguir, os recomiendo que probéis al menos el funcionamiento de saslauthd para que en caso de problemas de autenticación podamos descartar esa parte. Un simple comando valdrá:

# testsaslauthd -u USUARIO -p CLAVE -f /var/run/saslauthd/mux

Sí, lo sé… contraseñas en línea de comando. No hay nada perfecto. Si pasamos la prueba, podemos seguir con la configuración.

Desde este momento, todos los usuarios tendrán que autenticarse para unirse a una conferencia. Pero es posible que también deseemos que usuarios anónimos se unan (a una sala creada), dejando la autenticación como requisito para crear una sala nueva y dar privilegios de moderador.

Dejar unirse, como invitados, a usuarios no autenticados (Secure Domain)

Tendremos hacer unos cambios en Jitsi Meet, Prosody y Jicofo para que los usuarios anónimos entren bajo un Virtualhost diferente en Prosody. Empezando por Prosody, añadiremos lo siguiente a nuestro fichero de configuración:

VirtualHost "invitados.EXAMPLE.NET"
  authentication = "anonymous"
  c2s_require_encryption = false

Como vemos, en este Virtualhost no hay autenticación. Luego habrá que informar a Jitsi Meet de este dominio para los usuarios que no se autentican. En su fichero de configuración (/etc/jitsi/meet/EXAMPLE.NET-config.js):

# Descomentar la siguiente línea:
anonymousdomain: 'invitados.EXAMPLE.NET',

Por último habrá que decirte a Jicofo (encargado de la creación de salas) que sólo los usuarios de nuestro dominio con autenticación pueden crear salas/ser moderadores. En /etc/jitsi/jicofo/sip-communicator.properties:

# Añadir la línea
org.jitsi.jicofo.auth.URL=XMPP:EXAMPLE.NET

No olvidéis reiniciar Prosody y Jicofo después de todos estos cambios. En próximas entregas hablaré de la configuración del resto de componentes y de la autenticación con tokens, que permite una integración con aplicaciones de terceros como Moodle.
$ exit

Una vez conocidos los componentes, veremos ahora la configuración de los mismos. Mi objetivo no es tanto dar unas instrucciones paso a paso, sino explicar que partes de la configuración sirven para qué propósito y qué opciones tenemos en función de las características que deseemos en nuestra instalación.

Prosody (autenticación de usuarios y componentes Jitsi)

Los paquetes Debian que proporciona el proyecto Jitsi crean un fichero de configuración con todo lo relacionado con Jitsi. Esto permite evitar cambios en el fichero principal y aislar la configuración propia de Jitsi de otra configuración que ya pudiéramos tener en Prosody. Entiendo, por tanto, que tendremos un fichero /etc/prosody/conf.avail/EXAMPLE.NET.cfg.lua y que habrá un enlace simbólico a este fichero desde /etc/prosody/conf.d/EXAMPLE.NET.cfg.lua. Donde EXAMPLE.NET será el dominio de nuestra instalación (p.e. meet.inittab.org).

La (falta de) autenticación de usuarios

Como ya hemos comentado, Prosody es el encargado de la autenticación de usuarios. Ésta se configura en un VirtualHost que llevará por nombre el mismo que nuestro dominio. El siguiente ejemplo permite la entrada de cualquier usuario en nuestro Jitsi Meet, es decir no realiza autenticación de usuarios:

VirtualHost "EXAMPLE.NET"
  authentication = "anonymous"
  ssl = {
    key = "/etc/prosody/certs/EXAMPLE.NET.key";
    certificate = "/etc/prosody/certs/EXAMPLE.NET.crt";
  }
  speakerstats_component = "speakerstats.EXAMPLE.NET"
  conference_duration_component = "conferenceduration.EXAMPLE.NET"
  modules_enabled = {
    "bosh";
    "pubsub";
    "ping";
    "speakerstats";
    "turncredentials";
    "conference_duration";
  }
  c2s_require_encryption = false

Antes de ver las opciones de autenticación, quería hacer dos puntualizaciones sobre la configuración creada por el paquete «jitsi-meet-prosody«. Éste genera una clave y certificado autofirmado (los que están en /etc/prosody/certs) y deshabilita la obligación de usar TLS en las conexiones de clientes (c2s_require_encryption = false). Aunque pueda parecer inseguro, la realidad es que nuestras credenciales ya viajan seguras por la conexión HTTPS con el servidor web. Si quisiéramos cubrir el tramo entre nuestro servidor web y Prosody, podríamos configurar un certificado válido, por ejemplo de Let’s Encrypt y activar (true) la opción c2s_require_encryption:

  ssl = {
    key = "/etc/letsencrypt/live/EXAMPLE.NET/fullchain.pem";
    certificate = "/etc/letsencrypt/live/EXAMPLE.NET/privkey.pem";
  }
  c2s_require_encryption = true

En posteriores artículos veremos como limitar el acceso a nuestra instancia de Jitsi Meet autenticando usuarios.

El siguiente bloque define un componente en Prosody para la creación de las salas/conferencias (muc: Multi User Conference) que usará Jitsi Meet:

Component "conference.EXAMPLE.NET" "muc"
  storage = "memory"
  modules_enabled = {
    "muc_meeting_id";
    "muc_domain_mapper";
  }
  admins = { "focus@auth.EXAMPLE.NET" }
  muc_room_locking = false
  muc_room_default_public_jids = true

En él vemos que focus@auth.EXAMPLE.NET, el usuario que usa Jicofo, será el administrador de las salas. Este bloque será modificado cuando usemos autenticación con «tokens» para gestionar los moderadores y participantes en las salas.

Otro bloque similar es el que usan los diferentes componentes de Jitsi Meet para comunicarse entre ellos (informar de que videobridges y jibris están disponibles y cual es su carga para que Jicofo decida en qué videobridge crear nuevas salas o qué Jibri se encargará de una petición nueva de grabación):

Component "internal.auth.EXAMPLE.NET" "muc"
  storage = "memory"
  modules_enabled = {
    "ping";
  }
  admins = { "focus@auth.EXAMPLE.NET" }
  muc_room_locking = false
  muc_room_default_public_jids = true

También vemos que el usuario de Jicofo es el administrador de este muc.
Los usuarios de los componentes de Jitsi Meet no se autentican en el dominio principal (EXAMPLE.NET) sino en uno propio (auth.EXAMPLE.NET). Esto permite que podamos cambiar la configuración de autenticación para los asistentes, en el dominio principal, sin afectar a la autenticación de los componentes, que se hace en el dominio auth.EXAMPLE.NET:

VirtualHost "auth.EXAMPLE.NET"
  ssl = {
    key = "/etc/prosody/certs/auth.EXAMPLE.NET.key";
    certificate = "/etc/prosody/certs/auth.EXAMPLE.NET.crt";
  }
  authentication = "internal_plain"

Una vez más vemos que los certificados usados para este VirtualHost son autofirmados y creados por la instalación del paquete «jitsi-meet-prosody«.
Si bien este dominio no tiene por qué existir en el DNS, y por tanto no disponer de un certificado válido, si será necesaria la propagación del certificado (en los directorios /usr/local/share/ca-certificates) a los servidores adicionales a éste que ejecuten videobridges, jibris o jigasi si queremos que verifiquen la identidad del servidor Prosody cuando se autentiquen en él. De otra manera tendremos que usar una opción en ellos para deshabilitar la comprobación de este certificado (TODO: aquí vendrá el enlace a esa opción cuando esté su artículo).

La autenticación en este VirtualHost, authentication = "internal_plain", se realiza de forma local por Prosody. Por este motivo los usuarios de los componentes deben ser dados de alta con la herramienta prosodyctl. Para los componentes instalados en el mismo servidor que Prosody, esto se hace automáticamente por la paquetería de Debian.
Pero si instalamos componentes en otros servidores deberemos hacerlo nosotros manualmente. Veamos como.

Prosody mantiene un directorio por cada VirtualHost que tiene autenticación "internal_plain", en nuestro caso (auth.EXAMPLE.NET) podemos verlo así:

# ls -s /var/lib/prosody/auth%2eEXAMPLE%2eNET/accounts/ -l
total 16
-rw-r----- 1 prosody prosody 40 Apr 27 18:37 focus.dat
-rw-r----- 1 prosody prosody 34 Apr 27 18:37 jvb.dat
-rw-r----- 1 prosody prosody 40 Apr 27 18:38 prometheus.dat

En el nombre del directorio (y en los ficheros que contenga) se codifican, en código porciento, los caracteres especiales como puntos o guiones. Por eso el nombre «feo» del directorio. Dentro de él vemos un fichero con cada usuario registrado en este VirtualHost. Para dar de alta un usuario, para un componente nuevo, usaremos el siguiente comando:

# prosodyctl register USUARIO auth.EXAMPLE.NET CLAVE

Queda alguna configuración más que comentar, para usuarios invitados cuando usemos autenticación de participantes, o para la autenticación especial de Jibris, pero la veremos más adelante.

Con este artículo espero que se entienda, más o menos, el papel de Prosody uniendo el resto de piezas y las posibilidades de «fortificarlo» más de querer ser extrictos con la seguridad. En el próximos artículos veremos la autenticación de usuarios mediante LDAP.

Aprovecho para recordaros que en el Playbook de Ansible de la UDIMA para Jitsi Meet todas las tareas de instalación y configuración están automatizadas y casi podríais ahorraros leer estos peñazos que escribo
$ exit

Últimamente parece que las videoconferencias se han puesto de moda, como el papel higiénico. Y si bien hay muchas alternativas, la inmensa mayoría podrían no respetar tu privacidad y algunas tienen un historial de problemas de seguridad que asusta.

Por suerte hay una alternativa plenamente funcional y libre: Jitsi Meet.

No necesitas nada para usar Jitsi Meet*

* Salvo un navegador actual o su aplicación móvil/de escritorio

Si no tienes medios (servidor, ancho de banda, ganas de complicarte la vida), puedes usar su servicio público que funciona estupendamente. Es muy sencillo, simplemente dale un nombre a tu conferencia y pasa la URL resultante (por ejemplo: https://meet.jit.si/UnPingüino) a todos los participantes que quieras invitar.

Evita, eso sí, nombres fáciles o comunes («pepe», «prueba», «test») para la conferencia o puede que entre más gente de la que esperas, ya que las conferencias en el servidor público no limitan quien entra en ellas.

Pero si lo que quieres es no depender de terceros, controlar quien puede entrar en tus conferencias, o proteger tu privacidad, puedes instalar Jitsi Meet en un servidor propio. Y a eso es a lo que hemos venido.

Las piezas del puzzle

Nada es perfecto, y si en algo peca(ba) Jitsi Meet es en su documentación. Tal era la situación que salió un proyecto paralelo sólo para documentarlo: EasyJitsi
Os recomiendo echarle un ojo para tener más información.

Lo primero que debemos hacer antes de montar Jitsi Meet es entender que piezas lo componen y para que sirven cada una de ellas.

Prosody

Aunque no es parte del proyecto Jitsi, Prosody es una de las piezas más importantes de esta arquitectura. Se trata de un servidor XMPP. O en términos más claros; un servidor de mensajería instantánea.
XMPP es un grupo de protocolos que definen y permiten todas las características esperables en un servicio de mensajería: autenticación de usuarios, conversaciones con varios participantes (rooms/canales), envío de ficheros, … Es el protocolo sobre el que se construye Google Talk / Hangouts / Chat, aunque Google decidiera no usar el estándar para interoperar con otras implementaciones XMPP. Pero tranquilos, con más de 1.500 millones de usuarios de Gmail pronto tampoco tendrá que intercambiar correo con nadie que no sean ellos y podrá inventarse las extensiones que lo mejoren y liberen de viejos estándares. ¡Hala!, ya me despaché. Sigamos…

Prosody será el encargado de autenticar al resto de componentes de Jitsi Meet y, en caso de quererlo, a los usuarios que se conecten a nuestro servicio de Meet. Además gestiona la comunicación entre componentes y usuarios. Por ejemplo permitiendo que Jicofo sepa de la existencia de videobridges y Jibris en servicio.

Jicofo (Jitsi Conferenre Focus)

Es el encargado de dirigir la orquesta. Lleva el control de los recursos, decide en que videobridge se hospeda una conferencia (en función de la carga de los disponibles) o que Jibri será el que transmitirá (a Youtube, por ejemplo) o grabará la sala que lo así solicite.

Videobride

Es el encargado de recibir y hacer llegar los flujos de audio y vídeo a los participantes de una conferencia. Aunque en una conferencia de dos personas es posible que los vídeos vayan de un a otro participante directamente, sin mediar el videobridge, en cuanto los participantes son tres o más, todos envían su señal de vídeo al videobridge, que la repite al resto de participantes.

Este funcionamiento es además característica fundamental de Jitsi Meet. Los videobridge no mezclan vídeo, según llega de un cliente sale al resto. Eso se traduce en menos latencia, al no perder tiempo procesando vídeo, a costa de un uso alto (con muchos participantes) de ancho de banda. Por ejemplo, y dependiendo de la calidad que usemos, si tenemos 10 participantes, con la cámara abierta, enviando vídeo a 3Mbps, además de estar recibiendo 30Mbps estaría sacando unos 300Mbps de tráfico.

Jibri (Jitsi BRoadcasting Infrastructure)

Permite grabar, en disco o nube, o retransmitir a Youtube (por ahora) una sesión. Está compuesto por varios componentes: el propio Jibri que se conecta con prosody para recibir las órdenes de grabación de Jicofo, un navegador Chrome que se conecta como un usuario más a la sesión que grabará, y ffmpeg que se encarga de codificar el vídeo final.

Una característica a tener en cuenta de Jibri es que una sola instancia es capaz de grabar una sola sesión. Así que si quieres grabar más de una simultáneamente necesitarás tener más de un servidor/docker con Jibri.

Un servidor web y Jitsi Meet

Jitsi Meet, propiamente dicho, sería la parte frontal de todo el invento. Es una aplicación en Javascript que estará alojada en un servidor web. En el momento que escribo esto, nginx el servidor mejor soportado por Jitsi Meet para hacer este trabajo.

Otros componentes

Opcionalmente, en las últimas versiones, se puede instalar/configurar un servidor TURN/STUN para facilitar las comunicaciones de clientes detrás de NAT. De no hacerlo se pueden usar servidores públicos, en principio sin grandes compromisos (a mi entender) salvo la dependencia en la disponibilidad del servicio.

Jigasi es la última pieza del puzzle. Este componente permite integrar Jitsi Meet con una centralita de Voz IP. Ya sea para realizar llamadas desde una conferencia en curso (Meet ordena a Jigasi llamar) o para que participantes puedan unirse a una conferencia a través de una llamada telefónica (la centralita de Voz IP dirige las llamadas a Jigasi que las hace llegar a Jitsi Meet).

En la próxima entrega entraré en más detalle sobre la configuración de cada uno de ellos. Si os corre prisa echarlo a andar podéis usar su instalación docker, pegaros con sus paquetes, o probar el «playbook» de Ansible que la Universidad a Distancia de Madrid (UDIMA) ha publicado en su Github. Y sí, puede que yo tenga algo que ver con esto último

Realicé una instalación desde cero de Debian 10 Buster en una de mis máquinas y aún no había instalado el DNI (Documento nacional de Identidad) electrónico para hacer gestiones con las administraciones públicas españolas, así que me he puesto hoy a ello.
Ha sido relativamente sencillo.

1.- Paquetes necesarios para el lector y gestión de la entrada del PIN (tengo instalado KDE Plasma, y ya tenía pinentry-qt instalado)

sudo apt-get install pcscd pcsc-tools opensc

2.- Comprobar que el lector funciona: pinchar el lector USB con el DNI metido, y escribir

pcsc_scan

Esta es la salida que me proporciona:

$ pcsc_scan

Using reader plug'n play mechanism
Scanning present readers...
0: C3PO LTC31 v2 00 00
 
Mon Jun 24 12:35:44 2019
 Reader 0: C3PO LTC31 v2 00 00
  Event number: 0
  Card state: Card inserted, Shared Mode, 
  ATR: 3B 7F 96 00 00 00 6A 44 4E 49 65 10 01 01 55 04 21 03 90 00

ATR: 3B 7F 96 00 00 00 6A 44 4E 49 65 10 01 01 55 04 21 03 90 00
+ TS = 3B --> Direct Convention
+ T0 = 7F, Y(1): 0111, K: 15 (historical bytes)
  TA(1) = 96 --> Fi=512, Di=32, 16 cycles/ETU
    250000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = 00 --> Extra guard time: 0
+ Historical bytes: 00 6A 44 4E 49 65 10 01 01 55 04 21 03 90 00
  Category indicator byte: 00 (compact TLV data object)
    Tag: 6, len: A (pre-issuing data)
      Data: 44 4E 49 65 10 01 01 55 04 21
    Mandatory status indicator (3 last bytes)
      LCS (life card cycle): 03 (Initialisation state)
      SW: 9000 (Normal processing.)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 7F 96 00 00 00 6A 44 4E 49 65 10 01 01 55 04 21 03 90 00
3B 7F 96 00 00 00 6A 44 4E 49 65 10 01 01 55 04 .. 03 90 00
        DNIE Spain (eID)
        http://www.dnielectronico.es/PortalDNIe/

Salgo con Ctrl+C y desconecto el lector de DNI.

3.- Instalar el paquete de DNI electrónico, para Debian: vamos a usar los de Debian Stretch, porque aún no hay paquetes para Buster disponibles.

$ wget https://www.dnielectronico.es/descargas/distribuciones_linux/libpkcs11-dnie_1.5.0_amd64.deb

Compruebo que la suma de comprobación es correcta:

$ md5sum libpkcs11-dnie_1.5.0_amd64.deb 
526cb7761f312f2beb97344cc74f3dcc  libpkcs11-dnie_1.5.0_amd64.deb

Instalo

$ sudo dpkg -i libpkcs11-dnie_1.5.0_amd64.deb

Aquí se instala el paquete pero luego da un error porque intenta abrir Firefox como root, cosa que el sistema no deja.

He mirado los contenidos del paquete y realmente lo que se hace es llamar a un script en Perl que es el que lanza Firefox, así que lo llamo como usuario normal:

$ /usr/share/libpkcs11-dnietif/launch.pl

Se abre Firefox y hay que seguir las instrucciones de la página web que aparece (file:///usr/share/libpkcs11-dnietif/launch.html) para cargar el módulo de seguridad de DNIe, y la autoridad de certificación FNMT (yo he cargado solamente el módulo de seguridad, porque creo que la FNMT ya la incorpora Firefox). Si veo que algo falla volveré aquí, terminaré las instrucciones, y actualizaré este artículo.

Una vez hecho esto, cierro Firefox, lo vuelvo a abrir, entro en una web que me pida el DNIelectrónico, y compruebo que funciona.

Realicé una instalación desde cero de Debian 9 Stretch en uno de mis portátiles y aún no había instalado el DNI (Documento nacional de Identidad) electrónico para hacer gestiones con las administraciones públicas españolas, así que me he puesto hoy a ello.
Ha sido relativamente sencillo.

1.- Paquetes necesarios para el lector y gestión de la entrada del PIN

sudo apt-get install pcscd pcsc-tools pinentry-qt pinentry-qt4 opensc opensc-pkcs11

Nota: hay varios paquetes pinentry disponibles para los distintos escritorios/gestores de ventana, yo como uso Plasma de KDE, pues uso los basados en Qt.

2.- Comprobar que el lector funciona: pinchar el lector USB con el DNI metido, y escribir

pcsc_scan

Esta es la salida que me proporciona:

$ pcsc_scan
PC/SC device scanner
V 1.4.27 (c) 2001-2011, Ludovic Rousseau 
Compiled with PC/SC lite version: 1.8.17
Using reader plug'n play mechanism                                                           
Scanning present readers...                                                                  
0: C3PO LTC31 v2 00 00                                                                       
                                                                                             
Thu May 11 19:04:04 2017                                                                     
Reader 0: C3PO LTC31 v2 00 00                                                                
  Card state: Card inserted,                                                                 
  ATR: 3B 7F 38 00 00 00 6A 44 4E 49 65 20 02 4C 34 01 13 03 90 00                           
                                                                                             
ATR: 3B 7F 38 00 00 00 6A 44 4E 49 65 20 02 4C 34 01 13 03 90 00                             
+ TS = 3B --> Direct Convention                                                              
+ T0 = 7F, Y(1): 0111, K: 15 (historical bytes)                                              
  TA(1) = 38 --> Fi=744, Di=12, 62 cycles/ETU                                                
    64516 bits/s at 4 MHz, fMax for Fi = 8 MHz => 129032 bits/s                              
  TB(1) = 00 --> VPP is not electrically connected                                           
  TC(1) = 00 --> Extra guard time: 0                                                         
+ Historical bytes: 00 6A 44 4E 49 65 20 02 4C 34 01 13 03 90 00                             
  Category indicator byte: 00 (compact TLV data object)                                      
    Tag: 6, len: A (pre-issuing data)
      Data: 44 4E 49 65 20 02 4C 34 01 13
    Mandatory status indicator (3 last bytes)
      LCS (life card cycle): 03 (Initialisation state)
      SW: 9000 (Normal processing.)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B 7F 38 00 00 00 6A 44 4E 49 65 20 02 4C 34 01 13 03 90 00
3B 7F 38 00 00 00 6A 44 4E 49 65 [1,2]0 02 4C 34 01 13 03 90 00
        DNI electronico (Spanish electronic ID card)
        http://www.dnielectronico.es

Salgo con Ctrl+C y desconecto el lector de DNI.

3.- Instalar los paquetes de DNI electrónico, para Debian: vamos a usar los de Debian Jessie, porque aún no hay paquetes para Stretch disponibles.

wget https://www.dnielectronico.es/descargas/distribuciones_linux/Debian-64bits/Debian_%208%20Jessie_libpkcs11-dnie_1.4.0_amd64.deb

$ sudo dpkg -i ./Debian_\ 8\ Jessie_libpkcs11-dnie_1.4.0_amd64.deb

Se abre Firefox y hay que seguir las instrucciones de la página web que aparece, para cargar el módulo de seguridad de DNIe, y la autoridad de certificación FNMT.

Una vez hecho esto, cierro firefox. En el terminal indica que la instalación del paquete terminó con errores pero no tiene importancia. Vuelvo a conectar el lector del DNI con el DNI metido. Abro Firefox y compruebo que funciona.

Si tienes trato conmigo, me habrás oído hablar algo de Jabber/XMPP.

¿Te vienes a dar un paseo por la mensajería instantánea libre?

Jabber/XMPP

Es un protocolo de comunicación, como el correo electrónico o el FTP.
Antes se llamaba Jabber, ahora se llama XMPP
Permite la mensajería instantánea entre dispositivos usando internet (ordenadores, móviles, otros aparatos).
Permite charlar persona a persona y también en grupo.

El estándar es abierto y funciona con un servidor donde se crean las cuentas, y programas clientes (para ordenador o móvil) que sirven para enviar/recibir los mensajes. Te puedes comunicar con personas que tengan cuenta en un servidor XMPP distinto al tuyo (como en el caso del correo, tu servidor le pasará el mensaje al servidor del destinatario, que lo entregará).

Se puede usar con software libre (y gratuito) tanto en el lado del servidor como en los programas clientes, y permite el uso de cifrado punto a punto, para que ni los servidores ni los “mirones” vean el contenido de los mensajes.

Buena pinta ¿eh?

Registrarse

Mi cuenta es larjona@jabber.org

Me hice la cuenta hace algún tiempo y ese servidor está algo saturado, así que a la familia y amigos ahora les recomiendo otros, por ejemplo mijabber.es. Si quieres buscar otro diferente, tienes una lista con muchos servidores aquí: https://xmpp.net/directory.php

Para registrarse, puedes ir con un navegador web a la página del servidor y crear la cuenta, o puedes usar algún programa cliente que permita el registro automático (esto último no lo he probado).

Elige tu servidor, y elige un apodo que esté libre. Y ya está (bueno, algún servidor puede que te pida un correo electrónico para poder recuperar tu contraseña si se te olvida, o algún otro dato personal. Tú decides).

Programas clientes

Hay clientes para muchos sistemas operativos distintos.

También, muchos servidores, ofrecen un cliente web, para no tener que instalar nada. Por ejemplo: https://mijabber.es/jappix/

En GNU/Linux, Android, e iOS, usa el repositorio oficial para instalar el que quieras (puedes tener varios, si quieres). En Windows/OS X, visita las páginas web de los proyectos para descargar los ejecutables.

Yo uso Xabber en mi móvil (Android 2.x), y Conversations esporádicamente en mi tableta (Android 4.x). También he probado Tigase y Yaxim. Todos disponibles en F-Droid.

En el ordenador (con Debian), he probado varios: Psi, Psi+, Jitsi. Tengo pendiente probar Gajim.

En Windows sólo he probado Jitsi, pero conozco gente que usa Gajim o Pidgin.

Algunos clientes tienen estructura modular, y hay que instalar complementos para poder usar el cifrado, o la videollamada, u otras funciones avanzadas.

Chatear, y grupos

Una vez hemos instalado el cliente, iniciamos sesión con nuestra cuenta identificativa o JID, por ejemplo pepita.pulgarcita@mijabber.es y la contraseña.
Podemos añadir contactos (indicando sus JID), y se enviará una solicitud de autorización al contacto. También podemos entrar en grupos, (según el cliente que uses, verás que los llaman “grupos”, “salas”, “conferencias”, o MUC (“multi user chat”)). Por ejemplo en la sala redeslibres@salas.mijabber.es (haz clic y echarás un ojo ahora mismo desde el navegador) o crear tú uno en un servidor que permita la creación de grupos (salas.mijabber.es es uno de ellos, simplemente creas un nuevo nombre como “familiadepepitapulgarcita@salas.mijabber.es” y ya).

Cuando nos unimos a una sala de charla, podemos usar un apodo diferente, invitar a gente, proteger la sala con contraseña, y otras cosas.

En la conversación uno a uno, podemos activar el cifrado OTR, llamada de voz, o videollamada, si nuestro cliente y el de nuestro interlocutor lo soportan.

Envío de archivos

El estándar XMPP permite enviar/recibir archivos de dos maneras diferentes, y cada servidor y programa cliente decide de cuál manera lo hacen. Esto es un poco problemático, porque tú con tu cliente y tu cuenta en tu servidor podrás enviar archivos y quizá el servidor del receptor o el cliente no admite ese método… es cuestión de ponerse de acuerdo.

En general, los clientes de escritorio permiten el envío de archivos, y algunos clientes móviles (Conversations) también.

El método que funciona en todo caso es subir el archivo a algún sitio y proporcionar a tu interlocutor o interlocutores la URL Pero no te des por vencido/a, haz pruebas y actualiza frecuentemente tus clientes porque esta situación está evolucionando para bien.

Derivados

Existen aplicaciones que utilizan XMPP pero no son del todo compatibles, porque han adaptado el sistema a sus necesidades.

Kontalk

Un ejemplo de derivado libre es Kontalk (a partir de la versión 3, versiones anteriores no usaban XMPP).

El servidor es XMPP, pero el programa crea la cuenta de usuario aplicando una función “hash” al número de teléfono del usuario, con lo que se obtiene un JID algo complicado, tipo aedc28ed561209dfa98dee@beta.kontalk.net, y ése es el JID que tienes que decir a tus contactos que usan XMPP estándar para que te agreguen… Porque además el cliente de Kontalk no permite agregar contactos manualmente (aún), sólo usando la lista de números de teléfono. Además, no es posible hoy por hoy iniciar sesión con tu JID de Kontalk usando otro cliente XMPP, porque Kontalk usa cifrado GPG con un par de claves, en lugar de contraseña. Así que los usuarios de Kontalk, en la práctica, sólo pueden usar la aplicación de Kontalk para comunicar.

Kontalk, por ahora, no permite grupos, aunque se está trabajando en ello (así como en mejorar el sistema para que se puedan usar otros clientes XMPP para comunicarse).

El código del servidor y del cliente es libre, por lo que es posible, por un lado, instalar más servidores para crear una red federada como la XMPP estándar, y por otro, como sabemos, se puede adaptar y mejorar todo el sistema (de hecho, el desarrollo es comunitario, con 2 personas dirigiendo el proyecto y una comunidad bastante activa).

Un ejemplo de derivado no libre es Whatsapp.

Han adaptado el servidor, cliente y protocolo para que se registren las cuentas automáticamente mediante el número de teléfono (de forma similar a como hemos explicado con Kontalk), y al no estar el código fuente disponible, es difícil saber cómo lo han hecho, y si han hecho más cosas. Han eliminado prácticamente cualquier posibilidad de control por parte del usuario: el usuario no puede saber su JID, tampoco puede especificar otro servidor para usar, y aunque se averiguara el JID, por acuerdo de términos de servicio, no puede usar otra aplicación distinta a la “oficial” para conectarse. Así, la empresa proveedora se ha reservado para sí todo el control. Todas las cuentas están en el mismo servidor, y usan el mismo cliente, y el usuario no puede cambiar nada; se asegura entonces el funcionamiento del envío de archivos (aunque éste se limita a sólo archivos de determinados tipos) y se asegura que todas las comunicaciones pasan por el servidor de Whatsapp, lo que permite controlar la comunicación, pero también perjudica a todos los usuarios si hay un problema en ese servidor.

En conclusión, la empresa usa XMPP para aprovechar sus ventajas en exclusiva, sin conceder al usuario esas ventajas que XMPP podría ofrecerle.

GTalk

GTalk era el cliente de mensajería instantánea de Google. Funcionaba usando el estándar XMPP, pero Google no implementó ciertos estándares de seguridad que exigen la mayoría de los servidores XMPP actuales. Como GTalk no era software libre, tampoco era posible arreglar esta situación por parte de la comunidad.

Cuando Google lanzó su nuevo sistema de mensajería y videollamadas, Hangouts (abandonando definitivamente GTalk), seguía sin ser libre, y además resultó incompatible con XMPP. Así, todas las personas que usaban XMPP estándar, dejaron de ver conectados a sus amigos que usaban GTalk/Hangouts, y viceversa. Google no informó a los usuarios de GTalk de que perderían la conectividad con sus contactos XMPP en otros servidores, al actualizar a Hangouts. Desde mi punto de vista, sólo eso es razón para dejar de usarlo y volver al XMPP estándar creando una cuenta en cualquier (otro) servidor…

Los usuarios de Hangouts tienen además el problema de la centralización del servidor, como hemos comentado anteriormente con Whatsapp. Si su servidor tiene problemas, no podrán usar ese sistema (no hay otro servidor de Hangouts donde crearse cuenta).

Conclusiones

Cuando nos dicen que determinada empresa/aplicación de mensajería ofrece mejor experiencia de usuario, es interesante pensar cómo lo consigue, o a costa de qué. Desde mi punto de vista, centralizar la comunicación haciendo que todos pasemos por un mismo servidor es hacer “trampa” (y además, tiene implicaciones muy importantes acerca de la privacidad de las comunicaciones, por ejemplo).

Llevo un tiempo usando XMPP, y veo que las aplicaciones de cliente y servidor están en continua evolución, resolviendo retos nada triviales (envío de archivos, videollamada, compatibilidad móvil/PC, comunicación síncrona y asíncrona…), sin renunciar a la interoperatividad y la federación (elementos claves de la supervivencia de una red que quiera ser una verdadera red) y a poner el control en manos de los usuarios y sus comunidades (elementos claves para que podamos comunicarnos con libertad).

Si piensas que el ecosistema XMPP se mueve despacio, y necesitaría un buen empujón para alcanzar la usabilidad y el nº de usuarios de los otros, ¿a qué esperas para colaborar? Úsalo, estúdialo, mejóralo, difúndelo. Es software libre, ¡tienes todo el derecho a ello!

Comentarios

Puedes comentar sobre este artículo en este hilo de pump.io.

Y también, usando XMPP, en la sala redeslibres@salas.mijabber.es

Un libro que me encantó es «Homeland» de Cory Doctorow, trata sobre un grupo de hackers que se ven envueltos en situaciones que los deja expuestos a uno de los gobiernos y empresas más poderosas que existen y deben hacer algo aún así los haga correr peligros. Una historia de ficción sobre gente como Aaron Swartz.

Pero lo mejor del libro, es que precisamente cierra con dos cartas, una por Jacob Appelbaum, uno de los primeros mimbros de Wikileaks y desarrollador del proyecto Tor; y otra por Aaron Swartz. La carta de Aaron la traduje y publico a continuación, espero les sirva de inspiración para que sigan en sus luchas aún cuando a veces parezca que quién da la batalla del otro lado es muy grande e invencible:

Hola, soy Aaron. Se me ha dado este pequeño espacio aquí al final del libro porque soy un humano de carne y hueso, y cómo tal, puedo decirte algo que no creerías si viniese de la boca de cualquiera de esos carácteres ficticios:

Esto es real.

Claro, no hay alguien llamado Marcus o Ange realmente, al menos no que yo conozca, pero sí sé de gente real justo como ellos. Si quieres, puedes ir a San Francisco y conocerlos. Y mientras estás allí, puedes jugar D&D con John Gilmore o construir un cohete en Noisebridge o trabajar con algunos hippies en un proyecto de arte para Burning Man.

Y si algo de las cosas más relacionadas con conspiraciones en el libro te parecen demasiado alocadas para ser verdad, bueno, simplemente googlea Blackwater, Xe o BlueCoat. (Yo mismo tengo una solicitud FOIA pendiente para saber más de "software para manejo de persona", pero los federales dicen que les va a tomar tres años más redactar todos los documentos relevantes.)

Ahora, yo espero que te hayas divertido quedándote despierto toda la noche leyendo acerca de estas cosas, pero la parte que viene es importante así que presta atención: lo que está pasando ahora no es algún reality show de televisión donde simplemente puedes sentarte en casa y ver.

Esta es tu vida, este es tú país -- y se quieres mantenerlo seguro, debes involucrarte.

Sé que es fácil sentirse sin poder, como si no hubiese algo que puedas hacer para que baje la marcha o detener "el sistema." Como si todos los hilos son movidos por fuerzas oscuras y poderosas lejanas a tu control. Yo me siento de esa forma también, a veces. Pero simplemente no es verdad.

Hace menos de un año, un amigo me llamó para decirme sobre un proyecto de ley oscuro del cuál había escuchado llamado Acta para Combatir la Vulneración En Línea y La Falsificación o COICA (En Inglés es: Combatting Online Infringement and Counterfeitting Act, de allí la abreviación COICA). Mientras leía el proyecto empecé a preocuparme más y más: bajo estas provisiones, el gobierno podría censurar sitios web que no le gusten sin algo como un juicio. Sería la primera vez que el gobierno de los EEUU se le darían poderes para censurar el acceso a la red.

El proyecto había sido introducido hace un día o dos, pero ya tenía un par de docenas de senadores apoyándola. Y, a pesar de nunca haber un debate ya estaba siendo programada para ser votada en sólo un par de días. Nadie había reportado al respecto y ése era justamente el punto: ellos querían apurar esta cosa para que pasara antes que alguien se diese cuenta.

Afortunadamente, mi amigo se dió cuenta. Nos quedamos despiertos todo el fin de semana y lanzamos un sitio web explicando qué decía el proyecto de ley, con una petición que podías firmar en rechazo al proyecto que te daría números de teléfonos para llamar a tus representantes en el senado. Le dijimos al respecto a algunos amigos y ellos le dijeron a algunos de sus amigos y en cuestión de un par de días teníamos más de 200 mil personas en nuestra petición. Fue increíble.

Bueno, la gente promoviendo esta ley no paró. Ellos gastaron literalmente decenas de millones de dólares haciendo lobby para éste proyecto de ley. La cabeza de cada compañía de medios grandes voló a Washington, D.C. y allí se reunieron con el jefe de personal del presidente y amablemente le recordaron de los millones de dólares que le habían donado a la campaña del presidente y le explicaron cómo lo que ellos querían -- la única cosa que querían -- era que esta ley se aprobara.

Pero la presión pública siguió creciendo. Para intentar sacar a la gente del camino ellos intentaron cambiando el nombre de la ley -- llamándola PIPA y SOPA, incluso llamándola E-PARASITES Act -- pero no importó cómo la llamaron, más y más personas se siguieron diciéndole a sus amigos sobre la ley y consiguiendo más y más personas que se opusieran. Pronto, las firmas en nuestra petición iba en millones.

Logramos detenerlos por más de un año con diferentes tácticas, pero se dieron cuenta que si esperaban más quizás nunca lograrían tener un chance de pasar esta ley. Así que programaron un voto apenas volviesen de la pausa de invierno.

Pero mientras los miembros del congreso estaban fuera en la pausa de invierno, manteniendo reuniones públicas y en las salas de sus pueblos en casa, la gente empezó a visitarlos. En todo el país, miembros del congreso empezaron a ser cuestionados por sus electores acerca de su apoyo a esa sucia ley de censura del internet. Y los miembros del congreso empezaron a asustarse -- algunos llegando tan lejos como responderles atacandome.

Pero esto ya no se trataba de mi -- nunca se trató de mi. Desde el principio fue sobre ciudadanos tomando las cosas en sus propias manos: haciendo vídeos en YouTube y escribiendo canciones oponiéndose a la ley, haciendo gráficos mostrando cuánto dinero los promotores de la ley habían recibido de las industrias promoviéndola, y organizando boycotts poniéndo presión en las compañías que habían promovido la ley.

Y funcionó -- tomó la ley desde un punto político sin problema alguno que se suponía debía pasar unánimamente a una posición más parecida a tener un balón tóxico que nadie quería tocar. ¡Incluso los promotores de la ley empezaron a sacar declaraciones oponiéndose a la ley! Oh sí, esos dueños de medios estaban molestos...

Así no es como se supone que el sistema deba funcionar. ¡Un montón de chicos no detienen unas de las fuerzas más poderosas en Washington simplemente escribiendo en sus portátiles!

Pero pasó. Y tú puedes hacer que pase de nuevo.

El sistema está cambiando. Gracias a la Internet, todos los días personas pueden saber acerca de cosas y organizarse incluso si el sistema está determinado a ignorarlo. Ahora, quizás no ganes todo el tiempo -- esto es la vida real, después de todo -- pero finalmente tenemos una oportunidad.

Pero sólo funciona si tú tomas parte en ello. Y ahora que has leído este libro y aprendido cómo hacerlo, estas perfectamente informado sobre cómo hacerlo de nuevo. Es correcto: ahora depende de ti cambiar el sistema.

Aaron Swartz.

El release candidate de v1.0.0 para transloadit-api ya está disponible.

Puedes instalarlo vía npm y probarlo:

npm install transloadit-api@1.0.0-rc1

Ahora soporta la API completa de transloadit: firmas, assemblies, notifications y manejo de plantillas.

El código está en github, la documentación en este website así como en los comentarios del código (que son la fuente para el website) y por supuesto: cualquier problema repórtalo en el tracker de github. Tiene un montón de pruebas pero aún le faltan algunas, especialmente para operaciones que requieren internet.

Quizás tenga tiempo para escribirlas esta semana y entonces lanzar una v1.0.0 como es.