La aparición de plataformas de redes sociales controladas por corporaciones, impulsadas por motivos comerciales, ha erosionado significativamente la esperanza inicial de una cultura participativa en línea. Las tecnologías de la información en red deberían democratizar fundamentalmente la producción cultural, pero en la actualidad, estas plataformas limitan y moldean la participación en línea principalmente con fines lucrativos: un 'me gusta' no es una expresión de gratitud por un contenido, sino que es una herramienta de monetización que impulsa algoritmos motivados comercialmente.

Plataformas alternativas de redes sociales construidas sobre protocolos descentralizados y federados ofrecen un retorno a la concepción original de la socialidad en línea. Los datos son controlados por el usuario y se propagan a través de bases de datos descentralizadas, los frontends son impulsados por la comunidad, la moderación es una expresión de las preferencias de la comunidad, los algoritmos son elegidos por el usuario y un ethos de código abierto impulsa la innovación.

Historia de los medios de comunicación social descentralizados y alternativos

Antes de que la web se convirtiera en un centro de comercio, entretenimiento e interacciones sociales, era principalmente una herramienta académica y militar. Tim Berners-Lee tenía una visión igualitaria cuando formuló los primeros protocolos web: el diseño inicial de internet era ser una red descentralizada, donde la información pudiera fluir libremente entre nodos sin ningún punto de control o fallo único.

Sin embargo, a medida que la web crecía en importancia comercial, plataformas centralizadas, como los motores de búsqueda y los gigantes de las redes sociales, surgieron como actores dominantes. Si bien estas entidades aportaban un valor significativo, se desviaron del ethos descentralizado original, lo que resultó en nuestro entorno web2 actual.

La innovación clave en la línea de tiempo de las redes sociales alternativas fue la llegada del concepto de protocolos federados. Una red federada se refiere a un sistema donde múltiples servidores independientes o nodos cooperan para formar una sola red social, en contraposición a las plataformas centralizadas donde una sola organización controla todos los servidores.

En un sistema federado, cada servidor ejecuta software compatible que sigue protocolos compartidos, lo que les permite comunicarse entre sí. Un usuario registrado en un servidor puede seguir, interactuar y compartir contenido con usuarios de otros servidores de manera transparente, como si estuvieran en la misma plataforma. Ejemplos de estos protocolos incluyen ActivityPub y OStatus, que alimentan plataformas federadas como Mastodon y PeerTube.

En una configuración federada, los usuarios pueden elegir en qué servidor confían, migrando potencialmente a diferentes servidores o configurando el suyo propio, lo que les brinda más autonomía. El término 'Fediverse' -un acrónimo de 'federación' y 'universo'- se utiliza para describir dicho sistema. El Fediverso comenzó con plataformas como GNU social y sus predecesores (StatusNet y Laconica), pero el punto de inflexión real fue el desarrollo y la adopción generalizada del protocolo ActivityPub, que fue publicado como un estándar recomendado por el Consorcio World Wide Web (W3C) en 2018.

Dentro de web3, las redes sociales federadas son el estado predeterminado de los sistemas descentralizados una vez que los datos se trasladan a la cadena. Las blockchains actúan como un servidor backend sin opiniones para el contenido almacenado, con interfaces que indexan este contenido y lo sirven directamente a los usuarios. La identidad está gestionada por pares de claves público-privadas que ya gestionan las carteras de los usuarios, lo que les permite autenticar fácilmente cualquier dato o contenido que generen. Además, el uso de primitivas en la cadena como NFT puede agrupar contenido almacenado en los metadatos y actuar como un nombre de dominio o identificador descentralizado (DID).

Similar to how ActivityPub works, los protocolos web3 buscan iniciar grafos sociales a través de relaciones autenticadas entre nodos de usuarios. Dado que cualquier frontend puede indexar y servir este contenido, existe una hipercompetencia en la capa de frontend que resulta en un próspero panorama de funcionalidades. Además, debido a que los datos están en la cadena, los usuarios pueden elegir los algoritmos que les resulten cómodos y pueden recibir incentivos para usar ciertos algoritmos, recuperando así el valor de sus datos. Esto se combina con medios más directos de monetizar su contenido, lo que brinda una experiencia general mejor para los creadores, que en gran medida han quedado al margen de la monetización a pesar de que su contenido es lo que impulsa la demanda de estas plataformas.

Comparación de Protocolos

Para apreciar verdaderamente las innovaciones dentro de los protocolos de redes sociales descentralizadas, es necesario comprender las sutilezas técnicas que los habilitan. Es importante destacar que no estamos incluyendo todos los protocolos sociales aquí, sino que optamos por algunos de los más prevalentes:

