La red comunitaria
La red comunitaria
La red pública fue reducida, en buena medida, a un puñado de empresas.
La vastedad de Internet quedó detrás de unas pocas puertas de entrada, y casi toda la vida visible terminó empujada hacia allí: las conversaciones, la publicación, la organización de comunidades, la circulación de imágenes, la memoria, la reputación y hasta la idea misma de presencia.
La conveniencia hizo el resto. Era más fácil entrar que sostener un espacio propio, y esa facilidad fue vendida como progreso completo, aunque trajera consigo dependencia, encierro y adicción. La ciudad amurallada creció dentro de un territorio inmenso, y la mayoría quedó adentro sin recordar que afuera seguía existiendo el mundo real.
Y desde esta concentración se fue perdiendo la pertenencia y la personalidad. Antes, cada sitio podía tener una estética propia, una forma de escribir, una disposición característica de sus elementos, colores discutibles, decisiones arbitrarias y, justamente por eso, un lenguaje reconocible. Había lugares que pertenecían a alguien o a un grupo porque se notaba en su forma.
Hoy todo sigue la misma guía de estilos. Las interfaces repiten las mismas estructuras, los lenguajes se uniforman y las comunidades habitan espacios que visualmente no les pertenecen. Cambian los nombres, los avatares y algunos colores, pero el edificio es el mismo. También lo son las reglas, y buena parte de esas reglas arrastran una forma de entender el mundo según el corporativismo estadounidense, desde donde se define qué puede mostrarse, qué debe ocultarse y qué sensibilidad resulta aceptable para todos los demás.
El ciberespacio de antaño se basó principalmente en espacios de comunidad: lugares concretos, sostenidos por personas concretas, donde una página, una radio, un juego, un catálogo o una herramienta existían porque alguien los había puesto allí y otra gente sabía cómo encontrarlos. Tenían un alcance, una forma y una comunidad alrededor.
Hoy tenemos máquinas capaces de hablar entre sí, pero entre una y otra hemos colocado una cantidad considerable de trámites, empresas y permisos. Una persona quiere publicar algo y tiene ya una computadora, conexión y aquello que quiere compartir. Le faltan, según parece, miles de intermediarios más.
Entre una máquina y otra levantamos una aduana completa: cuentas, correos, dominios, proveedores, paneles, permisos, suscripciones, tokens y alguna contraseña más, porque una nunca alcanza.
Pero la máquina ya estaba lista antes que la burocracia, y hace falta recuperar una forma democrática de publicar desde dispositivos comunes, encontrar esos servicios dentro de una comunidad y permitir que dos pares se comuniquen sin una plataforma instalada de manera permanente entre ambos.
Las comunidades existen antes que las aplicaciones que usan. Tienen ya vínculos, acuerdos, conflictos y lenguajes propios, y la red debería servir a esa realidad en lugar de reemplazarla por una población de usuarios acomodada dentro de una interfaz universal.
Una plataforma puede reunir personas, pero puede también apropiarse del lugar donde esas personas se reúnen. Conserva los datos, cambia las reglas, decide qué se muestra y puede cerrar el espacio. Lo que parecía ser una comunidad termina viviendo en una habitación alquilada, con muebles que no puede mover y una puerta cuya llave posee otro.
Nadie necesita fabricar sus propias placas ni memorizar protocolos para recuperar algo de control sobre la infraestructura que usa. Esa falsa elección, hacerlo todo uno mismo o depender por completo de otro, sirve bastante bien para mantener las cosas como están.
Entre ambos extremos existe un territorio relegado.
Pero necesitamos redes informáticas sostenidas por su comunidad, compuesta por servicios autónomos que sus integrantes pueden publicar, descubrir y utilizar desde dispositivos comunes, sin depender de una plataforma central, una identidad global ni un intermediario permanente entre los pares.
Una Red comunitaria se define por la propiedad de su infraestructura y por la forma en que esa infraestructura se organiza. Sus puntos de coordinación facilitan el encuentro, pero no concentran necesariamente los contenidos, los datos, la identidad ni las comunicaciones. Cada servicio puede tener su propia escala, duración, estética y reglas, bajo el control de la comunidad que lo sostiene.
Una red comunitaria no tiene por qué ser una plataforma
Las plataformas necesitan control, seguir y captar datos de los usuarios, establecer condiciones y conservar registros indelebles de lo que ocurre allí. Pueden hacerlo por seguridad, por comodidad, por razones comerciales o por todas juntas. Lo cierto es que la participación queda atada a una infraestructura que permanece en el centro.
Pero una red comunitaria puede funcionar de otra manera.
Puede limitarse a ayudar a que dos dispositivos se encuentren. Puede hacerlo sin alojar aquello que comparten, sin transportar de manera permanente su conversación y sin construir una identidad general para cada persona.
No necesita saberlo todo, ni necesita durar para siempre.
Hay servicios cuyo sentido termina en una comunidad determinada. Su alcance puede ser pequeño y, aun así, completo.
La costumbre de medir toda infraestructura por su alcance confunde crecimiento con valor. Una red comunitaria de cinco personas puede funcionar. Puede incluso funcionar mejor, para esas cinco personas, que una plataforma con millones.
Pequeño no significa provisional. Local no significa atrasado. Y temporal no significa roto.
La feria como ejemplo
Una feria de barrio no exige registro, uno llega y ve qué puestos están abiertos. Algunos permanecen cada semana; otros aparecen de vez en cuando. Cada puesto ofrece algo distinto, y la feria existe por esa suma irregular.
Nadie supone que la feria deba estar disponible las veinticuatro horas. El puesto está mientras alguien lo sostiene.
Esta forma de existencia, obvia fuera de la informática, parece volverse sospechosa apenas entra una computadora. Se espera entonces disponibilidad permanente, respaldo mundial, crecimiento indefinido y una interfaz capaz de recibir a millones de personas que nunca llegarán.
La feria sirve aquí como ejemplo de una forma comunitaria de red.
Un servicio aparece. Permanece unas horas. Se apaga con la máquina. Vuelve la semana siguiente.
Puede estar hoy y no mañana, sin que eso constituya un fracaso. Su temporalidad pertenece a la gente que lo sostiene, a sus horarios y a los recursos que tiene disponibles.
Una red comunitaria puede asumir la temporalidad de quienes la sostienen. Es decir, no hay obligación de volver la expresión en un calendario estricto por el miedo de quedar enterrado por "el algoritmo".
Visibilidad sin competencia
Las plataformas actuales muestran lo que existe y ordenan lo que vemos según criterios basados en sus intereses.
Priorizan, recomiendan, ocultan y vuelven a ordenar según métricas que pertenecen a sus propios objetivos. Un contenido aparece porque genera interacción; otro se hunde porque no produce suficiente retención.
La visibilidad se convierte en una competencia. Quien publica no habla solo con su comunidad; habla también con la máquina que decide si la comunidad llegará a verlo.
Una red comunitaria organizada como feria puede presentar sus servicios de otra manera. Puede mostrar nombres, íconos, descripciones, categorías, estados e información comunitaria. Puede tener una interfaz cuidada, un directorio visual o algo semejante a una tienda de aplicaciones.
Lo decisivo es que los puestos puedan existir sin competir ante un algoritmo.
Estar presente debería alcanzar para ser encontrado. Luego cada persona recorrerá, elegirá o ignorará lo que tenga delante, como ha hecho siempre la gente cuando nadie optimiza su atención por ella.
La comunidad no es una métrica
La palabra comunidad se usa con una facilidad sospechosa. Una plataforma reúne usuarios y llama comunidad al conjunto, pero el espacio, los datos, las reglas y la visibilidad siguen perteneciendo a la empresa.
La plataforma puede cambiar las condiciones, puede cerrar una función, ocultar publicaciones, expulsar personas e incluso puede desaparecer.
Quienes creían haber construido un lugar descubren entonces que tenían una audiencia alojada en propiedad ajena.
Pero una comunidad es algo más que una cantidad de cuentas, es un grupo capaz de sostener vínculos, normas y espacios propios. No de manera perfecta ni necesariamente autosuficiente, pero sí con alguna posibilidad real de decidir, copiar, reemplazar y marcharse.
La tecnología debería facilitar esa autonomía y en vez de sustituirla por un panel de administración.
El ciberespacio como red de comunidades
Conviene recuperar una palabra que parece haber quedado vieja: ciberespacio.
Permite pensar la red como un ámbito compuesto por lugares, relaciones y servicios. Dentro de ese espacio pueden existir focos comunitarios: una página mantenida por alguien, un servidor conocido por un grupo, un foro, una radio, un catálogo o una herramienta compartida. Cada foco tiene su gente, su alcance y su forma de sostenerse.
La Web temprana mostró una parte de esa posibilidad. Estaba hecha de páginas personales, foros, servidores y directorios construidos por personas u organizaciones concretas. Había lugares, y alrededor de esos lugares se formaban comunidades.
Publicar, sin embargo, requería conocimientos, infraestructura y recursos que no estaban al alcance de cualquiera. Durante mucho tiempo, las redes fueron territorio de universidades, empresas grandes y especialistas. La masificación amplió el acceso, pero concentró también la capacidad de publicar dentro de sistemas controlados por otros.
Las condiciones materiales son hoy distintas. Hay en hogares, comercios y bolsillos máquinas con una capacidad que habría resultado absurda décadas atrás. Esa capacidad permite recuperar algo de lo que se perdió: un ciberespacio formado por muchos focos de comunidad, pequeños o grandes, permanentes o temporales, conectados sin quedar subordinados a una sola plataforma.
La posibilidad que importa es que una comunidad pueda tener un lugar propio en la red, reconocible también por su forma, y sostenerlo con sus propios medios.
Publicar sin comprar presencia
Una persona puede compartir desde su casa un servidor de juego, un comercio puede servir un catálogo desde la computadora del local, una familia puede ofrecer archivos o herramientas a sus integrantes, un grupo puede levantar una radio, una cooperativa puede mantener servicios internos, un barrio puede tener una cartelera o una pequeña web comunitaria.
La infraestructura permanece en manos de quienes la usan. La publicación puede existir también desde infraestructura propia y cercana.
A veces convendrá hacerlo y a veces no será necesario.
Pero no debería ser una condición metafísica del ciberespacio, como si un servicio no existiera hasta que alguien emite una factura por alojarlo.
Algunas definiciones técnicas
Si dos equipos pueden comunicarse entre sí, la ruta de los datos debería unirlos sin dejar a un tercero instalado en el medio. A esta forma de comunicación se la llama P2P, o peer to peer: conexión entre pares.
El problema es que la mayoría de las conexiones domésticas y móviles no muestran cada dispositivo directamente a Internet. El router, o incluso la empresa proveedora, agrupa varias máquinas detrás de una misma dirección pública. Ese mecanismo se llama NAT y decide qué tráfico puede entrar y a cuál de los dispositivos debe enviarlo.
Cuando una máquina inicia una conexión hacia afuera, el NAT (Network Address Translation) abre temporalmente un camino y recuerda por dónde debe regresar la respuesta. La dificultad aparece cuando dos dispositivos, ambos detrás de sus respectivos NAT, intentan encontrarse entre sí.
Una técnica llamada hole punching, perforación de puertos, aprovecha esas aberturas temporales. Los dos pares coordinan el intento y envían tráfico casi al mismo tiempo, esperando que cada NAT habilite una ruta compatible con la del otro.
Algunos NAT asignan una puerta pública distinta según el destino al que se intenta llegar. Se los suele llamar NAT simétricos. En esos casos, la dirección que un servidor observó puede no servir para comunicarse con otro, porque la abertura existía solamente para aquella conversación.
STUN (Session Traversal Utilities for NAT) es un protocolo que ayuda a un dispositivo a descubrir cómo se lo ve desde afuera: qué dirección y qué puerto público le fueron asignados. Puede mostrar una posible entrada, pero no obliga al NAT a conservarla cuando cambia el interlocutor.
TURN (Traversal Using Relays around NAT) coloca un servidor accesible para ambos extremos. Cada par se conecta a ese servidor y el servidor reenvía el tráfico. A ese servidor intermedio se lo llama relay, retransmisor.
ICE (Interactive Connectivity Establishment) reúne distintas rutas posibles y las prueba. Intenta primero establecer una conexión directa y, cuando ninguna funciona, suele recurrir a TURN.
La conexión funciona, pero ha cambiado de naturaleza.
El relay recibe y reenvía cada paquete, consume ancho de banda, mantiene sesiones y debe permanecer disponible mientras dure la comunicación. Al crecer la red, crecen también sus máquinas, sus enlaces y su costo operativo.
Quien controla ese punto ocupa una posición privilegiada con respecto a los demás. Puede observar el paso del tráfico, limitarlo, cobrarlo, suspenderlo o convertir su disponibilidad en una condición para toda la red.
Quizá el centro tenga varias regiones, nombres agradables y diagramas llenos de flechas. Para los pares que dependen de él, sigue siendo un centro.
De allí decanta también un desbalance de poder. La infraestructura que comenzó como una salida para conexiones difíciles puede transformarse en la pieza que todos necesitan, y quien puede sostenerla termina controlando el acceso de quienes no pueden pagar una equivalente.
La concentración rara vez aparece completa desde el comienzo. Suele formarse alrededor de dependencias que, una por una, parecían prácticas.
Una red comunitaria basada en comunicación directa puede asumir otro límite: cuando el camino entre pares no resulta posible, la conexión falla. Esa decisión sacrifica cobertura universal para conservar la arquitectura que le da sentido.
BitTorrent acepta una limitación parecida con respecto a la disponibilidad. Los archivos se dividen y distribuyen entre los pares, y quienes poseen una parte pueden compartirla con los demás. Puede haber servidores que ayuden a encontrarlos, pero no existe un servidor único encargado de conservar y transmitir todo el contenido. Si ningún par disponible tiene aquello que falta, la descarga no continúa.
Otras redes P2P persiguen objetivos diferentes. I2P, por ejemplo, prioriza la privacidad y el anonimato. En lugar de unir directamente al origen con el destino, hace circular el tráfico por túneles construidos entre varios pares, de manera que ninguno de ellos necesite conocer por completo quién se comunica con quién. No elimina los intermediarios, pero distribuye esa función entre los participantes para evitar que quede concentrada en un único servidor.
WebRTC, en cambio, está pensado principalmente para la comunicación en tiempo real dentro de aplicaciones web. Intenta establecer una ruta directa mediante ICE y STUN, pero, cuando esa ruta no resulta posible, puede recurrir a TURN para mantener la conexión a través de un relay. Resuelve así una necesidad práctica de conectividad, aunque en ese caso los datos dejan de viajar directamente entre los pares.
No existe una única manera de construir tecnología P2P. Cada aplicación puede incorporar relays externos si lo requiere, pero conviene llamar a cada cosa por su nombre: una ruta directa conecta pares; una ruta mediada depende de un tercero, y eso ya no es P2P, aunque lo quieran dibujar como tal.
Una base, no una aplicación total
Una infraestructura mínima puede resolver el encuentro entre quien publica y quien consume, y las aplicaciones construidas encima decidirán el resto. Pueden agregar catálogos, metadatos, permisos, identidad local, invitaciones, protocolos comunitarios o mecanismos externos de relay. La forma final pertenece a la aplicación y a la comunidad que la usa.
Una comunidad puede necesitar identidad local mientras otra puede preferir no tenerla. Una aplicación puede usar invitaciones, otra puede publicar de forma abierta. Una puede aceptar intermediarios, otra puede rechazar cualquier relay.
El núcleo no debería anticipar todas las decisiones ni imponer una forma universal de organización, debe entrega piezas. Y la comunidad decide qué construir con ellas y, si la pieza deja de servir, la cambia.
Libertad para irse
Una infraestructura saludable debe permitir entrar, pero también salir. Debe poder levantar otro servidor, publicar en varios, dejar de publicar, copiar una lista, modificar el software, cambiar de herramienta, empezar otra red.
Cada nodo debería poder reemplazarse, y cada comunidad debería conservar el control sobre su identidad, su historial y el acceso a sus miembros. La libertad tecnológica incluye la posibilidad de elegir entre opciones y, sobre todo, de abandonar el menú.
Una red comunitaria apropiable debe sobrevivir a la desaparición de sus piezas, incluso de aquella herramienta con la que comenzó.
No hace falta conquistar el mundo
La propuesta no compite por ocupar el lugar de las plataformas, los servicios de nube ni las redes globales. Ocupa otro lugar. El que hoy falta.
Una red comunitaria usada por cinco amigos puede ser exitosa. Una instalación familiar puede ser suficiente. Un servicio para un comercio puede cumplir su propósito sin expandirse a otros comercios, otras ciudades y otros continentes. Una comunidad pequeña no es una plataforma fallida. No está esperando convertirse en algo más serio. La costumbre de medir valor mediante cuentas, permanencia y cuota de mercado pertenece a empresas que necesitan crecer. No tiene por qué gobernar toda herramienta ni toda red. Algo puede existir poco tiempo, servir a pocas personas y desaparecer después. Y puede haber valido la pena de todos modos.
Experiencias y proyectos afines
En distintos lugares existen comunidades que construyen, administran y sostienen sus propias infraestructuras informáticas. No todas persiguen la misma arquitectura ni resuelven el mismo problema, pero demuestran que una red puede ser algo más que un servicio recibido pasivamente de una empresa.
En Villa Soldati, Buenos Aires, Soldati Conectada construyó una red comunitaria de Internet impulsada por El Hormiguero, FM Soldati y otras organizaciones del barrio. Su primera etapa conectó espacios mediante fibra óptica y combinó la infraestructura con acceso público, alfabetización tecnológica y participación comunitaria. Este proyecto lleva conectividad al territorio mientras incorpora a la comunidad en la construcción y el sostenimiento de la infraestructura.
También en Argentina, AlterMundi desarrolla hardware abierto y software libre para redes comunitarias. Herramientas como LibreRouter y experiencias como QuintanaLibre, en la provincia de Córdoba, buscan reducir las barreras técnicas y económicas para desplegar conectividad autónoma, utilizando equipos que las propias comunidades puedan instalar, comprender y mantener.
En Cataluña, Guifi.net organiza una infraestructura de telecomunicaciones compartida, abierta, libre y neutral, tratada como un bien común. Personas, organizaciones, administraciones y operadores pueden aportar recursos y utilizar la red bajo reglas destinadas a evitar que una sola parte se apropie de la infraestructura común.
En comunidades rurales e indígenas de México, las experiencias acompañadas por Rhizomatica muestran que una comunidad puede construir y gobernar incluso su propia infraestructura de telefonía celular. Su trabajo combina tecnologías abiertas, participación directa, formación técnica y cambios regulatorios para sostener redes propiedad de las comunidades que las utilizan.
En zonas rurales de Grecia, Sarantaporo.gr construye infraestructura inalámbrica comunitaria como un bien común. La red pertenece a la comunidad local, se sostiene mediante las contribuciones de sus participantes y sirve tanto para acceder a Internet como para desarrollar servicios de telefonía, intercambio de archivos, acceso remoto y otras aplicaciones locales. El proyecto vincula además la infraestructura con alfabetización digital y participación comunitaria.
Estas experiencias se concentran principalmente en la propiedad, el despliegue y el gobierno de la conectividad. La propuesta de este manifiesto se relaciona con ellas, pero extiende la pregunta hacia otra capa: cómo puede una comunidad publicar, encontrar y utilizar sus propios servicios sin convertir necesariamente esa infraestructura en una plataforma central.
Una red comunitaria necesita caminos propios, pero también lugares propios a los que esos caminos permitan llegar.
Una implementación posible: RP2P
Estas redes comunitarias que construyen enlaces inalámbricos, despliegan fibra, instalan antenas, administran routers o sostienen infraestructura celular, resuelven problemas fundamentales y demuestran que una comunidad puede apropiarse de los medios con los que se conecta. También muestran, sin embargo, que muchas redes comunitarias requieren equipamiento específico, planificación territorial, instalación física y personas con conocimientos técnicos capaces de mantenerlas. Eso no las vuelve menos valiosas. Significa que trabajan sobre una capa distinta del problema.
RP2P parte de otra pregunta: qué puede hacerse con las máquinas y las conexiones que una comunidad ya tiene.
No pretende reemplazar una red comunitaria de acceso, un proveedor cooperativo, una malla inalámbrica ni una infraestructura de telefonía. Puede funcionar sobre cualquiera de ellas. También puede funcionar sobre una red doméstica, una conexión comercial, una red móvil o la Internet pública.
RP2P utiliza la infraestructura subyacente para ofrecer una capa pequeña a fin de habilitar a los usuarios a publicar, encontrar y conectar servicios sin exigir que la comunidad construya primero una plataforma completa ni mantenga una infraestructura central encargada de alojarlos.
Es una biblioteca y una herramienta de línea de comandos escrita en C. Organiza la comunicación alrededor de tres funciones: quien publica un servicio, quien quiere utilizarlo y un índice que ayuda a que ambos se encuentren.
El índice conserva la información necesaria para presentar los extremos, pero no aloja el servicio ni necesita transportar sus datos durante toda la comunicación. Una vez producido el encuentro, RP2P procura establecer una ruta directa entre los pares.
El tráfico viaja sobre UDP mediante hole punching, con descubrimiento STUN opcional. Para aplicaciones que esperan una conexión TCP, RP2P incorpora una capa confiable y cifrada sobre ese camino UDP.
De este modo, una aplicación existente puede publicarse sin haber sido diseñada originalmente como una aplicación P2P. Un servidor de juego, una radio, un catálogo, una cartelera, una herramienta interna o cualquier otro servicio puede utilizar RP2P como medio de encuentro y transporte. La intención es que levantar un servicio comunitario no requiera desplegar una arquitectura nueva para cada aplicación.
RP2P tampoco exige una clase especial de dispositivo. Puede ejecutarse en una computadora doméstica, un pequeño servidor, la máquina de un comercio o cualquier equipo capaz de sostener el servicio. Un mismo dispositivo puede publicar, consumir o actuar como índice.
Los índices pueden ser pequeños, temporales y reemplazables. Una comunidad puede levantar uno propio, utilizar varios o compartir su dirección por los medios que ya usa. No necesita registrarlo ante una autoridad global ni convertirlo en el centro permanente de la red.
Los nombres publicados en un índice son identificadores operativos, no cuentas personales. Pueden señalar servicios como radio, pedidos, juego o catalogo. La publicación puede protegerse mediante contraseñas y ciertos nombres pueden reservarse sin construir alrededor de ellos una identidad universal ni una base de usuarios.
RP2P no incorpora TURN como mecanismo central y el índice no funciona normalmente como relay. Si dos pares no pueden establecer una ruta directa, la conexión puede fallar. Ese límite fue elegido para evitar que una solución auxiliar termine convertida en la infraestructura obligatoria de toda la red.
Esto permite que RP2P sea pequeño también en términos operativos. No promete resolver la conectividad de cualquier dispositivo bajo cualquier condición. Busca resolver una tarea más acotada: que dos extremos puedan encontrarse e intentar comunicarse directamente utilizando la infraestructura disponible. Esa reducción del alcance es parte de su propuesta.
Dentro del mismo campo existe libp2p, un stack modular y ampliamente desarrollada para construir distintas clases de redes y aplicaciones entre pares. Reúne transportes, canales seguros, multiplexación, descubrimiento, routing, atravesamiento de NAT, relays y otras piezas que pueden combinarse según las necesidades de cada sistema.
Ese alcance responde a otro propósito. Quien necesita una plataforma general, extensible e interoperable encuentra allí herramientas para resolver una variedad mucho mayor de topologías y escenarios. RP2P no intenta reemplazarla ni reproducir todo lo que ofrece.
Su elección es mantener una superficie pequeña. No hace falta estudiar una colección extensa de módulos, comparar varias formas de ensamblar la red ni convertirse en especialista en un ecosistema antes de conectar dos extremos. Hay pocas piezas, un flujo concreto y una implementación que puede leerse de principio a fin.
En un entorno técnico donde las soluciones grandes suelen convertirse en la referencia automática, esta diferencia de escala merece quedar explícita. El núcleo de RP2P ocupa un lugar más limitado por decisión: ofrece una base directa para publicar, encontrar y conectar servicios sin intentar convertirse en una plataforma técnica capaz de anticipar todas las implementaciones posibles.
Pero RP2P no termina en esa biblioteca. El proyecto surge también para desarrollar soluciones descentralizadas concretas sobre esa base y llevarlas hasta los problemas descritos en este texto: la dependencia de plataformas centrales, la dificultad de publicar desde infraestructura propia y la pérdida de espacios que puedan permanecer bajo control de sus comunidades.
La separación entre núcleo y aplicaciones permite conservar una base pequeña sin desentenderse de lo que se construye encima. La biblioteca no necesita incorporar catálogos, interfaces, identidad comunitaria, herramientas para comercios, radios o directorios. Esas soluciones pueden existir como proyectos independientes y responsables de sus decisiones particulares.
El objetivo consiste en sostener un núcleo comprensible y, a partir de él, construir aplicaciones capaces de convertir esa arquitectura en lugares habitables dentro de la red.
Mientras otros proyectos comunitarios construyen los caminos, RP2P puede ayudar a construir los lugares a los que esos caminos conducen.
Una red como Soldati Conectada, Guifi.net, QuintanaLibre o cualquier otra infraestructura comunitaria podría transportar servicios publicados mediante RP2P. En ese contexto, ambas capas se complementan: la red comunitaria ofrece conectividad y RP2P permite que quienes la integran publiquen y descubran servicios propios sobre ella.
Pero RP2P no necesita esperar a que exista una infraestructura comunitaria especializada. Puede comenzar con una computadora, una conexión a Internet cualquiera y algo que se quiera compartir.
No se presenta aquí una respuesta universal ni una herramienta destinada a reemplazar todo lo demás. Su núcleo es una pieza pequeña, combinable y prescindible. Una comunidad puede usarlo junto con otras tecnologías, modificarlo o reemplazarlo. Al mismo tiempo, RP2P continuará desarrollando aplicaciones concretas sobre esa base, porque la arquitectura adquiere sentido cuando puede convertirse en herramientas que una comunidad realmente pueda usar.
El proyecto está disponible en https://github.com/kaisarcode/rp2p.c.
El ciberespacio puede volver a tener focos de comunidad: lugares sostenidos por quienes los usan, desplegados sobre la infraestructura que tengan disponible y conectados sin quedar absorbidos por una única plataforma.
Un servicio aparece, otro se apaga y la comunidad cambia. Algunos espacios duran años; otros, una tarde. Su valor no depende de ser global, eterno o capaz de convertirse en monopolio.
Quien publica, quien busca y el punto de encuentro
Para que una red basada en RP2P funcione hacen falta, en términos generales, tres cosas.
- Alguien publica un servicio.
- Alguien quiere encontrarlo.
- Y algo ayuda a que ambos se ubiquen.
Ese punto de encuentro es un índice que guarda un nombre y la información necesaria para presentar los extremos. No aloja la aplicación, no conserva sus datos y no tiene por qué permanecer en la ruta una vez producido el encuentro. Su tarea solo es coordinar.
Conviene detenerse en esa palabra porque la coordinación tiene una tendencia conocida a convertirse en gobierno. Un sistema empieza registrando nombres, luego autentica personas, después conserva información, transporta el tráfico y termina decidiendo quién puede entrar.
No sucede por una maldad intrínseca del servidor. Sucede porque cada función nueva parece razonable cuando se la mira por separado. Por eso es importante el límite. El índice ayuda a encontrar, pero después debería apartarse.
Cada persona o comunidad debería poder levantar, compartir y reemplazar su propio índice. Un mismo dispositivo debe poder publicar, consumir y servir de punto de encuentro. No hay allí clases naturales de máquinas. Hay funciones, y las funciones pueden moverse.
Dispositivos comunes como infraestructura
Una computadora doméstica es infraestructura. También lo es la máquina de un comercio, un pequeño servidor, una placa de bajo consumo o algún equipo viejo que todavía respira debajo de un escritorio. La infraestructura empieza también en las máquinas que ya están al alcance de una comunidad.
Los dispositivos comunes procesan, almacenan y transmiten bastante más de lo que muchas aplicaciones les permiten hacer. Se los trata con frecuencia como terminales de servicios remotos, pantallas obedientes que envían información hacia máquinas ajenas, aun cuando tienen recursos suficientes para sostener una parte del trabajo.
Una red comunitaria pequeña puede distribuir ese trabajo entre los extremos. Quien publica sostiene su servicio, quien participa aporta su conexión. Los datos pueden procesarse cerca de quienes los producen.
El índice realiza solamente la coordinación necesaria, y la capacidad surge entonces de la suma de los participantes y no del crecimiento de un servidor central.
A esto puede llamárselo edge computing, si hace falta ponerle nombre. En términos menos ceremoniosos, significa usar las máquinas que ya están ahí.
Crecer por multiplicación
Escalar suele significar agrandar. Más memoria, más procesadores, más regiones, más ancho de banda y una factura cuyo número de ceros indica, supuestamente, el éxito del proyecto. Pero una red comunitaria puede crecer de otra forma. En lugar de un índice cada vez más grande, puede tener muchos índices pequeños. Independientes, superpuestos y administrados por personas distintas.
Un servicio puede anunciarse en más de uno, una aplicación puede consultar varios, una comunidad puede conservar una lista de índices conocidos y compartirla con otras. No hace falta que todos se sincronicen. No hace falta una autoridad global que establezca cuáles son legítimos. La red crece por tejido: un grupo conoce a otro, un índice se comparte, un servicio aparece en varios lugares.
Más vínculos en vez de un centro más grande. Esta forma de escala no promete uniformidad. Dos comunidades pueden organizarse de maneras distintas. Pueden aceptar reglas diferentes e incluso no conocerse. Esa diversidad expresa una pluralidad real, con todas sus incomodidades incluidas.
De boca en boca
No es obligatorio el descubrimiento mundial, la dirección de un índice puede enviarse en un mensaje, imprimirse en un papel, ponerse en un código QR, guardarse en un archivo o copiarse en una memoria USB. La entrada a una red comunitaria puede consistir en una frase "Usá este índice y buscá este nombre."
La confianza, en ese caso proviene de una relación anterior y no de una insignia otorgada por una empresa. Alguien conoce a quien compartió la dirección. Los clientes conocen al comercio, los miembros conocen a la cooperativa, el grupo sabe, más o menos, quién está dentro. La confianza puede ser local, parcial y suficiente para la situación. Y también puede equivocarse, claro. Las relaciones humanas son así. Pero delegar toda confianza en una plataforma no elimina el problema; apenas cambia quién puede equivocarse y quién conserva la autoridad cuando lo hace.
Sin cuentas por defecto
En una red basada en RP2P, un nombre usado para encontrar un servicio no es una cuenta. Puede ser radio, catalogo, juego o cualquier identificador que tenga sentido dentro de un índice. Señala dónde buscar algo. No necesita representar a una persona ante el resto del mundo. No requiere correo electrónico ni necesita un perfil ni recuperación de contraseña. Tampoco construye una identidad global. Las cuentas traen consigo una estructura: una entidad debe crearlas, almacenarlas, recuperarlas y, llegado el caso, suspenderlas. No aparecen solas ni son una condición natural de la comunicación. Participar en una red comunitaria no debería obligar a pertenecer de forma permanente a una organización, ni usar una herramienta tampoco.
Contraseñas para cosas concretas
Que una red comunitaria no tenga cuentas no significa que deba renunciar a todo control, un índice puede necesitar una contraseña para limitar quién publica. Puede reservar ciertos nombres para evitar que otra persona los ocupe durante una desconexión. Un comercio, por ejemplo, podría publicar servicios llamados:
- catalogo
- pedidos
- radio
- reservas
Si pedidos se desconecta por un momento, no conviene que cualquier otro publisher pueda apropiarse del nombre y presentarse como el servicio original. La contraseña protege entonces un recurso específico: la publicación o la ocupación de un identificador, sin necesitar una identidad personal ni requerir datos personales a quienes consumen el servicio. El índice debe dejar de ser un proveedor de cuentas. Una contraseña puede resolver un problema acotado sin que alrededor de ella tenga que crecer una oficina de documentación digital.
Las limitaciones son parte del diseño
En tecnología, toda ausencia suele interpretarse como una función pendiente.
Si no hay perfiles, habrá que agregarlos. Si no hay seguidores, faltará crecimiento. Si no hay métricas, nadie sabrá qué ocurre. Si no hay autoridad central, el sistema parecerá incompleto. Y si no funciona bajo cualquier red y circunstancia, alguien pedirá un relay obligatorio para corregirlo. Así se acumulan funciones razonables hasta obtener, una vez más, una plataforma centralizada.
Una base comunitaria puede prescindir de identidad global, métricas sociales, telemetría obligatoria, almacenamiento central y una autoridad oficial. También puede aceptar que sus índices no se sincronicen en todo el mundo, que algunos servicios sean temporales y que la comunicación directa tenga límites.
Estas ausencias distan de ser errores, pues algunas funciones exigen infraestructura difícil de sostener en pequeña escala, o crean centros de control. Otras permiten acumular datos o decidir visibilidad. Por lo tanto, la capacidad técnica debe alejarse del núcleo. Las limitaciones pueden proteger una escala, y la escala puede proteger cierta libertad.
Lo que viene
La base está establecida, pero una infraestructura por sí sola no alcanza.
Todavía hacen falta aplicaciones que traduzcan estos principios a herramientas utilizables por personas que no deberían necesitar comprender NAT, UDP, índices ni perforación de puertos para participar. Publicar un servicio, encontrarlo, compartir un índice o levantar un espacio comunitario debería ser una tarea cotidiana y no una especialidad.
Harán falta interfaces simples, instaladores, directorios visuales, herramientas para comercios, radios, juegos, archivos, carteleras y servicios internos. También harán falta documentación, ejemplos, pruebas en situaciones reales y comunidades dispuestas a descubrir qué partes de esta propuesta funcionan, cuáles deben cambiar y cuáles conviene abandonar.
Necesitamos producir piezas pequeñas, comprensibles y combinables, de manera que cada comunidad pueda elegir qué necesita y qué no.
Algunas aplicaciones podrán durar años. Otras resolverán una necesidad puntual y desaparecerán. Algunas usarán RP2P directamente; otras incorporarán sus ideas de otra manera o construirán sobre infraestructuras comunitarias ya existentes. El trabajo que sigue consiste en agregar interfaces, y también en conservar los límites: evitar que el índice se convierta en plataforma, que la facilidad de uso exija una identidad global y que la búsqueda de conectividad universal reinstale un centro obligatorio.
La medida del avance no será la cantidad de usuarios ni la velocidad de crecimiento. Será algo más concreto: que una persona o una comunidad pueda poner en marcha un servicio propio, compartirlo y sostenerlo con los recursos que ya tiene.
La red, puede volver a ser un espacio común, el Ciberespacio recuperado, formado por muchos lugares propios, directos y sostenidos por sus comunidades.
Licencia
Esta obra está bajo licencia CC BY-NC-ND 4.0: puede compartirse dando el crédito adecuado, pero no modificarse ni utilizarse con fines comerciales.
El software RP2P se distribuye por separado bajo la licencia GNU General Public License v3.0.