Un sistema de archivos social

• Amplía el concepto de computación personal centrada en archivos hacia la computación social, describiendo una estructura en la que todo el contenido creado por el usuario le pertenece a él, no a las apps
• Basado en el protocolo AT, propone el concepto de un sistema de archivos social descentralizado que permite la interoperabilidad de datos entre apps
• Cada usuario tiene su propia ‘everything folder’ o repositorio (repository), donde publicaciones, Me gusta y seguimientos se almacenan como archivos (records) basados en JSON
• Mediante DID (Decentralized Identifier) y el esquema de URI at://, mantiene enlaces identificables de forma permanente incluso si cambia el hosting o el handle
• Esta estructura forma un ecosistema social centrado en los datos, no en las apps, permitiendo que cualquiera cree nuevas apps que funcionen sobre los datos existentes

---

El paradigma de archivos y su expansión social

• Originalmente, los archivos existen en un espacio controlado por el usuario, no dentro de una app, y las apps solo cumplen el rol de herramientas para leer y escribir archivos
  • Formatos de archivo abiertos como .svg permiten que varias apps compartan los mismos datos
  • Bajo el principio de que “el formato de archivo es la API”, es posible la interoperabilidad entre apps
• Si este concepto se aplica a las apps sociales, acciones como publicaciones, seguimientos y Me gusta también pueden tratarse como archivos
  • Existe una ‘everything folder’ que contiene toda la actividad en línea del usuario
  • Las apps reflejan los datos de esa carpeta, y la carpeta cumple el papel de única fuente de verdad (source of truth)

El protocolo AT y el sistema de archivos social

• El protocolo AT es la tecnología que implementa esta estructura en la práctica, y Bluesky, Leaflet, Tangled, Semble y Wisp funcionan sobre esta base
• Las apps no son dueñas de los datos del usuario, y gracias a un almacenamiento de datos separado a nivel de archivo, las nuevas apps pueden reutilizar los datos existentes
• Las carpetas de todos los usuarios juntas forman un sistema de archivos social descentralizado

Estructura de records y colecciones

• Cada publicación se representa como un archivo JSON (record) y no incluye información del autor ni datos derivados, como la cantidad de Me gusta
  • Ejemplo: { text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }
• El nombre del archivo se genera con una clave de record basada en timestamp (record key) para evitar colisiones
• La estructura del archivo se define mediante un esquema llamado lexicon, y cada app puede diseñar su propio lexicon
  • Ejemplos: com.twitter.post, fm.last.scrobble, io.letterboxd.review
• Incluso para el mismo concepto, cada app puede tener un lexicon distinto, y las colisiones se evitan con namespaces basados en dominios

Validación y confianza

• No existe una Lexicon Police: ninguna app puede imponer sus datos a otras apps
  • Las apps validan los datos al leerlos (validate on read) y, si no son válidos, los ignoran
• Cuando cambia un lexicon, es obligatorio mantener compatibilidad hacia atrás, y los cambios incompatibles se separan en un nuevo lexicon
• Los lexicon pueden publicarse abiertamente y permiten demostrar propiedad del dominio mediante DNS

Enlaces e identidad (Identity)

• Los ‘Me gusta’ o las ‘respuestas’ creados por el usuario deben referenciar otros records, por lo que se necesita un sistema de enlaces permanente
• Tras varios intentos, se estableció la identidad usando DID (Decentralized Identifier)
  • Un identificador como did:plc:6wpkkitfdkgthatfvspcfmjo no puede modificarse
  • Cada DID se resuelve a un documento que contiene la información actual de hosting, handle y clave pública
• El URI at:// combina DID, colección y clave de record para ofrecer enlaces que no se rompen aunque cambie el hosting
  • Ejemplo: at://did:plc:6wpkkitfdkgthatfvspcfmjo/com.twitter.post/34qye3wows2c5

Hipervínculos JSON y expresión de relaciones

• Cada ‘Me gusta’, ‘repost’ y ‘respuesta’ tiene una estructura de JSON con hipervínculos que referencia otros records
  • Ejemplo: el campo parent referencia el URI at:// de otra publicación
• Toda la información de la UI —autor, texto, cantidad de Me gusta, etc.— puede calcularse a partir de estas conexiones entre archivos

Repositorio (Repository) y flujo de datos

• La ‘everything folder’ del usuario se llama repositorio (repository) y se identifica mediante un DID
  • En su interior hay varias colecciones (collection) y records (record)
• El repositorio puede alojarse en cualquier lugar, y los enlaces se conservan aunque se mueva
• Las apps pueden leer el repositorio como si fuera un sistema de archivos o suscribirse por stream (WebSocket) para sincronización en tiempo real
  • Cada commit se verifica mediante un árbol hash firmado (Merkle tree) para evitar la falsificación de datos
  • Los servidores de relay simplemente retransmiten eventos, y la confianza se obtiene gracias a una estructura verificable

