Construindo comentários do Bluesky no meu blog

• Não usei sistemas de comentários existentes (Disqus, hospedagem própria, GitHub Issues etc.) por causa de problemas como desempenho, rastreamento, sobrecarga de manutenção e limite de usuários
• O Bluesky é adequado para comentários de blog porque não precisa de manutenção de infraestrutura, suporta conteúdo rico, usa contas com identidade real e permite conversa entre plataformas
• A implementação funciona assim: publicar no blog → compartilhar no Bluesky → adicionar o AT URI aos metadados do post → carregar e exibir a thread de comentários desse post
• Os componentes ficam separados em 3 partes: exibição de todos os comentários, exibição de comentário individual + resposta, e tratamento de embeds como imagem e link
• O tratamento de respostas é feito de forma recursiva, com limite de até 5 níveis, grade e modal de imagens, card de links e texto alternativo para embeds não suportados
• Integração Astro + React, carregamento no cliente com client:load, e habilitações feitas ao adicionar DID e postCid ao frontmatter
• Para segurança de tipos, usei os tipos TypeScript do @atcute/client; com JavaScript desativado, o conteúdo principal ainda aparece por meio de uma estrutura de progressive enhancement
• Sem servidor nem banco de dados, foi possível garantir desempenho usando a API do Bluesky e a CDN
• Essa abordagem evita reimplementar recursos sociais em cada site e ganha escalabilidade e independência ao conectar com a plataforma que o usuário já usa

---

Por que escolhi o Bluesky como sistema de comentários

• Não precisa manter infraestrutura
• Suporta conteúdo rico como imagem, link e citação de posts
• Confiabilidade e responsabilidade baseadas em contas do Bluesky
• Possibilidade de tráfego cruzado entre blog e mídia social
• Separação de propriedade de conteúdo (post do blog é do dono, comentários pertencem aos autores)

Entendendo o protocolo AT

• DID: identificador de usuário descentralizado
• CID: identificador de conteúdo
• AT URI: endereço no formato at://did:.../app.bsky.feed.post/...
• É possível buscar a thread de comentários via chamada da API getPostThread, sem necessidade de autenticação

Estrutura de componentes

• Componente principal de comentários
• Componente de renderização de comentário + resposta
• Componente de tratamento de embeds de imagem, link etc.

Tratamento de comentários aninhados

• Renderização recursiva, limite máximo de 5 níveis
• Representação hierárquica por meio de indentação visual

Tratamento de conteúdo rico

• Imagem: fornecida via CDN, grade de múltiplas imagens e visualização em modal
• Link externo: renderização de card com thumbnail e descrição
• Outros embeds: exibição de texto de fallback

Integração com Astro

• Uso de componente React + client:load
• Adicionar DID e postCid do Bluesky no frontmatter para ativar os comentários

Experiência de desenvolvimento

• Garantia de estabilidade com suporte de tipos do TypeScript
• Com Progressive Enhancement, o conteúdo não é afetado se a API ficar indisponível
• Sem carga de servidor/DB usando a infraestrutura do Bluesky

Conclusão

• Em vez de manter os problemas de sistemas de comentários tradicionais, conecte-se à plataforma que o usuário já utiliza
• O aumento de participantes pode acompanhar o crescimento do Bluesky
• Por ser baseado em ATProto, também facilita a troca para outro AppView ou implementação própria

[GN⁺]

Comentário do Hacker News

• Gostaria que fosse divulgado um plano geral de como o Bluesky pretende se monetizar no futuro. Por trás da estrutura técnica aparentemente complexa, fico curioso para saber de que forma isso seria cobrada caso se torne pago.

