Social abierto

• Así como el código abierto se convirtió en el estándar de la infraestructura de software, también está surgiendo en las apps sociales el paradigma de “social abierto”
• El AT Protocol permite que los usuarios posean y controlen directamente sus datos sociales, presentando un concepto distinto al de las plataformas sociales tradicionales
• Los datos sociales ya no quedan encerrados dentro de un servicio específico, sino que se almacenan en repositorios personales administrados por el propio usuario
• Esto hace posible la reutilización y el remix de datos entre apps, y permite que los datos persistan sin desaparecer incluso si un servicio cierra
• Con la expansión del social abierto, se espera que la propiedad de los datos impulsada por el usuario y la escalabilidad flexible emerjan como valores clave

---

Introducción: el éxito del código abierto y una nueva tendencia

• El código abierto logró consolidarse hoy como la base de la infraestructura común, pese a la mucha resistencia que enfrentó en el pasado
• A diferencia de antes, hoy elegir código abierto ya no representa un problema, y en áreas importantes del software el código abierto se ha establecido como la opción por defecto
• Ahora estamos frente a un punto de inflexión en el campo de las apps sociales, similar al del código abierto hace 35 años
• Ha surgido la nueva corriente del “social abierto”, y el AT Protocol de Bluesky es considerado su implementación más convincente

La estructura básica de la web y la propiedad de los datos personales

• En la web del pasado existían direcciones personales como alice.com y bob.com, y cada usuario era dueño de su propio espacio, donde podía publicar libremente su contenido
• Si no te gustaba el hosting, podías mudarte a otro lugar y la dirección seguía siendo la misma, sin romper los enlaces existentes
• Gracias a esto, los usuarios no quedaban atados a un proveedor de hosting específico, y los proveedores tenían que competir
• En otras palabras, gracias al diseño descentralizado de la web, el usuario controlaba los datos y las empresas eran simples proveedoras

Redes sociales modernas: la pérdida de la propiedad de los datos

• Hoy, en lugar de administrar su propio sitio, la mayoría de la gente recibe identificadores como @alice o @bob dados por una empresa y publica en apps de redes sociales
• Los datos como publicaciones, comentarios y “me gusta” se almacenan en la base de datos de una empresa social específica
• Gracias a esta estructura surgieron funciones de agregación social como búsqueda, feed, recomendaciones y notificaciones
• Sin embargo, también apareció el efecto secundario de que los datos centrales dejan de pertenecernos
• Los usuarios quedan en una situación donde no pueden llevarse libremente los datos y relaciones que ellos mismos crearon

El problema: usuarios atrapados en la plataforma

• Si un usuario se va, tiene que dejar atrás toda la red de conexiones que construyó
• No puede cambiar fácilmente de proveedor de hosting, y al abandonar la plataforma pierde también sus conexiones y sus datos
• Como las plataformas saben esto, los usuarios terminan soportando cambios desfavorables para ellos (exceso de anuncios, distorsión algorítmica, eliminación de funciones, etc.)
• Incluso si hacen una copia de seguridad o exportan sus datos, eso no pasa de ser “datos muertos” sin contexto social, difíciles de revivir en otro lugar

Social abierto: recuperar la propiedad de los datos y la red

• En el social abierto, mediante handles basados en dominios como @alice.com, se otorga al usuario la propiedad efectiva de sus datos sociales
  • El nombre se vincula con un dominio que poseo, como @alice.com
• El usuario administra directamente todos los datos sociales que genera mediante un repositorio personal (repository)
  • Actividades como publicaciones, comentarios y follows se registran en el repositorio personal (repo)
  • El repositorio es simplemente un servidor web que guarda registros en formato JSON
  • La dirección tiene la forma at://alice.com/..., por lo que puede enlazarse con otras
• Los repositorios basados en AT Protocol funcionan sobre DNS, HTTP y JSON, y cada dato se almacena como JSON enlazado por hipervínculos
• Incluso para quienes no conocen la tecnología, al registrarse en una app se crea automáticamente un repositorio, por lo que los datos siguen siendo propiedad del usuario independientemente de la app
• Los datos pertenecen al repositorio del usuario, y aunque cambie el proveedor del servicio, se mantienen la propiedad de los datos y la conectividad

Estructura y aplicaciones de las apps de social abierto

