En un tiempo en el que la vida social digital se desarrolla cada vez más dentro de aplicaciones cerradas y de diseño único, un nuevo marco de investigación llamado Graffiti ofrece una visión radicalmente diferente: cualquiera puede crear su propia aplicación social que se ajuste exactamente a las necesidades de su comunidad, sin perder por ello sus contactos existentes ni sus datos. Se trata de una capa de comunicación y datos destinada a la creación sencilla de herramientas sociales personalizadas mediante tecnologías front-end típicas (HTML, CSS, JavaScript), con interoperabilidad integrada entre diferentes aplicaciones y la propiedad del usuario sobre los datos almacenados en una infraestructura descentralizada.

Por qué deberían existir las aplicaciones sociales personalizadas

Imaginemos un club de conciertos independiente que quiere reunir a un público local en torno a nuevos artistas: intercambio de recomendaciones, breves fragmentos de ensayos, encuestas rápidas antes del programa, listas de canciones después de la actuación... Todo esto puede caber en una única aplicación social especializada y hecha a medida para la microcomunidad. El problema surge en el momento en que, en aras de dicha personalización, el público tiene que "trasladarse" a un nuevo servicio y construir allí de nuevo su grafo social, mientras que los creadores de la aplicación deben dominar y mantener un complejo back-end. Graffiti rompe este círculo vicioso de dos maneras: simplifica el desarrollo ofreciendo una capa de fondo común a la que acceden todas las aplicaciones y, al mismo tiempo, garantiza que las publicaciones y las conexiones sociales puedan verse y utilizarse en cualquier aplicación compatible, sin pérdida de continuidad entre las personas.

La idea clave: interoperabilidad sin el consentimiento del propietario de la plataforma

A diferencia de las redes sociales convencionales, donde la interoperabilidad suele estar limitada a las API definidas por el propietario de la plataforma, Graffiti propone un nivel de protocolo en el que todas las acciones sociales se "convierten" en datos que pueden ser leídos, compartidos e interpretados en diferentes aplicaciones cliente. Los autores denominan a este enfoque reificación total: cada interacción —desde una publicación y una respuesta hasta un "me gusta", un bloqueo, una denuncia o una moderación— se registra como un artefacto de datos independiente. Las aplicaciones deciden entonces, según sus propias reglas, cómo mostrar (o ignorar) estos artefactos, lo que permite que diferentes políticas y filosofías de diseño se implementen simultáneamente sobre el mismo grafo social.

En la práctica, esto significa que las comunidades pueden elegir a sus propios moderadores y sus propias reglas, sin dejar de estar "en la misma red" con los demás. Si una aplicación decide ocultar las publicaciones que una persona determinada ha marcado como inapropiadas, otra aplicación puede utilizar el mismo conjunto de metadatos solo para una advertencia o para clasificar. La moderación pasa así de ser una intervención monolítica y centralizada a una competencia de políticas y herramientas que los usuarios eligen.

Resolviendo el "colapso de contexto" con canales

La interoperabilidad también tiene un lado oscuro: el contenido creado para una audiencia puede acabar ante una completamente diferente. Este fenómeno, conocido en la literatura como colapso de contexto (del inglés context collapse), puede causar malentendidos y daños sociales cuando un mensaje se saca de su marco deseado. Graffiti aborda esto con el concepto de canales. Un canal es una "valla" flexible alrededor de un mensaje (o de todo un hilo) que representa un contexto específico: una persona, una aplicación, una organización, un lugar, un evento o una unidad temática. Las publicaciones visibles en un canal no tienen por qué "filtrarse" automáticamente a otro; el autor puede definir con más precisión la audiencia y evitar así la mezcla no deseada de contextos.

Desarrollo front-end sin un back-end pesado