Exploración de Atmosphere y casos reales

• pdsls.dev funciona como un explorador del sistema de archivos social al ingresar un DID o handle
  • Permite consultar directamente cada colección y record
• La app de ejemplo Sidetrail refleja en tiempo real los cambios en los records del usuario y muestra que los datos existen en el repositorio, no en la app
• La demo de teal.fm Relay visualiza el historial de reproducción musical (scrobble) indexando records fm.teal.alpha.feed.play, incluso sin una API real
  • Con la herramienta lex-gql, es posible ejecutar consultas GraphQL basadas en Lexicon
• En Bluesky, los usuarios pueden publicar directamente algoritmos de feed personalizados
  • Ejemplo: el feed “For You” de @spacecowboy17.bsky.social funciona de manera independiente, lo que permite que terceros mejoren funciones sobre datos compartidos

Conclusión

• El sistema de archivos social propone una estructura de internet centrada en los datos, no en las apps
• El usuario es dueño de su repositorio de datos, y las apps reaccionan sobre él
• El objetivo es pasar de “una app que lo hace todo” a “un ecosistema donde todo es posible”

[GN⁺]

Comentarios en Hacker News

• Las apps pueden desaparecer, pero los archivos permanecen
  El texto de swyx enfatiza que el trabajo que perdura termina existiendo en forma de archivos/datos
  Los datos pueden parsearse sin permisos y, aunque se dañen parcialmente, siguen siendo útiles, pero los incentivos económicos todavía giran alrededor del código
  Si surgen estándares que hagan que el código acepte y exporte datos, eso generaría un enorme valor para toda la civilización
  Creo que uno de los palancas más poderosas que tenemos es lograr que el ecosistema de desarrolladores incentive a empresas como Google, Microsoft, OpenAI y Anthropic a participar voluntariamente en la estandarización de datos

  • Coincido con la idea de que “los archivos son la fuente de la verdad”
    Pero las apps actuales tienen forma de sitios web que dependen de ingresos por publicidad, así que no tienen ningún incentivo para funcionar de esa manera
  • Darle a Google, MS, OpenAI o Anthropic lo que quieren no significa necesariamente que vaya a haber una recompensa a cambio
    Basta ver a Apple para notar que muchas veces los estándares no cambian el mundo
  • Me alegra :) Nunca había escuchado la “ley de la indirección”, pero es un concepto bastante interesante

• Si el campo createdAt es arbitrario, ¿no podría modificar retroactivamente un registro como yo quiera?
  Me pregunto si hay alguna forma de verificar mediante firmas (signing) el momento de creación y si hubo modificaciones posteriores

• POSSE y AT Protocol pueden entenderse como marketplaces interoperables
  Como en Reddit o Instagram, el contenido del usuario es el producto, la atención es la moneda y la plataforma obtiene ingresos mediante anuncios o datos de comportamiento
  Pero esa estructura no es inevitable.
  Si el usuario tiene la propiedad de sus datos sociales, la app pasa a ser una interfaz que lee esos datos
  Yo también estoy aplicando un modelo parecido al comercio: el vendedor aloja por su cuenta la lógica de pedidos y pagos, y el marketplace se integra directamente con la API del vendedor
  Así se reducen las comisiones de plataforma y se devuelve la propiedad a quien crea el valor

  • Vi openship en tu perfil y me dio curiosidad; voy a revisarlo yo mismo

• El texto era tan detallado que se sentía algo excesivo para transmitir la idea central
  Aun así, la analogía es excelente. Si hubiera un navegador de archivos para PDS, se podría experimentar directamente
  El PDS de Bluesky es básicamente un sistema de archivos público, y como en Git, la replicación forma parte del diseño
  La replicación no se puede controlar, pero también tiene la ventaja del respaldo automático
  Al final, lo que subes al PDS queda como un registro permanente, así que hay que tener cuidado

  • Mi objetivo al escribir es trasladar tal cual la estructura que tengo en la cabeza
    Si es útil pero largo, otras personas pueden tomar solo las partes que necesiten
    En la sección de demo al final del texto se puede ver un ejemplo real de un administrador de archivos
    La expresión “un mundo donde todos se vuelven scrapers” captura la esencia
  • Con pdsfs puedes montar un PDS localmente como solo lectura mediante FUSE
  • pdsls.dev cumple muy bien ese papel. Es una app completamente del lado del cliente y además es open source
  • Me pregunto en qué estado está el cifrado de atproto. ¿Bastaría con publicar datos cifrados simplemente con sha256?
  • ATProto todavía no es un protocolo terminado, y pronto también se añadirá soporte para datos privados