• Cada app de social abierto gestiona parte del repositorio social del usuario como si fuera un CMS, y ahora la app no es más que una herramienta para leer y escribir en el repositorio del usuario
• Por ejemplo, datos de distintas apps como Bluesky, Tangled y Leaflet pueden coexistir en el repositorio de un mismo usuario
  • Si escribo una publicación en Bluesky, queda registrada en mi repositorio, y si marco un proyecto con estrella en Tangled, eso también entra en mi repositorio
  • Los formatos de datos se separan con namespaces (por ejemplo, app.bsky.post, sh.tangled.star, etc.) para evitar conflictos
  • Con el tiempo, mi repositorio se convierte en una colección de datos reunidos desde varias apps

Cambios en el ecosistema que trae la apertura de los datos

• Como los datos se almacenan de forma abierta, resulta más fácil la integración entre apps, el desarrollo de nuevos servicios y la referencia, reutilización y remix libre de los datos de otros
• Aunque una app cierre, los datos permanecen en el repositorio del usuario y pueden reutilizarse en otros servicios
• Las apps nuevas pueden aprovechar las relaciones y datos de la red existente para superar el “cold start” (el problema de construir una red inicial)
• Como estos datos pueden ser leídos por cualquiera, otra app puede tomarlos para cargar la foto de perfil o reutilizar tal cual las relaciones de seguimiento existentes
• Aunque una app cierre, los datos permanecen en el repositorio del usuario y otras apps pueden volver a sacarlos y usarlos

Agregación y desafíos técnicos

• Aunque los datos de los usuarios están distribuidos en repositorios separados, se recibe un stream de eventos de cambios de datos mediante suscripciones WebSocket y se refleja en una base de datos local
• A través de grandes relays (servidores intermediarios) se reciben los eventos de toda la red y se filtran solo los necesarios
• Los registros de datos están firmados criptográficamente, garantizando confiabilidad y consistencia
• Infraestructuras como Graze y Slices apoyan la agregación en el social abierto

¿Y cómo funcionan las capacidades de agregación?

• Aunque el repositorio de cada usuario existe por separado, la app recibe el stream de eventos en tiempo real que sale de los repositorios de los usuarios y lo registra en su propia base de datos
• Un servidor intermediario (relay) como Bluesky reúne y entrega el stream completo, y la app guarda solo los eventos que le interesan
• La base de datos construida de esta manera puede ofrecer rápidamente funciones como búsqueda, feed y recomendaciones
• Los registros de datos están firmados criptográficamente, garantizando confiabilidad y consistencia: aun sin confiar en el intermediario, se puede verificar la autenticidad de los datos
• Infraestructuras como Graze y Slices apoyan la agregación en el social abierto

Panorama general

• Web del pasado: el usuario controlaba su propio contenido y su dirección
• Apps sociales de hoy: tienen funciones de agregación, pero los datos quedan atados a bases de datos propiedad de empresas
• Social abierto: mantiene las funciones de agregación, pero los datos siguen en manos del usuario
• Las apps pasan a ser simplemente una ventana que reúne y muestra los datos del usuario
• Aunque el servicio desaparezca, los datos permanecen y otra app puede volver a mostrarlos en un nuevo contexto

Conclusión

• La clave del social abierto es combinar las ventajas de la web personal (propiedad de los datos, libertad de hosting, permanencia de enlaces) con las fortalezas de las redes sociales cerradas (agregación y escalabilidad)
• El social abierto garantiza propiedad de los datos impulsada por el usuario, libre portabilidad de datos entre apps y continuidad del servicio
  • Así como el código abierto decía que “el código debe pertenecer al usuario”, también “los datos deben pertenecer al usuario”
  • Resuelve el problema de que los usuarios pierdan sus datos y su conectividad en plataformas cerradas
• Si aparecen más productos de social abierto, las fronteras entre apps se volverán difusas y el ecosistema evolucionará hacia uno donde los datos fluyan de manera natural
  • En última instancia, podría llegar un futuro donde el usuario controle de forma efectiva sus datos y su red
• Al principio lo impulsarán unos pocos desarrolladores y usuarios entusiastas, pero si la base compartida sigue creciendo, existe una alta probabilidad de que eventualmente el enfoque abierto gane
  • Incluso sin conocer conceptos técnicos como descentralización o federación, se pueden percibir beneficios concretos (interoperabilidad de datos, migración sencilla y persistencia)
  • El social abierto se expandirá gradualmente gracias a un esfuerzo comunitario apasionado y a efectos acumulativos de largo plazo

[shakespeares]

Instagram también es un lugar para guardar recuerdos, pero parece que no es fácil irse cuando uno quiere.
También da la impresión de que, en cuanto a compartir y usar los datos, hay una parte en la que hay que ceder hasta cierto punto.