Identidad / Espacios de nombres

En el contexto de gráficos sociales federados y descentralizados o protocolos de red, un 'namespace' se refiere a un dominio o ámbito bajo el cual los identificadores de usuario u otros recursos son únicos. Es una forma de distinguir recursos o identidades de un dominio/servidor de otro, asegurando que no haya conflictos o ambigüedades al integrar o comunicarse a través de múltiples dominios.

La identidad y los espacios de nombres asociados en los protocolos sociales descentralizados abarcan toda la gama, desde pares de claves simples (Nostr, Scuttlebutt) hasta URI apuntando a HTTP, URL que alojan perfiles (ActivityPub) y modelos más complejos que utilizan primitivas en cadena como NFT (y, más recientemente, extensiones ERC-6551, por ejemplo, Lens v2).

Farcaster es un gran ejemplo de estas técnicas. Una cuenta de Farcaster representa una entidad distinta en la red. Cada cuenta tiene un identificador numérico único llamado Farcaster ID (“fid”). Las identidades se emiten y gestionan en la cadena utilizando un contrato de Ethereum llamado IdRegistry. Los usuarios realizan una transacción a la IdRegistry para obtener un nuevo fid. La dirección que posee el fid es la dirección de custodia del usuario. La IdRegistry garantiza que los fids se puedan transferir entre direcciones y que ninguna de las direcciones tenga el mismo fid. Farcaster también extiende este espacio de nombres para admitir nombres ENS que se emiten en la cadena o fuera de ella. Se debe enviar una prueba firmada a la red para reclamar un nombre de usuario.

ActivityPub, por otro lado, identifica a cada usuario con un URI único, típicamente una URL HTTPS. Este URI apunta al perfil del usuario y sirve como su identificador global en el Fediverso. Para hacer que estos URIs sean más amigables para el usuario, muchas plataformas de ActivityPub utilizan un sistema llamado Webfinger. Webfinger permite a los usuarios tener una identidad como '@'username@domain.com’.

Lens y CyberConnect en su lugar administran los perfiles de usuario como NFT. En el caso de Lens, una dirección de usuario tiene un ProfileNFT, y es posible que una sola dirección tenga múltiples ProfileNFTs. Cada Profile NFT encapsula toda la historia de la actividad de un usuario, incluidas publicaciones, espejos, comentarios y otros tipos de contenido que han creado. Además, los Profile NFTs tienen un FollowModule, que es esencialmente un conjunto de reglas que gobiernan cómo diferentes cuentas pueden obtener Follow NFTs. Estos Follow NFTs sirven para documentar las conexiones entre cuentas y el perfil principal directamente en la cadena. También hay identificadores que pueden existir y pueden acuñarse por separado de los perfiles, y pueden estar vinculados o desvinculados de un perfil a otro. Los identificadores existen en sus propios espacios de nombres (por ejemplo, lente/@alice).

Datos

Los datos son probablemente la característica más importante de las redes descentralizadas, ya que su creación y estandarización es lo que permite estos sistemas. La técnica más común para gestionar datos aquí es el uso de formatos estandarizados como JSON y objetos de relación comunes (por ejemplo, me gusta, seguidores). Los objetos de datos principales suelen incluir:

Actores y objetos: Define "actores" (por ejemplo, usuarios o grupos) y "objetos" (por ejemplo, publicaciones o mensajes).

Publicaciones: Las publicaciones o comentarios se encapsulan como “Publicaciones”, a menudo vinculadas a contenido externo a través de URL.

Contenido en Registros de Solo Append: Registros en los que cada entrada, ya sea una publicación o actualización, es un elemento de contenido discreto, agregado y almacenado secuencialmente.

Sumerjámonos en un par de ejemplos de cómo funciona esto utilizando protocolos específicos.

ActivityPub utiliza el formato de datos ActivityStreams 2.0, una estructura basada en JSON, para representar varias interacciones sociales como publicaciones o 'me gusta'. El protocolo diferencia entre dos componentes principales: Cliente a Servidor (C2S) y Servidor a Servidor (S2S). C2S permite a los usuarios, a través de aplicaciones de cliente, interactuar con sus respectivos servidores. En contraste, S2S facilita la comunicación entre servidores, lo que permite la naturaleza federada robusta del protocolo.

Dentro de ActivityPub, las entidades se categorizan como "actores" (a menudo cuentas de usuarios o grupos) y "objetos" (contenido o acciones como publicaciones o me gusta). Cuando un actor realiza una acción sobre un objeto, crea una "actividad" como "Crear", "Seguir" o "Me gusta".

