Social aberto

• Assim como o código aberto se tornou o padrão da infraestrutura de software, o paradigma de "social aberto" também está surgindo nos apps sociais
• O AT Protocol permite que os usuários possuam e controlem diretamente seus dados sociais, propondo um conceito diferente das plataformas sociais tradicionais
• Os dados sociais deixam de ficar presos dentro de um serviço específico e passam a ser armazenados em um repositório pessoal gerenciado pelo próprio usuário
• Com isso, torna-se possível a reutilização e remixagem de dados entre apps, e mesmo que um serviço seja encerrado, os dados não desaparecem e continuam existindo
• Com a expansão do social aberto, a propriedade dos dados centrada no usuário e a flexibilidade para expansão tendem a emergir como valores centrais

---

Introdução: o sucesso do código aberto e uma nova tendência

• O código aberto, apesar de muita resistência no passado, hoje se consolidou como base da infraestrutura comum
• Diferentemente do passado, hoje escolher código aberto não é um problema, e em áreas importantes de software o open source virou o padrão
• Agora estamos diante de um ponto de virada nos apps sociais semelhante ao do open source de 35 anos atrás
• Uma nova tendência chamada "social aberto" surgiu, e o AT Protocol do Bluesky é visto como a implementação mais convincente

A estrutura básica da web e a posse de dados pessoais

• Na web do passado, existiam endereços pessoais como alice.com e bob.com, e cada usuário possuía seu próprio espaço para publicar livremente seu conteúdo
• Se o hosting não agradasse, era possível migrar para outro lugar e manter o mesmo endereço, sem quebrar os links existentes
• Por isso, os usuários não ficavam presos a um provedor de hospedagem específico, e os provedores precisavam competir
• Em outras palavras, graças ao design descentralizado da web, os usuários controlavam os dados, e as empresas atuavam apenas como fornecedoras

Redes sociais modernas: a perda da propriedade dos dados

• Hoje, em vez de manterem seus próprios sites, as pessoas normalmente recebem identificadores como @alice e @bob de uma empresa e publicam em apps de mídia social
• Dados como posts, comentários e curtidas ficam armazenados no banco de dados de uma empresa social específica
• Essa estrutura viabilizou funções de agregação social como busca, feed, recomendações e notificações
• Mas isso também trouxe o efeito colateral de que os dados centrais deixam de ser nossos
• Os usuários passam a viver numa situação em que não conseguem levar livremente consigo os dados e relações que criaram

O problema: usuários presos à plataforma

• Quando o usuário sai, precisa deixar para trás toda a rede de conexões que construiu
• Não é fácil trocar de provedor de hospedagem, e ao deixar a plataforma, perde-se junto a conexão e os dados
• Como as plataformas sabem disso, o usuário acaba tendo de tolerar mudanças prejudiciais (excesso de anúncios, distorção de algoritmos, remoção de recursos etc.)
• Mesmo com backup ou exportação de dados, isso não passa de "dados mortos" sem contexto social, difíceis de reviver em outro lugar

Social aberto: recuperação da propriedade dos dados e da rede

• No social aberto, identificadores baseados em domínio como @alice.com devolvem ao usuário a propriedade efetiva dos dados sociais
  • O nome fica vinculado a um domínio que eu possuo, como @alice.com
• O usuário gerencia diretamente todos os dados sociais que gera por meio de um repositório pessoal (repository)
  • Atividades como posts, comentários e follows são registradas no repositório pessoal (repo)
  • O repositório é apenas um servidor web simples que armazena registros em formato JSON
  • O endereço segue o formato at://alice.com/..., permitindo interligação entre eles
• Repositórios baseados no AT Protocol operam sobre DNS, HTTP e JSON, e cada dado é armazenado em JSON com hiperlinks
• Mesmo quem não entende de tecnologia tem um repositório criado automaticamente ao se cadastrar em um app, e os dados continuam pertencendo ao usuário, independentemente do app
• Os dados pertencem ao repositório do usuário, e mesmo que o provedor de serviço mude, a propriedade e a conectividade dos dados são mantidas

Estrutura e aplicações dos apps de social aberto