[kimjoin2]

Katok... ss

[GN⁺]

Opiniones de Hacker News

• Al principio pensé que AT Protocol era el sistema de Bluesky, como una versión corporativa de ActivityPub, pero después de leer este artículo me gustó bastante la forma en que los datos se almacenan en el "repositorio" que yo elijo. También encaja con mi principio general de que es mejor hacer el filtrado y cosas así del lado de lectura que al momento de escribir. Así que me gusta una estructura donde puedo subir todo lo que quiera a mi repositorio, y otras personas pueden leerlo y usarlo. La flecha hace que parezca que los comentarios entran a mi repositorio, pero eso parece una pequeña imprecisión al expresar la idea. En general, se siente como una arquitectura muy genial y descentralizada. Pero cuando intenté operar mi propio PDS separado en AT, descubrí que, aunque está bastante pulido y bien empaquetado, sí tiene algunos requisitos previos:

  1. Maneja automáticamente cosas como SSL
  2. Levanta un servidor HTTPS/WSS para soportar varias operaciones RPC Por eso, aunque en la práctica quisiera usar tanto https://roshangeorge.dev como at://roshangeorge.dev, para este último necesito https://roshangeorge.dev/xrpc y wss://roshangeorge.dev. Así que al final termino operando con https://roshangeorge.dev y at://at.roshangeorge.dev, además de https://at.roshangeorge.dev y wss://at.roshangeorge.dev. Claro, esto es un detalle menor y no afecta la dirección general. Aun así, vale la pena señalarlo.

  • Creo que causé confusión por usar dos tipos de flechas. La flecha sólida (la que baja desde @alice.com) representa propiedad. Es lo mismo que la agrupación por colores. Todo lo azul significa que le pertenece a Alice. La flecha punteada es un enlace entre registros. Igual que un <a href>, cualquier registro puede enlazarse libremente con cualquier otro, sin importar en qué repositorio esté. Si alguien comenta en mi publicación, ese comentario entra al repositorio de quien comentó y queda enlazado con la publicación original. Diseñamos el modelo de datos así para que quien indexa pueda reconstruir fácilmente la relación si tiene ambos registros. Por ejemplo, si Bob comenta una publicación de Alice, el comentario de Bob está en el repositorio de Bob, y la publicación de Alice está en el repositorio de Alice. Si alguien comenta en mi post, ese comentario siempre permanece en el repositorio de esa persona. La premisa clave es que no se pueden crear registros en el repositorio de otra persona.

  • El empaquetado base de PDS soporta automáticamente el manejo de SSL, pero no es obligatorio; está hecho así para que a los desarrolladores les resulte fácil aplicarlo. Los URI at:// tienen la forma at://DID/..., y los handles legibles por humanos se mapean al DID mediante un registro DNS TXT (_atproto.roshangeorge.dev). El DID enlaza a un documento que indica la ubicación del servidor, así que las rutas HTTPS/WSS pueden estar donde sea. Además, los likes, respuestas, etc. a mis publicaciones se guardan en el repositorio de la persona que hizo esa acción, no en mi repositorio. Mi intuición sobre esa parte era correcta.

• Pensaba que ActivityPub era el mejor protocolo y que AT era solo una copia barata, pero este artículo me hizo darme cuenta de que AT es mucho mejor. La clave es que varios programas pueden compartir la misma identidad. Esa sí es una funcionalidad increíble, y de verdad me abrió la mente.

  • La mayoría de las explicaciones sobre ATProto se enfocan en la propiedad de los datos, pero en realidad ActivityPub es más potente en la parte de procesamiento de datos. ATProto está estructurado como una vista pública de todo el mundo, así que todos los eventos son visibles para un AppServer global de confianza y este tiene que evaluarlos directamente; por eso la generación de feeds, los permisos de acceso, etc. dependen por completo de intermediarios de confianza. ActivityPub, en cambio, se parece más a RSS o al correo electrónico: mi servidor solo gestiona los feeds que yo sigo, y mi inbox se compone directamente de publicaciones a las que tengo acceso. Esa también es la razón por la que en Bluesky no se pueden hacer "likes privados" como en Twitter. Cada AppView tiene que rastrear por sí mismo los likes de todas las publicaciones de la red, lo cual es tremendamente engorroso. A largo plazo, creo que la estructura de ActivityPub tiene más ventajas. Y sobre lo de que “varios programas comparten la misma identidad”, en realidad eso ya estaba en los diseños iniciales de ActivityPub. Lo que pasó es que las implementaciones tempranas más populares quitaron esa capacidad para adaptarse a sus estructuras existentes.

  • El debate entre AT y AP es bastante complejo. Ya se ha discutido varias veces en nuestra comunidad, así que dejo un hilo que puede servir de referencia: https://github.com/bevyengine/bevy/discussions/18302

  • Me alegra que esta parte te haya resonado. Siempre me frustra que se compare con AP, porque el alcance es completamente distinto.

  • También sería interesante un artículo que trate una perspectiva similar desde el punto de vista de un ingeniero de sistemas distribuidos. https://atproto.com/articles/atproto-for-distsys-engineers

  • Entonces me pregunto si eso significa que existe un servicio centralizado de identidad.