Las redes sociales Web3 adoptan muchas de las ideas fundamentales de ActivityPub pero las aplican en cadena. Lens Protocol, por ejemplo, introduce las “Publications,” que encapsulan una variedad de contenido generado por el usuario como publicaciones, espejos, comentarios y otras formas de medios. Cada Publicación está asociada con un ContentURI, que dirige al contenido específico almacenado en un protocolo descentralizado como IPFS o Arweave, o alternativamente, en un servicio de almacenamiento centralizado como AWS S3. Esta configuración garantiza que el perfil de un usuario y todas las publicaciones asociadas se almacenan de forma segura en su billetera personal, alejándose de la dependencia de bases de datos centralizadas.

Además, Web3 permite un enfoque más sencillo para monetizar el contenido y la influencia de los usuarios en comparación con el marco de Web2. Los usuarios pueden cobrar por la creación de Follow NFTs, o pueden integrar Módulos de Colección con sus Publicaciones. Esta última opción les permite recibir una tarifa por la creación de NFTs vinculados al ContentURI de su publicación. Además de estas características, Lens Protocol ofrece una API de GraphQL, que sirve para enmascarar los componentes de la cadena de bloques de las interfaces frontales y, en consecuencia, ofrece una experiencia más amigable para el usuario que los intentos anteriores de redes sociales descentralizadas.

En última instancia, muchos de los protocolos de redes sociales descentralizadas crean estructuras de datos de solo anexión que son autenticadas por claves de usuario. Por ejemplo, en CyberConnect, cada pieza de datos centrados en el usuario se representa como un flujo de datos donde las actualizaciones solo son permitidas por el propietario de los datos. Cada actualización de los datos se añade al flujo de datos en forma de un registro de confirmación de solo anexión y la estructura de datos resultante se convierte en una estructura de datos vinculados por hash llamada un DAG de Merkle. Los tipos de datos incluyen contenido, colecciones, comentarios y suscripciones.

Scuttlebutt utiliza de manera similar un registro de solo agregados. Cada usuario tiene su propio registro donde cada nuevo mensaje o acción se agrega al final después de ser firmado por la identidad del usuario (es decir, el par de claves Ed25519 asociado). También admite el intercambio de datos binarios, denominados “blobs”. Estos pueden ser imágenes, videos u otro contenido binario. Los blobs se almacenan por separado de los registros de solo agregados, pero las referencias (hashes) a estos blobs se pueden incluir en los registros.

Para Farcaster, los mensajes son actualizaciones públicas como hacer una publicación, seguir a alguien o agregar una foto de perfil, y estos mensajes se codifican como un protobuf y deben ser hasheados y firmados por el firmante de la cuenta. Los usuarios pueden publicar mensajes en los Hubs siempre que tengan suficiente almacenamiento. Los Hubs verifican la validez de los firmantes de cada mensaje antes de aceptarlos.

Almacenamiento

Los enfoques iniciales para el almacenamiento de datos para protocolos descentralizados eran en su mayoría fuera de la cadena, aunque recordaban al consenso en la cadena. Scuttlebutt, por ejemplo, utiliza una red de chismes entre pares, poniendo la responsabilidad del almacenamiento en el dispositivo local del usuario. Este enfoque garantiza la soberanía de los datos, ya que los usuarios tienen un control completo sobre su propia información. Sin embargo, también significa que la disponibilidad de los datos depende de que el dispositivo del usuario esté en línea o de que otros pares en la red tengan una copia de los datos. Con el tiempo, para gestionar el espacio de almacenamiento, algunos clientes de Scuttlebutt podrían necesitar implementar estrategias de recolección de basura para podar datos antiguos o menos relevantes.

Una alternativa a este enfoque peer-to-peer viene en forma de servidores que almacenan datos, aunque con redundancia en comparación con las plataformas de medios tradicionales. Matrix, por ejemplo, tiene múltiples homeservers que almacenan copias de historias de salas y se sincronizan entre sí. Cuando un usuario envía un mensaje (o cualquier evento) en una sala, su homeserver transmite ese evento a otros homeservers participantes, que luego almacenan y reenvían el evento a sus clientes conectados. De manera similar, ActivityPub hace que cada instancia (o servidor) en la red almacene sus datos, típicamente en una base de datos. La elección de la base de datos (relacional, NoSQL, etc.) depende de la implementación específica del software ActivityPub. Por ejemplo, Mastodon, una plataforma popular de ActivityPub, utiliza una base de datos PostgreSQL.