• Cada app de social aberto, como um CMS, gerencia parte do repositório social do usuário, e o app passa a ser apenas uma ferramenta para ler e escrever no repositório do usuário
• Por exemplo, dados de apps diferentes como Bluesky, Tangled e Leaflet passam a coexistir no repositório de um mesmo usuário
  • Se eu publico no Bluesky, esse registro vai para meu repositório; se favoritar um projeto no Tangled, isso também entra no meu repositório
  • Para evitar conflitos, os formatos de dados são separados por namespaces, como app.bsky.post e sh.tangled.star
  • Com o tempo, meu repositório se torna uma coleção de dados vindos de vários apps

Mudanças no ecossistema trazidas pela abertura dos dados

• Como os dados são armazenados de forma aberta, fica mais fácil integrar apps, criar novos serviços e referenciar, reutilizar e remixar dados uns dos outros livremente
• Mesmo que um app seja encerrado, os dados permanecem no repositório do usuário e podem ser reaproveitados por outros serviços
• Novos apps podem usar relações e dados da rede já existente para superar o "cold start" (o problema de construir uma rede inicial)
• Como esses dados podem ser lidos por qualquer um, outros apps podem buscá-los para carregar a foto de perfil ou reutilizar as relações de follow existentes
• Mesmo que um app feche as portas, os dados continuam no repositório do usuário e outro app pode recuperá-los depois

Agregação (aggregation) e desafios técnicos

• Embora os dados dos usuários fiquem distribuídos em repositórios individuais, é possível receber streams de eventos de alteração de dados via WebSocket e refletir isso em um banco de dados local
• Relays de grande porte recebem os eventos de toda a rede e filtram apenas os necessários
• Os registros de dados são assinados criptograficamente para garantir confiabilidade e consistência
• Por exemplo, infraestruturas como Graze e Slices dão suporte à agregação no social aberto

Como funcionam os recursos de agregação?

• Embora o repositório de cada usuário exista separadamente, os apps recebem streams de eventos em tempo real vindos desses repositórios e os registram em seus próprios bancos de dados
• Servidores de retransmissão (relays), como o Bluesky, reúnem e distribuem o stream completo, e os apps armazenam apenas os eventos de interesse
• O banco de dados construído dessa forma pode oferecer rapidamente recursos como busca, feed e recomendação
• Os registros de dados são assinados criptograficamente para garantir confiabilidade e consistência: mesmo sem confiar no relay, é possível verificar a autenticidade dos dados
• Infraestruturas como Graze e Slices dão suporte à agregação no social aberto

Visão geral

• Web do passado: o usuário controlava seu próprio conteúdo e endereço
• Apps sociais de hoje: há recursos de agregação, mas os dados ficam presos no banco de dados de uma empresa
• Social aberto: os recursos de agregação são mantidos, mas os dados continuam nas mãos do usuário
• Os apps se tornam apenas uma janela que reúne e exibe os dados do usuário
• Mesmo que um serviço desapareça, os dados continuam existindo e outro app pode reapresentá-los em um novo contexto

Conclusão

• O núcleo do social aberto é combinar as vantagens da web pessoal (propriedade dos dados, liberdade de hospedagem, manutenção de links) com os pontos fortes das redes sociais fechadas (agregação, escalabilidade)
• O social aberto garante propriedade dos dados centrada no usuário, mobilidade livre dos dados entre apps e continuidade dos serviços
  • Assim como o open source dizia que "o código deve pertencer ao usuário", aqui a ideia é que "os dados devem pertencer ao usuário"
  • Isso resolve o problema de o usuário perder dados e conectividade em plataformas fechadas
• À medida que mais produtos de social aberto surgirem, as fronteiras entre apps tendem a ficar difusas, evoluindo para um ecossistema em que os dados circulam naturalmente
  • No fim, pode surgir um futuro em que os usuários controlem de fato seus dados e sua rede
• No começo, isso provavelmente será impulsionado por um pequeno grupo de desenvolvedores e usuários entusiasmados, mas à medida que uma base compartilhada se acumular, o modelo aberto tem grande chance de vencer um dia
  • Mesmo sem entender conceitos técnicos como descentralização ou federação, as pessoas podem perceber benefícios concretos (integração de dados, migração fácil, continuidade)
  • O social aberto deve se expandir gradualmente por meio de um esforço comunitário apaixonado de longo prazo e efeitos cumulativos

[shakespeares]

É verdade que o Instagram também é um lugar para guardar memórias, mas parece difícil sair de lá quando se quer.
Também penso que, no aspecto de compartilhar e usar dados, há partes em que precisamos ceder até certo ponto.

[kimjoin2]

KakaoTalk... aff

[GN⁺]

Comentários do Hacker News

