Por que o Bluesky não é uma rede peer-to-peer?

Artigo original ↗ Discussão no Hacker News ↗

A arquitetura do Bluesky, que depende de servidores de dados pessoais e nós centrais de “relay” em vez de uma rede peer-to-peer completa, é examinada quanto ao modo como equilibra descentralização, capacidade de pesquisa e implementação prática em escala. Os comentadores contrastam-na com ActivityPub/Mastodon e Nostr, debatendo modelos de identidade (domínios vs chaves públicas), moderação e resistência à censura, o custo e a fragilidade da auto-hospedagem, e desafios de onboarding como a escolha de um servidor. Outros questionam se algum destes desenhos técnicos importa para a adoção em massa, argumentando que efeitos de rede, posicionamento do produto e qualidade do conteúdo acabarão por determinar se o Bluesky conseguirá substituir de forma significativa plataformas ao estilo do Twitter.

P2P vs Arquitetura Federada vs Centralizada

  • Vários comentadores observam que o modelo do Bluesky se parece menos com P2P puro e mais com a web ou o GitHub: servidores de “dados pessoais” do utilizador mais uma infraestrutura maior para agregação.
  • Os críticos argumentam que os relays/“big graph servers” do Bluesky criam pontos inevitáveis de controlo central; os defensores dizem que os relays são “busses” encaixáveis e que os PDSes podem ligar-se a muitos relays ou diretamente, portanto a autoridade não é fixa.
  • Alguns sugerem que um P2P verdadeiro com publicações autenticadas e eliminação eventual é possível, mas na prática é difícil de impor.

Descoberta, Pesquisa e Escala

  • Um lado argumenta que serviços grandes de indexação/pesquisa não são estritamente necessários; grafos sociais, tags e vistas de “amigos de amigos” podem oferecer descoberta em escala humana.
  • Outros insistem que a pesquisa global (por hashtag/tópico, em milhões de utilizadores) é essencial para muitos casos de uso reais e inevitavelmente exige armazenamento pesado e indexação centralizada.
  • A replicação total ao estilo do Fediverse é criticada por ser ambiental e tecnicamente cara em escala global.

Comparações com ActivityPub / Mastodon / Nostr

  • O ActivityPub é visto como viável, mas falho na prática: migração de contas deficiente, múltiplas identidades por tipo de app, falta de modo cliente-servidor amplamente usado e nenhuma forma fácil de “traga o seu próprio domínio” nas principais implementações.
  • Ecossistema do Mastodon: muitos nós, mas alguns grandes dominam devido a custos, conveniência e gravidade social. Instâncias pequenas/autogeridas podem parecer isoladas porque só veem os dados que solicitaram explicitamente.
  • O Nostr é elogiado por uma especificação central simples, mas criticado pela identidade baseada em chave privada, que muitos consideram inutilizável para utilizadores comuns e culturalmente ligada a comunidades de “crypto”.

Identidade: Domínios vs Chaves Públicas

  • A identidade baseada em DNS do Bluesky (handles como hostnames, muitas vezes no próprio domínio) é amplamente apreciada; há discussão sobre simples redirecionamentos HTTP ou CNAME de domínios pessoais para perfis.
  • Alguns receiam que domínios sejam escassos, expirem e centralizem o controlo em registos e registrars; defendem identidades de chave pública como âncoras duráveis e independentes da localização do armazenamento.
  • Outros contrapõem que as chaves são ilegíveis, difíceis de digitar e sem significado para utilizadores normais; nenhum esquema único satisfaz totalmente memorização, descentralização e segurança.

Moderação, Poder e Objetivos

  • Narrativas em confronto: Bluesky como resposta a bans de alto perfil vs Bluesky como tentativa de tornar os fornecedores “substituíveis” e reduzir a captura da plataforma, não de eliminar a moderação.
  • Há tensão entre querer sistemas resistentes à censura e reconhecer que qualquer infraestrutura financiada por anúncios ou centralizada tende a acumular poder de moderação.

Posicionamento do Produto e Experiência do Utilizador

  • Alguns veem o Bluesky como “Twitter mais lento” com diferenciação pouco clara e pesquisa fraca; outros valorizam precisamente esse ambiente mais lento, menos algorítmico e com menor toxicidade.
  • Uma crítica-chave é que os programadores se focam em minúcias do protocolo enquanto negligenciam o posicionamento de mercado e modelos de negócio de longo prazo.
  • A descoberta de conteúdo de qualidade continua a ser um ponto doloroso: sem um grafo social forte ou algoritmos, novos utilizadores têm dificuldade em encontrar feeds que valham a pena.

Obstáculos Técnicos a um P2P Verdadeiro

  • Para além de NAT/firewalls, os comentadores destacam os limites de bateria e largura de banda dos telemóveis: ligações ponto a ponto sempre ativas exigem keepalives frequentes, o que é dispendioso.
  • Frameworks existentes de travessia de NAT (ICE/WebRTC, redes overlay) ajudam, mas acrescentam complexidade; não existe um “equivalente P2P de TCP/IP” universalmente disponível.
  • Alguns argumentam que grande parte da complexidade arquitetural do Bluesky é motivada por contornar estas restrições reais de implementação.