Una de las ambiciones atractivas del marco es reducir la barrera de entrada para el desarrollo de aplicaciones sociales. Dado que el almacenamiento de contenido y el intercambio de datos se realizan en una infraestructura común y distribuida, los autores enfatizan que es posible construir clientes sociales funcionales solo con herramientas de front-end: HTML, CSS, bibliotecas de componentes o marcos populares como Vue. En lugar de que los equipos escriban y mantengan sus propios servidores, Graffiti estandariza la forma en que se guardan y recuperan los eventos reificados, permitiendo así que la energía se redirija a la experiencia del usuario, las políticas de seguridad en el cliente y la iteración rápida de nuevas funciones.

Propiedad de los datos e identidad portable

La promesa central de las redes sociales descentralizadas es la siguiente: los usuarios conservan sus datos e identidad incluso cuando cambian de aplicación. Graffiti lo hace operativo asegurando que los datos no "pertenezcan" al cliente, sino que se encuentren en un almacenamiento distribuido al que diferentes clientes pueden conectarse. La identidad y el grafo social se vuelven así portables, por lo que cambiar de aplicación ya no significa perder las conexiones. Dicha arquitectura va en consonancia con las tendencias más amplias de la web social descentralizada, que lleva años investigando cómo evitar el encierro en silos, desde el estándar ActivityPub que impulsa el fediverso hasta enfoques más recientes como el Protocolo AT sobre el que se está construyendo una serie de aplicaciones interoperables.

En qué se diferencia Graffiti de los protocolos descentralizados existentes

ActivityPub (una recomendación del W3C de 2018) se basa en una federación de servidores que intercambian actividades en el formato ActivityStreams 2.0; lo utilizan Mastodon y otros servicios del fediverso. El Protocolo AT, que está detrás de un creciente ecosistema de aplicaciones, ofrece identidades portables y la separación del almacenamiento de los clientes, así como feeds algorítmicos flexibles y herramientas de moderación abiertas. Graffiti comparte con ellos el objetivo de la portabilidad de la identidad y los datos, pero se distingue precisamente por la reificación total de las acciones sociales y un modelo de datos universal y agnóstico a la aplicación donde la propia moderación se registra como un dato. Este nivel de representación facilita la coexistencia de reglas contradictorias y permite que diferentes comunidades apliquen simultáneamente sus propias políticas de visibilidad y comportamiento sobre el mismo grafo.

Ejemplos de uso: desde escenas culturales hasta equipos de trabajo

Los autores ya han demostrado varias aplicaciones creadas sobre el marco, desde una interfaz de microblogging similar a las redes sociales "clásicas" hasta la edición colaborativa de contenido al estilo de una enciclopedia, el intercambio de mensajes cortos en tiempo real y aplicaciones dedicadas a comunidades locales. En el ejemplo concreto y aparentemente modesto del club de conciertos, Graffiti permite que el público abra canales temáticos (por ejemplo, por géneros, artistas o salas), comparta fragmentos y listas de reproducción, y que los moderadores, elegidos por la propia comunidad, establezcan reglas de visibilidad, sin temor a que estas determinaciones "inunden" los perfiles de los usuarios fuera del contexto del canal musical.

Es igualmente aplicable en entornos profesionales: los equipos pueden montar una herramienta mínima para una coordinación rápida con hilos por proyectos, mientras que comportamientos como "dar me gusta", "hacer ping" o "escalar" se registran como datos que otros clientes pueden traducir en sus propios patrones de interfaz de usuario. El resultado es un mosaico de aplicaciones compatibles de estética y profundidad diferentes, pero con el mismo "reservorio" social.

La moderación como un mercado de servicios, no como un comando central

Una objeción común a los sistemas descentralizados se refiere a la aplicación de las reglas: ¿quién "retira" el contenido ilegal o dañino? Graffiti no ofrece una única policía de contenidos, sino que permite que servicios de moderación rivales actúen sobre el mismo conjunto de datos sociales. Los usuarios —o comunidades enteras— eligen uno o más servicios, y las decisiones (etiquetas, bloqueos, advertencias) se registran como eventos reificados. Las aplicaciones luego interpretan estos eventos según sus propias reglas. Con ello se evita un estándar único que es necesariamente demasiado rígido para contextos culturales y legales diversos, pero también se abren serias preguntas de investigación sobre los límites de la protección personal y colectiva.