• Achei o artigo interessante; pessoalmente gosto de ler sobre pessoas construindo e operando seus próprios sites de forma independente. O texto menciona quatro alternativas para o problema do sistema de comentários, mas eu queria dizer que uma quinta abordagem também funcionou para mim. Depois de testar vários sistemas de comentários de terceiros, acabei criando e usando meu próprio form.lisp, um sistema de comentários simples. Cada comentário é salvo como arquivo de texto, então não preciso me preocupar com spam, XSS ou comentários sem sentido; verifico e adiciono manualmente ao blog nos finais de semana. Os comentários são armazenados como arquivos HTML comuns, e o gerador de site estático site.lisp também gera uma página de comentários junto com o conteúdo, ou seja, funciona como um gerador estático de comentários. Embora não se encaixe nas cinco propriedades citadas no texto (sem infraestrutura extra, conteúdo rico, nome real etc.), ele se encaixou perfeitamente no meu caso e venho usando com satisfação há pelo menos quatro anos.

  • Receber comentários via formulário de e-mail e, do ponto de vista da administração, adicioná-los manualmente no fim dos posts também é uma opção razoável.

  • Penso que o meu método também é muito adequado para blogs com pouco tráfego, mas, pessoalmente, acho estranho ter a voz de terceiros dentro do meu site; por isso, removi os comentários e uso o blog apenas como espaço de expressão pessoal. Em vez disso, prefiro deixar feedback por e-mail para outros blogueiros que me inspiram.

  • Dá a sensação de ser algo parecido com a publicação de colaborações de leitores em um jornal.

• Minha recomendação é o cactus.chat, que é baseado em Matrix e suporta convidados, então é possível comentar sem ter uma conta Matrix. Se eu usar minha própria conta, passo a participar de uma sala Matrix para cada post.

• O Bluesky é muito útil para armazenar dados com base em contas de usuário existentes; atualmente o mapa open source cartes.app está desenvolvendo um sistema de reviews baseado no Bluesky. Não é fácil, porque é necessário criar o léxico e manter o banco de dados alinhado com os streams do Bluesky.

  • Na verdade, dá para ir até certo ponto sem banco de dados; no scrapboard.org que construí, era possível consultar bastante dado do cliente apenas com a API getRecord (documentação).

  • Foi sugerido usar o mangrove.reviews: esse serviço tem uma licença CC-BY-SA bem clara e o MapComplete.org também é usado; o Bluesky também pode acabar tendo problemas algum dia.

• Sou cético em relação à sustentabilidade do modelo de receita do Bluesky, já que o fato de ser utilizável gratuitamente hoje é, na prática, graças ao investimento de VC (venture capital). Por isso, fico cauteloso ao adotá-lo; provavelmente sinto ansiedade de que, num futuro próximo, a API seja fechada ou o sistema de comentários acabe quebrado.

  • O Bluesky funciona tecnicamente sob o Personal Data Server (PDS) do usuário; qualquer pessoa pode trocar o PDS, e o servidor de app oficial do Bluesky é apenas um agregador. Também dá para acessar os mesmos dados por app servers e app views feitos por terceiros, então não é necessário ficar dependente da API oficial; em vários aspectos, a abertura é alta.

  • Sou bastante adepto do conceito de POSSE. O lado positivo do “ciclo de enshittification” é justamente poder ter, por um tempo, uma experiência agradável de comunidade online e depois migrar para outro lugar; não acho que devemos ficar apegados como se clubes antigos que desapareceram ainda pudessem voltar. Tenho também um link no Mastodon com meu pensamento sobre isso, explicação teórica.

  • Haverá um momento em que o Bluesky migrará para monetização, mas IA e outros serviços também seguem, no fim, esse modelo movido por capital de risco. Assim como com Twitter, Uber e DoorDash, o ambiente tende a se degradar, mas enquanto os VCs despejarem dinheiro sonhando com uma nova abundância, existe um certo prazer em aproveitar essa “prosperidade” até lá.

• Acredito que o ecossistema do Bluesky é realmente muito legal, já vi um caso dessa abordagem antes (sistema de comentários baseado no Bluesky). A única desvantagem para mim é que é preciso publicar um post separado no Bluesky para cada página web para que o sistema funcione; seria ótimo se houvesse algo como um web component.