• Como o AT Protocol é o sistema do Bluesky, no começo achei que fosse uma versão corporativa do ActivityPub, mas depois de ler este texto percebi que gosto bastante da forma como os dados ficam armazenados no "repositório" que eu escolho. Isso também combina com meu princípio geral de que é melhor executar filtragem e afins no lado da leitura do que no momento da escrita. Então faz sentido eu colocar no meu repositório tudo o que eu quiser, e deixar que outras pessoas leiam e usem isso. As setas fazem parecer que os comentários entram no meu repositório, mas isso parece só uma pequena imprecisão ao expressar a ideia. No geral, me parece uma arquitetura muito legal e descentralizada. Mas quando tentei de fato rodar um PDS separado no AT por conta própria, percebi que, embora tudo seja bem polido e bem empacotado, existem alguns pré-requisitos:

  1. Ele lida automaticamente com coisas como SSL
  2. Ele sobe um servidor HTTPS/WSS para dar suporte a vários processamentos RPC Por causa disso, mesmo que eu queira usar na prática tanto https://roshangeorge.dev quanto at://roshangeorge.dev, no segundo caso eu preciso de https://roshangeorge.dev/xrpc e wss://roshangeorge.dev. Então, no fim, acabei operando com https://roshangeorge.dev e at://at.roshangeorge.dev, além de https://at.roshangeorge.dev e wss://at.roshangeorge.dev. Claro, isso é um detalhe menor e não compromete a direção geral. Ainda assim, vale mencionar.

  • Acho que causei confusão por usar dois tipos de seta. A seta sólida (descendo de @alice.com) indica propriedade. É a mesma ideia do agrupamento por cor. Tudo em azul pertence à Alice. As setas tracejadas são links entre registros. Elas são como <a href>: qualquer registro pode apontar livremente para qualquer outro, em qualquer repositório. Se alguém comenta no meu post, esse comentário vai para o repositório de quem comentou e cria um vínculo com o post original. O motivo de o modelo de dados ter sido desenhado assim é permitir que quem faz indexação consiga reconstruir facilmente a relação se tiver os dois registros. Por exemplo, se Bob comenta no post da Alice, o comentário do Bob fica no repositório do Bob e o post da Alice fica no repositório da Alice. Se alguém comenta no meu post, esse comentário sempre permanece no repositório dessa pessoa. A premissa central é que não se pode criar um registro no repositório de outra pessoa.

  • O empacotamento padrão do PDS oferece suporte automático a SSL, mas isso não é obrigatório; foi feito para facilitar a adoção pelos desenvolvedores. Os URIs at:// têm a forma at://DID/..., e handles legíveis por humanos são mapeados para o DID por meio de um registro TXT de DNS (_atproto.roshangeorge.dev). O DID aponta para um documento que especifica a localização do servidor, então as rotas HTTPS/WSS podem ficar em qualquer lugar. Além disso, curtidas, respostas etc. aos meus posts entram no repositório de quem realizou a ação, não no meu repositório. Minha intuição sobre essa parte estava correta.

• Eu achava que o ActivityPub era o protocolo melhor e que o AT era só uma imitação barata, mas este texto me fez perceber que o AT é muito melhor. O ponto principal é que vários programas podem compartilhar a mesma identidade. Isso é uma funcionalidade realmente incrível e foi algo que ampliou muito minha visão.

  • A maior parte das explicações sobre o ATProto foca na propriedade dos dados, mas na prática o ActivityPub é mais poderoso na parte de processamento de dados. O ATProto tem uma estrutura voltada para observar o mundo inteiro publicamente, então todos os eventos ficam visíveis para um AppServer global confiável, que precisa julgá-los diretamente; por isso, geração de feed, permissões de acesso etc. acabam dependendo de intermediários confiáveis. O ActivityPub, por outro lado, é mais parecido com RSS ou email: meu servidor só gerencia os feeds que eu assinei, e minha inbox já é formada diretamente pelos posts aos quais tenho acesso. É por isso também que no Bluesky não existe algo como "curtidas privadas" no estilo do Twitter. Cada AppView precisa rastrear por conta própria a contagem de curtidas de todos os posts da rede, o que é extremamente incômodo. No longo prazo, acho que a estrutura do ActivityPub é mais vantajosa. E essa parte de “vários programas compartilharem a mesma identidade” já existia, na verdade, nos primeiros desenhos do ActivityPub. Foram as implementações iniciais mais populares que removeram isso para se adaptar a estruturas existentes.

  • O debate AT vs AP é extremamente complexo. Já tivemos essa discussão várias vezes na nossa comunidade, então deixo um thread que pode servir de referência: https://github.com/bevyengine/bevy/discussions/18302

  • Fico feliz que essa parte tenha te tocado. Sempre acho cansativo comparar com AP, porque o escopo é totalmente diferente.

  • Também seria interessante um texto que abordasse uma perspectiva semelhante do ponto de vista de um engenheiro de sistemas distribuídos. https://atproto.com/articles/atproto-for-distsys-engineers

  • Então isso significa que existe um serviço de identidade centralizado?