Seguridad, privacidad y los límites de la interoperabilidad

Independientemente de cómo se aborde la interoperabilidad, persiste una tensión no resuelta entre la apertura y la prevención de la difusión de contenido más allá de la audiencia prevista. Los canales ayudan, pero no eliminan la responsabilidad de los diseñadores de clientes y los administradores de comunidades de definir configuraciones de visibilidad predeterminadas razonables, la posibilidad de "bifurcar" hilos hacia espacios más cerrados, así como señalizadores de contexto claros. Además, la reificación de bloqueos y quejas crea metadatos que, si no se protegen, pueden revelar patrones de relaciones sociales. Por lo tanto, fortalecer la privacidad implica mecanismos criptográficos, enfoques de "divulgación selectiva" y políticas estrictas de retención de datos, algo que los autores han anunciado como una dirección futura de desarrollo.

Estado de la investigación y reconocimientos

El trabajo que presenta sistemáticamente el concepto y la implementación de Graffiti fue presentado en la conferencia anual UIST 2025, que se celebró del 28 de septiembre al 1 de octubre de 2025 en Busán. El programa de la conferencia menciona precisamente esta publicación con la firma de Theia Henderson, David R. Karger y David D. Clark, y el trabajo fue incluido entre los trabajos premiados de la conferencia. También está disponible un manuscrito revisado por pares en acceso abierto.

El propio contexto de la investigación se enmarca en los esfuerzos de varios años de las comunidades académicas y tecnológicas para construir sistemas de información descentralizados que devuelvan a los usuarios el control sobre sus datos e identidad, una tradición que en el MIT está representada simbólicamente por el trabajo de grupos dedicados a los paradigmas de la web descentralizada.

Comparación de paradigmas de diseño: qué significa una web social "componible"

En la web semántica ya hemos tenido una serie de intentos de estandarizar la comunicación a través de objetos y actividades genéricos (por ejemplo, ActivityStreams). Graffiti devuelve ese espíritu al lado del cliente y lo hace práctico para construir aplicaciones: en lugar de adaptarnos a una aplicación "principal" que prescribe cómo es una publicación, una respuesta o una denuncia, Graffiti estandariza la representación de los eventos, mientras que la interfaz, los flujos y las reglas de interpretación siguen siendo una cuestión de elección. De ahí surge una consecuencia inesperada: es más fácil construir "puentes" entre protocolos (por ejemplo, hacia el fediverso o el ecosistema del protocolo AT) porque la traducción se realiza a nivel de evento, y no a través de la clonación forzada de toda la lógica de la plataforma.

Qué significa esto para los creadores de contenido y las pequeñas organizaciones

Para los medios locales, las organizaciones culturales, las escuelas, las asociaciones y las startups, el mayor obstáculo hasta ahora ha sido la combinación de la complejidad técnica y el riesgo de la "habitación vacía". Si la comunidad tiene que abandonar su red existente, el proyecto tiene dificultades para despegar. Graffiti aborda esto ofreciendo tres beneficios prácticos: (1) la creación de un MVP solo con el front-end, (2) la portabilidad de la identidad y los datos sin "restablecer" las conexiones sociales y (3) la interoperabilidad nativa que permite que las publicaciones de una aplicación sean visibles en otra, sin la obligación de un diseño único o reglas centralizadas.

Ejemplos de escenarios y patrones de uso

• Microblog para distritos de la ciudad: canales por barrios y temas (agenda de eventos, llamadas a voluntariado, objetos perdidos y encontrados); en cada canal, reglas de moderación diferentes que la comunidad elige mediante la "suscripción" a servicios de moderación.


• Cooperativa editorial: edición de textos en forma de "hilos-wiki" donde las modificaciones, revisiones y etiquetas de calidad también son eventos reificados; otro cliente puede mostrar los mismos datos como un flujo de revisión por pares clásico.


