Red social distribuida

Este artículo está motivado por el apunte de Manuel sobre una red social distribuida, a raíz de la reciente definición del concepto de pirámide de compromiso en la Indianopedia. Como la discusión allí parece bastante coherente y esto podría acabar siendo un batiburrillo sin demasiado sentido, me limitaré a exponer aquí algunas ideas sobre lo que podría ser una red social distribuida sencilla basada en herramientas existentes. ¡Atención, este artículo contiene bastante carga técnica!

Hace poco me quedé sin poder ver unas fotos de la Semana Santa Saguntina donde salía yo actuando en la Passió en viu, y que alguien había colgado en Facebook, ya que no tengo cuenta en él (tuve una durante unas semanas y espero no haber de revivirla). Tomando por una parte la reflexión del momento sobre qué me motivaría a colgar así unas fotos de contenido digamos «público», y por la otra la conversación en el blog de Manuel, llego a las funciones que yo mismo encuentro interesantes en una red social:

1. Autorizar sólo a mis amigos a ver o comentar lo que publico.
2. Seguir lo que publican mis amigos.
3. Encontrar nuevos amigos partiendo de los existentes.

Situación actual

Para comenzar, el concepto de amigo en la mayoría de redes sociales es realmente pobre y poco matizado, reduciéndose a una simple colección de contactos. En cambio, yo otorgo diferentes grados de confianza a diferentes personas. Es más, esta confianza no sólo depende de la persona, sino del asunto concreto de la información que esté publicando. Por ejemplo, puedo discutir la última clase de teatro con algún compañero, pero éste no tiene por qué saber nada de los problemas personales de mis amigos, y viceversa. En cambio, cualquiera puede conocer mis inquietudes sobre la propiedad intelectual.

Las redes sociales al uso fallan estrepitosamente en este aspecto porque, pese a permitir la autorización, esta es tan básica (i.e. los contactos ven, el resto no) que la sensibilidad de la información que pueda publicar en ella estará limitada por la confianza que tenga con el menos conocido de mis contactos. En los blogs no suele haber ningún control en este sentido, así que al final uno ha de recurrir a una multitud de foros, grupos y listas de correo temáticos cerrados para conseguir una cierta flexibilidad en la autorización.

El seguimiento de lo que publican los contactos queda más o menos resuelto con la redifusión vía RSS: cada contacto emite un canal RSS principal para sus envíos, y cada envío dispone de otro canal para sus comentarios —pero no obviemos que RSS tiene serias limitaciones para ligar comentarios y para recuperar entradas antiguas. Coincidiendo con Manuel y David, podemos ver el seguimiento del canal RSS como el vínculo básico entre contactos, y la publicidad de estos vínculos como una forma de mostrar adhesión (aunque la relación real pueda ser más profunda).

La búsqueda de nuevos contactos en una red social es tan pobre como su concepto de amigo, así que no hay nada que pueda garantizar cierta afinidad entre mí y el amigo de un amigo. En cambio, en un blog puedo, mediante comentarios y pingback, encontrar a gente que al menos muestra cierto interés por los mismos temas que yo. En un grupo o foro cerrado ya suelo conocer al resto de los participantes.

Una propuesta de mejora

Vamos a ver cómo podríamos aumentar la funcionalidad de un blog o un sistema de gestión de contenido existente (manteniendo así las islas digitales propuestas por Manuel) para dotarlo de las funciones básicas de una red social distribuida (y que nos evite de paso haber de echar mano de foros, grupos, listas y similares).

Respecto al significado de «amigo» o «contacto», podríamos intentar modelar los diferentes niveles de confianza en nuestro diseño, pero estaríamos forzando sobre el usuario un modelo concreto que éste no tendría por qué compartir. Sería más flexible, como comentaba el polémico Tuomo Valkonen en Wailing on mailing, dar más relevancia al propio hilo de discusión («thread»): el autor definiría el público de cada hilo (envío) individual, contacto por contacto o ayudándose por grupos de contactos que él mismo definiría y que en principio sólo tendrían sentido para él.

Lo anterior es muy similar a definir los destinatarios de un correo, pero hay dos diferencias fundamentales heredadas del sistema base. Por un lado, la posibilidad de que un envío sea abierto a todo el mundo. Por otro, el uso de canales RSS establece un modelo de publicación pull y no push: el destinatario tira del canal cuando quiere recibir nuevos envíos.

¿Cómo definir pues el público de un envío? Su autor asignaría a cada envío una lista de contactos que tendrían acceso a él, como usuarios locales de su sitio o como identidades OpenID (identidades asociadas a direcciones web y proporcionadas por multitud de proveedores o por el propio usuario). OpenID permitiría al autor listar lectores que aún no tienen cuenta de usuario en el sitio, y al lector usar una única identidad gestionada por él mismo y común a todos los sitios (sin necesidad de crear una cuenta en cada uno).