Protocolos como Cyberconnect, Farcaster y Lens han adoptado blockchains para el almacenamiento. El uso de almacenamiento en cadena garantiza que los datos sean inmutables y verificables, proporcionando una base sólida para aplicaciones descentralizadas que utilizan mecanismos de consenso subyacentes para sincronizar estados. Sin embargo, este enfoque puede plantear desafíos de escalabilidad, ya que cada dato debe almacenarse en cadena, lo que potencialmente conlleva altas tarifas de transacción y tiempos de recuperación más lentos.

Esto ha llevado a muchos protocolos sociales web3 a experimentar con enfoques híbridos que utilizan almacenamiento en cadena para acciones menos frecuentes (por ejemplo, perfiles, suscripciones) y almacenamiento fuera de la cadena para eventos de alta frecuencia (por ejemplo, me gusta, reposts, comentarios) o cargar datos en cadena en intervalos frecuentes con almacenamiento fuera de la cadena utilizado como solución provisional.

CyberConnect, para manejar eficientemente las actualizaciones frecuentes entre las conexiones de usuario, emplea una lista hash enlazada en una tienda de datos descentralizada. Al iniciar una conexión, se crea un 'registro de operaciones'. Los cambios de estado posteriores, como alternar entre seguir y dejar de seguir, se agregan como nuevos nodos a este registro. Si bien estas actualizaciones se almacenan inicialmente en un servidor central, se cargan periódicamente en lotes a plataformas de almacenamiento descentralizadas como Arweave o IPFS. Para una rápida recuperación de datos, los nodos en el registro de operaciones se almacenan de forma centralizada. Sin embargo, los usuarios pueden verificar de forma independiente la integridad de los datos navegando a través de esta lista hash enlazada. Incluso con la dependencia de un servidor central para algunas consultas de datos, el sistema de CyberConnect está diseñado para ser suficientemente descentralizado y ofrecer un alto rendimiento.

Farcaster utiliza un enfoque híbrido de manera similar: los contratos onchain se utilizan para acciones poco frecuentes donde la consistencia y la descentralización son importantes. Las cuentas, nombres de usuario, almacenamiento y claves se gestionan mediante una serie de contratos de Ethereum. Los sistemas offchain se utilizan para acciones frecuentes donde el rendimiento es crítico. Los mensajes creados por las cuentas de usuario se almacenan y se propagan en la red peer-to-peer de los centros de Farcaster.

Discusión

Los protocolos sociales descentralizados están listos para revolucionar la experiencia del usuario en las interacciones digitales. La adopción acelerada de pares de claves público-privadas, impulsada tanto por la tracción web3 como como una medida proactiva contra el contenido generado por IA, facilitará una comprensión más amplia y familiaridad con los primitivos de identidad en este contexto, y la moderación continua y la captura de datos en las compañías de redes sociales web2 empujarán abiertamente a más usuarios a buscar en otro lugar. Esperamos una curva de adopción acelerada para estos protocolos.

Para fomentar la evolución de aplicaciones novedosas, existe una necesidad apremiante de que los desarrolladores de protocolos y los contribuyentes de código abierto se aventuren más allá de los tipos de datos básicos y los objetos de relación actualmente empleados en la capa de infraestructura. Si bien los primitivos existentes encapsulan adecuadamente las funcionalidades de las redes sociales web2 convencionales, existe un inmenso potencial de expansión e innovación. La mayoría de los protocolos discutidos aquí admiten inherentemente la extensibilidad dentro de sus sistemas, proporcionando una base sólida para futuros desarrollos y contribuciones de código abierto.

Sin embargo, es crucial subrayar la importancia de la interoperabilidad. Si bien los desarrolladores de frontend son capaces de aumentar la funcionalidad de forma independiente, hacerlo podría restarle valor a los beneficios colectivos del sistema si las mejoras no son interoperables con otras aplicaciones construidas sobre el mismo protocolo subyacente. Garantizar la compatibilidad y la integración sin problemas entre diversas aplicaciones es vital para el éxito a largo plazo y la adopción de protocolos sociales descentralizados.

En el ámbito del almacenamiento de datos, el consenso emergente dentro de los protocolos sociales web3 tiende hacia un enfoque híbrido. Dada la alta cantidad de contenido social y participación, es pragmático asignar activos de alto valor como la identidad y el contenido principal a primitivas on-chain, mientras se relega el contenido de menor riesgo como los likes y reacciones a soluciones off-chain. Este enfoque equilibrado no solo preserva la integridad y seguridad de datos cruciales, sino que también proporciona una experiencia de usuario reminiscente de plataformas de redes sociales tradicionales.

Descargo de responsabilidad：

1. Este artículo se reimprime de [Gateespejo]. Todos los derechos de autor pertenecen al autor original [1kx]. If there are objections to this reprint, please contact the Aprendizaje de la puertaequipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.