• Não me importo qual protocolo distribuído vai vencer, mas embora o ATProtocol pareça bom em teoria, na prática o ActivityPub vem me parecendo cada vez mais atraente. Eu participo bastante do Lemmy, e ele é bem ativo e divertido.

  1. 99,99% dos usuários de AT estão concentrados no Bluesky. É um serviço liderado por empresa. Mesmo que digam que não controlam o protocolo, na prática são a instância dominante do protocolo, então existe o risco de mudarem as coisas conforme seus próprios interesses. Tenho até receio de que, daqui a 5 anos, decidam que migração não será possível. Isso já aconteceu repetidas vezes em várias redes sociais.
  2. Usuários não ligam para protocolo; inércia e base de usuários importam muito mais. Mesmo nos vários substitutos do Reddit que usam AP, atrair usuários já é difícil, e convencê-los a migrar de novo é ainda mais difícil. No fim, temo que essas tentativas só fragmentem ainda mais comunidades já pequenas e que todos acabem desistindo e voltando para as plataformas grandes. O fato de a migração de conta ser fácil é um recurso legal, mas backup/restauração de configuração e o processo de criar uma conta em uma nova instância já são simples o bastante. Não é uma mudança tão grande assim. Site de referência: https://arewedecentralizedyet.online/ Lemmy, programming.dev, Piefed etc. também têm sido bem avaliados ultimamente.

  • Diferentemente do Mastodon, no AT o próprio conceito de instância é diferente. Há vários PDS dentro da infraestrutura do Bluesky, e estruturalmente eles operam de forma hierárquica diferente (veja o artigo relacionado). Não é correto chamar isso de uma única instância dominante. Claro, a preocupação de uma empresa influenciar o protocolo a seu favor é realista. Mas, até agora, eles foram bons administradores disso. Acho que é algo que será resolvido aos poucos conforme o ecossistema crescer. E existe, sim, a preocupação de o Bluesky encerrar o serviço e a migração se tornar impossível, mas o próprio protocolo já inclui backup e migração. Com um arquivo CAR, você pode migrar para outro host a qualquer momento. No Mastodon, a migração de conta tem muitas perdas, mas no atproto ela pode ser 100% transparente.

  • No fim das contas, seja Bluesky ou Mastodon, quando você entra parece que só tem discussão sobre política dos EUA. Como eu não gosto muito de drama político semanal, plataformas mais diversas como Tumblr, Pinterest ou TikTok parecem combinar mais comigo.

  • Mastodon não é exatamente igual ao ActivityPub, mas o fato de respostas desaparecerem do nada me faz não confiar. Alguns posts continuam lá e depois somem de novo, e isso foi uma das duas razões pelas quais abandonei o Mastodon.