Dado un lector identificado (autenticado) en el sitio del emisor, el control de acceso (autorización) funcionaría así: en canal RSS principal sólo aparecen las entradas que tienen al lector como público, y el lector sólo tiene acceso a las páginas y canales de comentarios correspondientes a estos envíos (los envíos abiertos serían por supuesto accesibles a todo el mundo sin autenticación).

Por desgracia, ahora mismo HTTP no admite OpenID como método nativo de autenticación y es necesario parar por la página de identificación del sitio donde se encuentra el canal RSS —no conozco ningún programa lector de noticias que permita este tipo de autenticación. En cambio, los lectores RSS web podrían usar OAuth para acceder a los canales con las credenciales del usuario ya identificado con OpenID, pero éste debería habilitar a cada sitio el acceso desde su sitio lector vía OAuth. Una solución temporal pasa desgraciadamente por el uso tradicional de usuario y contraseña.

Finalmente, no tiene sentido mantener una conversación privada cuando no sabes quién más puede estar siguiéndola. Por lo tanto, un lector autenticado como parte del público de un envío privado debería ser capaz de ver la lista de contactos del mismo (de forma similar al Wave de Google). Justamente esto permite a los lectores descubrir nuevos contactos potencialmente interesados (según el autor) en los mismos temas (cada contacto de la lista suele ir acompañado de un enlace a su web o blog, que puede coincidir con su OpenID), incluso cuando no lleguen a comentar el envío. Por supuesto, se continúa disponiendo de comentarios y pingback.

Ejemplo

Alberto tiene un blog en http://www.albero.mec/. Crea un nuevo envío privado donde resume la última reunión de padres de niños con necesidades especiales de aprendizaje. Antes de enviarlo, incluye las identidades OpenID de Boris (http://boris.openid4u.mec/) y Carla (http://carla.blogs.mec/), que podrían estar interesados, entre el público del envío.

Boris sigue el canal RSS de Alberto, http://www.alberto.mec/feed. Abre su lector de noticias, activa en él su identidad OpenID y actualiza los canales RSS. Ve la noticia de Albero sobre la reunión, apunta su canal RSS de comentarios (http://www.albert.mec/reunion-del-miercoles/feed) y abre la página de la noticia en el navegador para preguntar en un comentario cuándo será la siguiente (Boris tiene un hijo autista). El sitio de Alberto le pide identificarse, así que introduce su OpenID y accede a la página del envío.

En la página aparece la lista de lectores designados por Alberto. Entre ellos aparece Carla, de quien no sabe nada hace tiempo. Boris ve que Carla (que es maestra) tiene un blog donde describe sus experiencias intentando aplicar nuevas técnicas de enseñanza para niños con dificultades. Boris incluye en su lector de noticias el canal RSS del blog de Carla, http://carla.blogs.mec/feed.xml, y también le envía un mensaje privado mediante el formulario de contacto de su blog para indicarle su identificador OpenID. Carla lo apunta en su grupo de contactos interesados en la educación de niños con necesidades especiales de aprendizaje.

Animado por Boris, Alberto incluye entre los canales RSS que indica seguir en su web el de Carla para dar publicidad a sus proyectos educativos.

Conclusión

De la misma forma que la Red de miniposts distribuida (RMD) usa tecnologías existentes para reemplazar sin complicaciones a propuestas centralizadas como Twitter, se podría conseguir una Red social distribuida (¿RSD?) usando unas pocas tecnologías existentes de formas ligeramente diferentes a como se está haciendo en la actualidad. Bien es cierto que quedan pendientes de resolver algunas cuestiones técnicas (fundamentalmente la autenticación OpenID para el acceso a los canales RSS), pero queda bastante claro que sería relativamente fácil aumentar redes distribuidas como la blogosfera con las funcionalidades mínimas de las actuales redes sociales centralizadas.

Creo que este sistema deja menor lugar a ciertos delirios de representatividad, ya que, siendo el autor quien elabora las listad de público para cada envío, hincharlas artificialmente sería indicativo de spam (y tampoco olvidemos que sólo son visibles para quien ya forma parte de ellas). Asimismo, mostrar públicamente qué canales seguimos podría indicar simple adhesión y dar publicidad a un recuento de gente que sigue nuestro canal tendría un cierto regusto rankista.

¿Cómo veis este sistema? ¿Creéis que es técnicamente posible? ¿Le veis algún sentido, o más bien está completamente fuera de lugar? Espero vuestras opiniones y críticas.