• No texto, você diz que “não consigo anexar um sistema de comentários decente no blog há anos”, mas em todo o blog só aparecem duas postagens de 2025 (sendo que uma é este post).

  • Encontrei no archive.org que já houve outro blog no passado.

• Acho interessante por ser uma forma de interagir com redes sociais sem enfrentar diretamente o feed. Eu poderia anexar isso ao meu blog para que as pessoas deixem comentários diretamente, e eu interagir com Bluesky e outras redes só por essa interface. Ao abrir o feed, frequentemente eu acabava caindo em doomscrolling e desperdiçando tempo; com essa abordagem, percebi uma nova possibilidade de ainda me conectar às redes sociais sem cair nesse ciclo ruim.

  • Concordo que “ao abrir o feed, você acaba vendo só informação sem sentido o tempo todo”, e às vezes me pergunto se isso não era de propósito na sua ideia original.

• O Bluesky me dá a sensação de estar criando novamente, sozinho, um ambiente em que ideias frescas podem surgir livremente na internet.

  • Na prática, talvez seja apenas uma versão com opções de integração mais abertas do que o Threads; talvez “inovação aberta” seja uma expressão mais adequada para o ATProto.

  • Não quero investir muita energia em corporações ou em um único grupo, mas, por enquanto, a comunidade do Bluesky é divertida. Eu era fã do Twitter antigo, e acredito que a base atual de usuários principais do Bluesky tem bastante gente desse tipo. O que vai acontecer daqui para frente é algo a se acompanhar.

  • Eu sou adepto do slogan “protocolo, não plataforma”; embora também se fale em “build mode”, no fim é sobre criar algo que não possa ser facilmente apropriado ou mal utilizado.

  • Se você irritar a equipe do Bluesky ou algum grupo de usuários, ou se houver denúncia por um grupo específico, a conta pode ser banida imediatamente, ou pode virar invisível antes mesmo de alguém mencionar o assunto, se for colocada em uma blacklist pré-compartilhada. No fundo, soa como uma tentativa de recriar um ambiente mais duro do que o velho Twitter, com elementos de disputa de poder meio infantis, tipo o que acontece no refeitório do ensino médio.

• Como eu não hospedo o blog por conta própria e fico dependente do Bluesky, no fim das contas é o Bluesky que está me gerenciando. Eles dizem que não há lock-in de plataforma, mas fico curioso sobre o que fazer se amanhã minha conta for bloqueada pelo Bluesky ou se a empresa quebrar. Talvez seja possível migrar para produtos compatíveis com AT, mas fico preocupado com a perda de muitos dados.

  • Se você tem interesse no tema, em https://whtwnd.com/bnewbold.net estão organizadas informações e ferramentas práticas sobre construir uma rede relay, migração de dados e outras coisas com base no Bluesky e no AT Proto; há também vários avanços em migração de dados, portabilidade, suporte a rede relay alternativa, e o link relacionado pode ser consultado. (Para referência, o autor desse blog é funcionário do Bluesky; eu sou outra pessoa.)

  • Você pode fazer backup de seus dados pessoais em arquivos CAR (no formato tarball) no IPFS, e depois recuperar em qualquer PDS via documento did:plc da conta ou registro DNS. Se o PDS atual falhar ou for bloqueado, dá para migrar imediatamente para outro servidor. Existem implementações open source e provedores de hospedagem para relay (nós de gossip), PDS, clientes, app views (backend do app web do Bluesky). Mesmo que o Bluesky caia amanhã, é possível fazer self-hosting facilmente ou continuar o app existente usando outro provedor (por exemplo, zeppelin.social). O diretório PLC ainda é administrado pelo Bluesky, mas está migrando para uma fundação independente; se necessário, também é fácil cloná-lo, e com o método did:web você depende só do DNS, o que aumenta a independência.

  • Além disso, o Bluesky também está, claramente, expulsando ativamente usuários com viés libertário (libertário) ou de direita; o clima parece bom para quem é de esquerda ou politicamente indiferente.