• É um pouco decepcionante que cada app use seus próprios tipos de coleção e, ainda que possam compartilhar coleções entre si, no fim não fique claro se os apps serão realmente interoperáveis. Uma das coisas bonitas do ActivityPub é que um usuário do Mastodon pode seguir um usuário do Pixelfed sem precisar pensar muito nisso. É como se Twitter, Instagram, Reddit, YouTube e Substack se conectassem automaticamente sem configuração especial.

  • No AP, vários serviços já se integram bem em torno dos tipos Status e Question. Mastodon, Pixelfed, Misskey, Pleroma etc. giram todos em torno dessa estrutura. Mas o suporte a outros tipos é muito limitado, então outros tipos de conteúdo não são bem suportados. O problema é a falta de organização comunitária em torno de extensões fora do padrão. Já o ATproto exige que coleções de dados sigam definições de lexicon/schema, e implementações de referência e de terceiros fornecem validação de esquema. Por isso, a compatibilidade básica fica estruturada de forma mais clara; ainda assim, acho que ele deveria permitir um pouco mais de flexibilidade, como suporte opcional para alguns campos adicionais. Há exemplos como o Bridgy Fed, que anexa aos dados vindos do APub metadados como URL original e texto. (Veja https://fed.brid.gy/docs#bluesky-fields)

  • Há um esforço em andamento para melhorar lexicons comuns: https://github.com/lexicon-community

• Estou começando a sentir que os projetos que prometem ser o “próximo Twitter” erram um pouco na forma de resolver o problema. Depois de reproduzirem perfeitamente as funções do Twitter, eles acabam batendo no problema da falta de usuários e conteúdo, o clássico ovo e galinha. No fim, as pessoas se reúnem onde já tem gente, e esse lugar ainda é o Twitter. Em vez disso, a direção do timeline lançado recentemente pela OpenAI me parece melhor: primeiro reunir dados em segundo plano e depois entregá-los aos usuários. A implementação concreta pode ser diferente, mas a direção me parece correta. A maioria dos usuários não dá tanto valor à função de escrever tweets; o verdadeiro valor está no consumo dos dados, ou seja, em obter conteúdo. Sob essa ótica, acho que um leitor de RSS social múltiplo com opção P2P seria um caminho melhor. Opinião pessoal.

  • Como explicado no artigo, o enquadramento inicial usa microblogging, mas na prática é possível fazer muita coisa além de algo tipo Twitter. Por exemplo, o Tangled é “Github on atproto”, e o Leaflet é “Medium on atproto”. A limitação de abordagens P2P no lado do cliente é que elas têm dificuldade para garantir agregação em larga escala e consistência, que são expectativas básicas da maioria dos usuários comuns de apps sociais. O exemplo da OpenAI também é uma área em que o atproto se destaca. Como os dados já existem na rede, é fácil acoplar crawling, indexação e ferramentas de automação. Como exemplo inicial, veja https://github.com/graze-social/iftta.

  • Redes sociais crescem não com a lógica de “igual, mas com algo a mais!”, e sim quando aparece uma nova forma que era impossível na plataforma anterior.

  • É por isso que o Nostr é diferente! Dá para fazer blogs, algo no estilo Twitter, serviço de streaming, mensageiro e o que mais quiser. Coleção de exemplos: https://nostrapps.com

• Fico pensando se um TLD gratuito seria possível. Qual é, na prática, o custo de registrar domínios? Quando lembro que o Let's Encrypt liberou certificados gratuitamente, fico pensando por que seria impossível uma organização sem fins lucrativos também fornecer domínios de graça. Nem precisam ser bonitos. Pode ser um monte de UUID v7 encadeados; se for globalmente único e gratuito, já basta. Depois que o navegador acessa uma vez, ele vai lembrar, então endereços longos não seriam um problema. Essa ideia é realmente tão ruim?

  • No atproto, quem faz esse papel é o did:plc. É possível obter um ID gratuito em https://web.plc.directory/. Por exemplo, meu ID é https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr. Você pode vinculá-lo ao domínio usando um registro TXT com esse did:plc.

  • Um TLD gratuito é algo difícil de viabilizar na prática. TLDs e a public suffix list vêm com várias regras, custos e particularidades administrativas; veja https://github.com/publicsuffix/list. Já domínios comuns podem ser usados livremente, e também é possível distribuir subdomínios gratuitos. Mas, se você operar um serviço desses na prática, logo vai atrair spam, phishing e outros ataques da dark internet, e vai se arrepender de ter lançado. É como os encurtadores/redirecionadores de URL: qualquer um pode criar um, mas operar um serviço real é outra história. Se você levar a sério, os problemas chegam rápido. É uma realidade infeliz.

  • Isso é praticamente análogo a distribuir endereços IPv6. Hoje em dia, a maior parte da internet residencial recebe IPv6 público em blocos /64, mas os ISPs quase sempre bloqueiam portas com firewall, então o uso prático acaba impedido. Além disso, ao trocar de ISP, é fácil perder o endereço. Para transformar isso em um endereço IPv6 realmente permanente e portátil, seria preciso distribuir gratuitamente espaço de endereçamento provider-independent para indivíduos e conectá-lo ao roteamento global via BGP. Em teoria é possível, mas isso ainda nunca foi implementado (algo parecido com o estado do mundo antes do surgimento do Let's Encrypt). Não sei por que seria necessário um esquema de nomes baseado em DNS, mas se a ideia não for algo curto e fácil de memorizar, o DNS não é tão adequado assim. Ainda assim, algo no estilo do ngrok, emitindo domínios sob seu próprio gTLD, pode ser viável. Na prática, o ccTLD .me já distribuiu domínios gratuitos dessa forma no passado e, em troca, injetava anúncios em todo o tráfego por meio de um proxy intermediário.

  • O .tk era gratuito e foi o maior ccTLD do mundo em número de registros. Era muito usado de forma abusiva. Depois que o Facebook processou a operadora (a empresa holandesa Freenom) por envolvimento com phishing, isso deixou de ser gratuito.

  • Houve no passado uma iniciativa do TLD .FREE, mas, por problemas de execução e descumprimento de prazos, ela acabou esfriando https://icannwiki.org/.free

• Quando vejo um texto do Dan, eu clico. Fico um pouco preocupado com a ideia de que a web aberta pode ter dado certo por conta da vantagem do pioneirismo. Por outro lado, ver o sucesso do open source me dá esperança. Eu gostaria de ver um mundo em que algo como atproto desse certo. É realmente uma pena que aplicativos melhores não consigam vencer por causa dos efeitos de rede.

  • O HTML fez sucesso porque era “grátis”. Na época havia muitos padrões pagos de hipermídia, mas ele tinha uma acessibilidade muito maior do que esses concorrentes. Era um ambiente em que qualquer um podia criar facilmente um navegador ou servidor.

  • Uma grande vantagem do ATProto é justamente ter sido projetado para quebrar o limite dos efeitos de rede. Se todo mundo migrar para algo baseado em atproto, a rede social só precisaria ser trocada “uma última vez”. Em última instância, isso oferece um ambiente descentralizado com competição livre.

• Na prática, é difícil imaginar esse tipo de sistema se espalhando amplamente. O público-alvo de redes sociais tradicionais e o de usuários com inclinação descentralizadora são completamente diferentes. A maioria só se importa com a plataforma como meio, não com o sistema. Se no fim todo mundo só criar conta no Bluesky, isso vai se concentrar em alguns grandes serviços e perder o sentido, como sempre aconteceu.

  • Mesmo que todos se concentrem no bsky.social, isso ainda seria um avanço enorme em comparação com antes. Assim como não dizemos que a web ficou centralizada só porque muitos servidores estão na AWS, aqui também você pode migrar quando quiser.

  • Na prática, o Bluesky ainda não implementou federação completa. Todo o tráfego depende de um único servidor roteador “BGS”.

  • Infelizmente, no fim das contas, a origem do problema é “as pessoas”.

• Tenho sentimentos mistos sobre isso. Por um lado, a ideia é totalmente a minha cara. Está alinhada com o movimento Indie web, no qual cada pessoa possui seu próprio conteúdo, e o nível de acabamento desta página e destes textos é realmente impressionante. Por outro lado, quase não há desenvolvedores aplicando esse tipo de padrão em blogs pessoais ou projetos open source, e a adoção também é baixa entre blogueiros/vlogueiros e usuários comuns. Preocupa-me que tanta gente seja indiferente a propriedade dos dados, abertura e interoperabilidade. Parece que as pessoas só querem feeds como os do TikTok ou dos Reels do Instagram. Respeito a visão e o esforço, mas fico pensando se isso consegue mesmo virar algo mainstream em vez de continuar sendo um hobby de nicho.

  • Ainda falta melhorar a experiência de desenvolvimento para torná-la mais fácil. Mas o ritmo de avanço nesta área é tão rápido que estou muito animado com os próximos 6 a 12 meses. A maioria das pessoas ainda não entende que o ATProto pode ser aplicado a muito mais coisas além do Bluesky, e esse ponto ainda precisa se tornar mais concreto para o mercado.

  • Fico curioso sobre por que o conceito de “propriedade dos dados” seria tão importante assim, e por que seria realmente preocupante que o público em geral não ligue para isso. No passado, as pessoas consumiam conteúdo sem propriedade, como TV, livros e rádio. Agora elas só ganharam a possibilidade de publicar algo e deixar as pessoas ao redor verem. Será que a “propriedade” real de um post no Instagram é tão importante assim?

  • Concordo com você. No fim, o sucesso depende de nós divulgarmos ativamente essa tecnologia e trabalharmos para popularizá-la. Talvez um dia algum fundador/CTO encantado com open social lance um app de grande sucesso popular; se não fizermos nada, isso nunca vai acontecer.