• Escena musical: publicaciones de ensayos, listas de canciones y grabaciones de actuaciones viajan a través de los canales de los artistas, clubes y promotores; el público elige un cliente centrado en el audio, otro elige un cliente con hilos de foro; todos comparten el mismo conjunto de datos.


• Equipos de trabajo: integraciones sencillas con otros protocolos y servicios: la identidad es portable, por lo que cambiar a un nuevo cliente no interrumpe la red de contactos; las políticas de moderación pueden imitar los patrones de "revisión de código".

El panorama general: la carrera por una capa social interoperable

Los últimos dos años han traído una proliferación de iniciativas que buscan evitar la dependencia de una sola empresa: el fediverso basado en ActivityPub se expande a través de diversos software e integraciones, mientras que el ecosistema basado en el protocolo AT registra un crecimiento en el número de aplicaciones y usuarios, así como campañas que enfatizan los "intereses públicos" y la reconfiguración de la propiedad de las infraestructuras. Graffiti se inscribe en este paisaje como una propuesta de investigación que libera al máximo a los clientes: los desarrolladores pueden innovar a nivel de experiencia y funciones sin romper la interoperabilidad.

Cuestiones abiertas y desarrollo futuro

¿Hasta dónde puede llegar la moderación "personal" antes de volverse ineficaz contra el abuso organizado? ¿Cómo evitar que los eventos reificados (especialmente aquellos que apuntan a conflictos sociales) se utilicen como herramienta para el doxxing o el acoso selectivo? ¿Cuáles son los estándares mínimos de seguridad de los canales necesarios para evitar la reconstrucción de redes privadas a partir de metadatos? Y finalmente, ¿dónde trazar la línea entre la libertad de diseño y la responsabilidad hacia los grupos de usuarios más vulnerables? Los autores del proyecto ya han anunciado nuevas mejoras técnicas —desde herramientas para componer gráficamente clientes hasta mecanismos más fuertes de protección de la privacidad y seguridad— pero también investigaciones longitudinales sobre los efectos en el comportamiento de las comunidades.

Para quién está destinado Graffiti hoy en día

El mayor beneficio inmediato lo pueden obtener las organizaciones y los creadores que desean una interacción social rápida y temática sin construir un back-end y sin "desplazar" a su audiencia: medios locales e instituciones culturales, comunidades educativas, equipos de código abierto y asociaciones. Con algunos conocimientos de front-end y una idea clara sobre los canales y las reglas, pueden montar su propio cliente, incorporarse a los flujos de contenido existentes y, al mismo tiempo, mantener la propiedad de lo que producen. Para una aplicación más amplia —desde debates públicos masivos hasta temas sensibles— será crucial la calidad de los servicios de moderación, la ergonomía de los clientes y los estándares de protección de la privacidad que la comunidad acuerde.

Cómo empezar: directrices de diseño para un primer experimento

1. Defina los canales y la audiencia: antes de crear la interfaz de usuario, mapee los contextos (personas, equipos, lugares, eventos) y decida dónde puede aparecer cada contenido para evitar el colapso de contexto. Introduzca marcadores visuales de contexto claros y configuraciones de privacidad predeterminadas.


2. Modele las interacciones como datos: decida qué acciones serán reificadas (etiquetas de calidad, roles, bloqueos, denuncias, escaladas) y cómo las interpretará su aplicación. Planifique la posibilidad de que otro cliente interprete los mismos eventos de manera diferente.


3. Elija servicios de moderación: comience con al menos dos servicios independientes para probar la coexistencia de diferentes políticas. Añada una visualización clara de la fuente de las decisiones de moderación en la interfaz.


4. Asegure una identidad portable: planifique integraciones con protocolos que faciliten la migración y la retención del grafo social e indique a los usuarios dónde se guardan sus datos.


5. Itere con los usuarios: dado que la creación de clientes es sencilla, utilice ciclos rápidos de creación de prototipos; supervise los efectos en la cultura de la comunicación, especialmente a través de los límites de los canales.