• Creo que el concepto de “archivo” ya está anticuado
  Si todo se tratara como datos blob basados en hash, muchos problemas desaparecerían
  Lo que el usuario quiere no es una app, sino una capacidad
  Por ejemplo, “poder ver videos de yoga” o “poder compartir novedades con conocidos”, no YouTube o Bluesky en sí
  Las apps no son más que una forma de agrupar esas capacidades
  Se necesitan flujos de trabajo personalizados, como buscar una palabra en una app de mensajería y compartir el resultado directamente dentro de la conversación
  Me inspiré en PerKeep

  • El sistema de archivos es una expresión metafórica
    Lo usé como metáfora para explicar la “relación de muchos a muchos entre apps y formatos de archivo”
    Si miras la explicación de la estructura del repositorio de ATProto, verás que se basa en una estructura direccionada por contenido con Merkle-tree
    Como Lexicon no tiene una relación 1:1 con una app, AT ya se está moviendo hacia una era post-app

• Creo que los jardines amurallados son el resultado de la preferencia de los consumidores
  Cuando internet lo abrió todo, la gente empezó a querer espacios pequeños centrados en ciertas culturas o ideas
  IG o Snap son como esos chats grupales más segmentados
  De hecho, prefiero que mis publicaciones de IG no se compartan automáticamente en HN o Truth Social
  No termino de ver el valor de la portabilidad de datos. Siento que cruzar entre plataformas con contextos distintos no tiene mucho sentido

  • Las apps de ATProto no comparten automáticamente todos los “archivos” por defecto
    Anisota, que hice yo, fue diseñada para soportar tanto archivos de Bluesky como de Leaflet
    Por ejemplo, puedes ver la misma publicación tanto en Bluesky como en Anisota
    Además, con un proyecto llamado Aturi ofrezco enlaces universales para contenido basado en ATProto
  • Cuando Twitter fue adquirido, me habría gustado poder mover intactos mi identidad, mis publicaciones, mis likes y mi grafo social
    En ATProto, si son apps que usan el mismo Lexicon, es posible una migración completa de identidad y datos
  • Yo tampoco termino de entender la necesidad de la portabilidad de datos
    Las imágenes originales están en mi equipo local, y cada plataforma no es más que una representación distinta
    No quiero una integración sin sentido entre plataformas
  • Si Truth Social no hubiera eliminado el código de federación (federation code), habrían aparecido tal cual las publicaciones hechas desde Mastodon y otros servicios
  • Es bueno que distintas apps mantengan cada una su propio “ambiente”
    AT solo hace posible la interoperabilidad, no unifica todo
    Por ejemplo, Leaflet toma publicaciones de Bluesky y las muestra para rastrear citas
    Gracias a esta estructura, aunque hagas un fork del producto, sigue siendo totalmente compatible con la red, lo que fomenta la competencia
    De hecho, Blacksky es un caso en el que se hizo un fork de Bluesky para aplicar una política de moderación distinta

• Los textos que escribe Dan siempre son interesantes. Cuando los lees, tarde o temprano te das cuenta de que él era el autor

  • Gracias :)

• Soy escéptico respecto al modelo de datos autodescriptivo
  La afirmación de ATProto de que “si agregas un Lexicon, aparece un cliente” me parece exagerada
  En la práctica, para construir una UI hay que entender el significado de los datos, y con el Lexicon solo no alcanza
  Al final no es tan distinto de leer documentación e implementarlo manualmente
  La estandarización está bien, pero no es necesariamente un problema que requiera una base de datos replicada a nivel mundial
  Aun así, valoro el intento de reducir el lock-in
  Pero el verdadero problema que tuvo Twitter fueron factores sociales como el contenido político o el spam

  • El ejemplo que diste es simplemente un caso donde no existe cliente porque a nadie le interesa
    Pero si desaparece un servicio querido como Bento, alguien intentará restaurar esos datos
    Por ejemplo, Blento es una alternativa a Bento basada en ATProto que cualquiera puede volver a levantar porque es open source
    Este tipo de estructura representa un avance importante para garantizar la persistencia del contenido de los usuarios

• Leyendo “The Unix Programming Environment”, me di cuenta de que se puede hacer muchísimo con herramientas simples y archivos de texto
  Me hace imaginar cómo sería Slack si hubiera sido construido con un estilo UNIX centrado en archivos
  Quiero volver a sistemas simples y componibles

  • Unix dio ideas de arquitectura excelentes, pero tenía la limitación de tratar todos los datos como texto plano
    Una serialización fácil de leer por humanos está bien, pero tener que parsear y reformatear todo cada vez es doloroso

• La idea de que nuevas plataformas sociales compartan protocolos y formatos de datos comunes en un entorno distribuido y federado es interesante
  Pero parece difícil convencer a las plataformas comerciales existentes
  Si estos estándares se consolidan, a las herramientas de marketing social les resultará más fácil gestionar varias redes de forma integrada
  Pero la realidad es que siguen dominando ecosistemas cerrados como Facebook, Instagram y TikTok