• No me importa qué protocolo distribuido termine ganando, pero aunque ATProtocol se ve bien en teoría, en la práctica cada vez me parece más atractiva la opción de ActivityPub. Yo participo mucho en Lemmy, y es bastante activo y entretenido.

  1. El 99.99% de los usuarios de AT están concentrados en Bluesky. Es un servicio dirigido por una empresa. Aunque digan que no controlan el protocolo, en la práctica son su instancia dominante, así que existe el riesgo de que lo cambien a su conveniencia. Incluso me preocupa que en 5 años decidan que ya no será posible migrar. Eso ya ha pasado repetidamente en varias redes sociales.
  2. A los usuarios no les importan los protocolos; la inercia y la base de usuarios importan muchísimo más. Incluso en varios servicios alternativos a Reddit que usan AP, atraer usuarios es muy difícil, y convencerlos de volver a cambiar también lo es. Al final, me preocupa que estos intentos solo terminen fragmentando aún más comunidades ya pequeñas, y que todos terminen rindiéndose y regresando a una plataforma grande. Que sea fácil mover una cuenta es una función genial, pero ya es bastante simple hacer backup/restore de la configuración y crear una cuenta en una nueva instancia. No me parece un cambio tan grande. Sitio de referencia: https://arewedecentralizedyet.online/ Últimamente también valoro bastante Lemmy, programming.dev y Piefed

  • A diferencia de Mastodon, en AT el concepto mismo de instancia es distinto. Incluso dentro de la infraestructura de Bluesky hay varios PDS y funcionan de manera jerárquicamente diferente a nivel estructural (ver el artículo relacionado). No es correcto describirlo como una sola instancia dominante. Claro, la preocupación de que una empresa manipule el protocolo a su gusto es realista. Pero hasta ahora se considera que han sido buenos administradores. Creo que es algo que se irá resolviendo conforme crezca el ecosistema. También existe la preocupación de que Bluesky cierre el servicio y ya no se pueda migrar, pero el propio protocolo trae integrados el backup y la migración. Con solo tener un archivo CAR, puedes moverte a otro host en cualquier momento. En Mastodon se pierde bastante al migrar cuentas, pero en atproto la migración puede ser 100% transparente.

  • Al final, ya sea Bluesky o Mastodon, entras y no ves más que política estadounidense. Como no me gustan mucho los dramas políticos semanales, creo que plataformas más variadas como Tumblr, Pinterest o TikTok me quedan mejor.

  • Mastodon no es exactamente lo mismo que ActivityPub, pero no me da confianza que las respuestas desaparezcan de repente. Algunas publicaciones siguen ahí y luego desaparecen, y esa fue una de las dos razones por las que dejé Mastodon.

• Me da un poco de lástima que, aunque cada app use sus propios tipos de colección y puedan compartir colecciones entre ellas, al final no quede claro si las apps serán realmente interoperables. Una de las cosas bonitas de ActivityPub es que un usuario de Mastodon puede seguir a uno de Pixelfed sin tener que pensar demasiado en ello. Se siente como si Twitter, Instagram, Reddit, YouTube y Substack se conectaran automáticamente entre sí sin configuraciones especiales.

  • En AP, varios servicios se integran bastante bien de forma predeterminada en torno a los tipos Status y Question. Mastodon, Pixelfed, Misskey, Pleroma y otros giran en torno a ese esquema. Pero el soporte para otros tipos es muy limitado, así que otros contenidos no se manejan bien. El problema es la falta de una organización comunitaria para extensiones fuera del estándar. En ATproto es obligatorio seguir la definición de lexicon/schema de las colecciones de datos, y tanto las implementaciones de referencia como las de terceros ofrecen validación de esquemas. Así que la compatibilidad básica está estructurada de una forma mucho más clara, aunque creo que también hace falta más flexibilidad para permitir soporte opcional para algunos campos adicionales. Hay ejemplos como Bridgy Fed, que adjunta a los datos provenientes de APub metadatos como la URL original, el texto, etc. (ver https://fed.brid.gy/docs#bluesky-fields)

  • Se está trabajando para mejorar los lexicon comunes: https://github.com/lexicon-community

• Empiezo a sentir que los proyectos que prometen ser el “Twitter de próxima generación” están resolviendo el problema en una dirección un poco equivocada. Después de recrear perfectamente las funciones de Twitter, solo terminan atorándose con la falta de usuarios y de contenido, el clásico problema del huevo y la gallina. Al final, la gente se junta donde ya hay gente, y eso sigue siendo Twitter. Más bien, me parece mejor una dirección como la del timeline que lanzó recientemente OpenAI: primero reunir los datos en segundo plano y luego entregárselos al usuario. La implementación concreta puede variar, pero la dirección me parece correcta. La mayoría de los usuarios no le da tanto valor a la función de escribir tuits; el verdadero valor está en consumir los datos, en obtener contenido. Viéndolo así, creo que un lector RSS multisocial con opción P2P sería una mejor dirección. Es solo mi opinión.

  • Como explica el artículo, al principio se usa el microblogging como marco, pero en realidad son posibles formas muy diversas, no solo las tipo Twitter. Por ejemplo, Tangled está planteado como “Github sobre atproto”, y Leaflet como “Medium sobre atproto”. La limitación del enfoque P2P del lado cliente es que resulta difícil garantizar agregación a gran escala y consistencia, y eso es algo básico que la mayoría de los usuarios comunes espera de una app social. El ejemplo de OpenAI también es justamente una fortaleza de atproto. Como los datos ya existen en la red, es fácil agregar crawling, indexación y herramientas de automatización. Como caso inicial, se puede ver https://github.com/graze-social/iftta.

  • Las redes sociales no crecen por la fórmula de “¡lo mismo, pero con algo extra!”, sino cuando aparece una forma nueva que no era posible en la plataforma anterior.

  • ¡Por eso Nostr es diferente! Puedes hacer de todo: blogs, cosas tipo Twitter, servicios de streaming, mensajería, lo que sea. Colección de ejemplos: https://nostrapps.com

• Me pregunto si sería posible tener un TLD gratuito. ¿Cuál es realmente el costo de registrar un dominio? Si Let's Encrypt pudo ofrecer certificados gratis, me cuesta ver por qué una organización sin fines de lucro no podría ofrecer también dominios gratuitos. Ni siquiera tendrían que verse bonitos. No me importaría apilar varios UUID v7, mientras sean globalmente únicos y gratis. Una vez que el navegador se conecte, podrá recordarlo, así que una dirección larga tampoco sería problema. ¿De verdad sería tan mala idea?

  • En atproto eso lo cubre did:plc. Puedes obtener una ID gratuita en https://web.plc.directory/. Por ejemplo, mi ID es https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr. Puedes vincularla con ese did:plc usando un registro TXT del dominio.

  • Un TLD gratuito es difícil de hacer realidad en la práctica. Los TLD y la public suffix list tienen varias reglas, costos y particularidades operativas; ver https://github.com/publicsuffix/list. En cambio, los dominios normales que no son TLD se pueden usar libremente, y también se pueden repartir subdominios gratuitos. Pero si realmente operas un servicio así, pronto te caerán ataques del internet oscuro, como spam y phishing, y te arrepentirás de haberlo hecho. Igual que cualquiera puede crear un redireccionador de URL, pero operarlo en la práctica es otro asunto: si lo manejas en serio, enseguida te topas con problemas. Es una realidad desafortunada.

  • En esencia es una idea parecida a repartir direcciones IPv6. Hoy en día, la mayoría de los servicios de internet residenciales asignan IPv6 públicas en bloques /64, pero la mayoría de los ISP bloquea puertos con firewall, así que en la práctica no se pueden aprovechar bien. Además, si cambias de ISP, es fácil perder esa dirección. Para convertir eso en una dirección IPv6 verdaderamente permanente y portable, habría que repartir gratis espacio de direcciones provider-independent a nivel individual y conectarlo además al enrutamiento global por BGP. En teoría es posible, pero todavía no se ha implementado nunca; se parece al estado de las cosas antes de que existiera Let's Encrypt. No sé bien por qué hace falta un nombre basado en DNS, pero si no va a ser corto y fácil de recordar, DNS no es tan adecuado. Aun así, un enfoque como el de ngrok, que emite dominios con su propio gTLD, podría intentarse. De hecho, el ccTLD .me alguna vez repartió dominios gratuitos de una manera parecida, e insertaba publicidad en todo el tráfico desde un proxy intermedio como pago.

  • .tk era gratuito y llegó a ser el ccTLD más grande del mundo por cantidad de registros. Se usaba mucho para abusos. Facebook demandó a la operadora (la empresa neerlandesa Freenom) por facilitar phishing, y desde entonces ya no es gratis.

  • Hubo una iniciativa para el TLD .FREE, pero se fue desinflando por problemas de ejecución e incumplimientos de plazos https://icannwiki.org/.free

• Si veo un artículo de Dan, hago clic. Me preocupa un poco que la web abierta pareciera triunfar gracias a la ventaja de haber llegado primero. Por otro lado, ver cómo triunfa el open source sí me da esperanza. Me gustaría ver un mundo donde algo como atproto tenga éxito. Es una lástima que, por efectos de red, apps mejores no logren despegar.

  • HTML triunfó porque era “gratis”. En aquel entonces había muchos estándares de hipermedia de pago, y a diferencia de esos competidores, este era mucho más accesible. Era un entorno donde cualquiera podía crear fácilmente un navegador o un servidor.

  • También es una gran ventaja que ATProto esté diseñado para romper los límites de los efectos de red. Si todos migran a algo basado en atproto, entonces ya no habrá que cambiarse de red social “una última vez”. Al final ofrece un entorno descentralizado con competencia libre.

• Siendo realistas, me cuesta imaginar que un sistema así pueda difundirse de forma amplia. El público objetivo de las redes sociales tradicionales y la gente con inclinación por la descentralización son grupos completamente distintos. A la mayoría solo le interesa la plataforma como medio, no el sistema. Si al final todos crean solo una cuenta en Bluesky, entonces se concentrará igual que antes en unos pocos servicios grandes y perderá sentido.

  • Incluso si todos se juntan en bsky.social, eso ya sería un avance enorme comparado con lo anterior. Igual que no decimos que la web esté centralizada solo porque muchos servidores estén en AWS, aquí también siempre puedes mudarte si lo necesitas.

  • En realidad, bluesky todavía no tiene implementada por completo la federación. Todo el tráfico depende de un único servidor enrutador “BGS”.

  • Lamentablemente, al final el origen del problema es la “gente”.

• Tengo sentimientos encontrados sobre este trabajo. Por un lado, la idea es totalmente de mi gusto. Encaja con el movimiento Indie Web, donde cada persona posee su propio contenido, y el nivel de acabado de esta página y de estos textos también es realmente impresionante. Por otro lado, casi no hay desarrolladores que apliquen estos estándares en blogs personales o proyectos open source, y la adopción también es baja entre vloggers/blogueros y usuarios comunes. Me preocupa que a mucha gente no le importen la propiedad de los datos, la apertura ni la interoperabilidad. Da la impresión de que la gente solo quiere feeds como los de TikTok o Instagram Reels. Respeto la visión y el esfuerzo, pero me pregunto si esto puede llegar a ser algo mainstream en vez de un hobby de nicho.

  • Todavía queda por mejorar la experiencia de desarrollo para que sea más sencilla. Pero el ritmo de avance en esta área es increíblemente rápido, así que tengo muchísimas expectativas para los próximos 6 a 12 meses. La mayoría de la gente todavía no entiende que ATProto no aplica solo a Bluesky, sino a campos mucho más diversos, y hace falta tiempo para que eso se vea de manera más concreta en el mercado.

  • Me pregunto por qué el concepto de “propiedad de los datos” es tan importante, y por qué es realmente preocupante que al público no le importe. En el pasado, la gente ya consumía contenido sin propiedad, como la TV, los libros o la radio. Ahora simplemente se les dio la oportunidad de publicar algo y que quienes los rodean lo vean, así que también me pregunto si realmente importa tanto la “propiedad” real de una publicación en Instagram.

  • Estoy de acuerdo con lo que dices. Al final, si queremos que esto tenga éxito, nos toca a nosotros difundir esta tecnología activamente y ayudar a popularizarla. Quizá algún día un fundador o CTO fascinado por lo social abierto lance una app exitosa para el gran público; si no hacemos nada, nunca tendrá éxito.