Marcas Registradas do Bluesky no ATProto

Artigo original ↗ Discussão no Hacker News ↗

A aquisição, pelo Bluesky, da marca registrada “AT Protocol”, ostensivamente para bloquear outra empresa de restringir o uso pela comunidade, renovou o escrutínio sobre quão descentralizado o ecossistema do AT Protocol realmente é. Comentadores debatem se o controle do Bluesky sobre componentes-chave como o diretório de identidade PLC, grandes relays e o aplicativo cliente dominante deixa a rede efetivamente centralizada, apesar do projeto do protocolo para hospedagem e aplicativos independentes. Outros apontam implementações alternativas, o trabalho em andamento de padronização na IETF e infraestrutura de terceiros como evidência de que o ecossistema pode evoluir além de um único mantenedor corporativo, desde que a governança e as ferramentas de migração melhorem.

Origem e propósito da marca registrada

  • Outra empresa (Atsign, Inc.) havia registrado “ATPROTOCOL” e supostamente estava ameaçando ações legais contra o uso por terceiros.
  • O Bluesky adquiriu a marca para impedir que essa entidade restringisse o uso pela comunidade e agora a licencia para outros projetos.
  • Alguns veem isso como uma medida defensiva pragmática; outros se preocupam com o controle de longo prazo, mesmo havendo indícios de que ela possa depois ser transferida para uma organização neutra.

Governança, PLC e independência

  • O ATProto está sendo padronizado por meio de um grupo de trabalho da IETF; alguns inicialmente não tinham certeza se a IETF ou grupos de trabalho podem deter marcas registradas.
  • O Bluesky é uma public benefit corporation, mas comentaristas observam que isso não garante decisões centradas no usuário.
  • O diretório de identidade PLC ainda é visto como um ponto central de controle; a transferência para uma organização separada de governança é vista como algo já atrasado.
  • Há preocupação de que sanções dos EUA ou pressões semelhantes possam levar a uma desativação em nível de identidade.

“Instâncias”, topologia e centralização

  • Um grande fio debate se é correto dizer que o Bluesky opera a “única instância viável”.
  • Lado pró-ATProto: não existem “instâncias” no sentido do Mastodon; hospedagem (PDS), indexação/relays e aplicativos são desacoplados; qualquer pessoa pode executar cada parte, e várias pilhas independentes já existem.
  • Críticos: na prática, a maior parte dos dados e do tráfego ainda passa pela infraestrutura do Bluesky, então a centralização efetiva continua alta.

Auto-hospedagem, DIDs e migração

  • Usuários podem auto-hospedar PDSs e usar did:web para evitar o PLC, mas DIDs são imutáveis: não é possível migrar de did:plc para did:web sem perder seu grafo.
  • Isso é visto como uma limitação importante para quem começou na configuração padrão do Bluesky.
  • As ferramentas de interface gráfica para migração de PDS melhoraram, mas a migração de DID continua sem solução.

Wsocial e limitação de taxa

  • O lançamento problemático do Wsocial é citado como evidência de controle central: o tráfego deles atingiu limites de taxa do relay e eles praticamente não conseguiram participar sem coordenação.
  • Outros contrapõem que limitação de taxa e coordenação entre operadores são normais em sistemas federados (comparando com Mastodon e e-mail) e que existem outros relays e índices.

Comparações com ActivityPub e Nostr

  • Alguns argumentam que ActivityPub/Nostr são mais claramente descentralizados e mais fáceis/baratos de implantar.
  • Defensores do ATProto respondem que o ATProto visa um conjunto diferente de problemas (camada de dados compartilhada em grande escala, portabilidade de aplicativos), mais próximo de “RSS tipado”, e que vários aplicativos e serviços que não são do Bluesky já operam sobre a pilha.

Confusão com o antigo “AT protocol”

  • Um fio paralelo menciona o antigo conjunto de comandos do modem “AT”, às vezes informalmente chamado de “AT protocol”, mas a maioria concorda que isso não afeta a marca registrada na prática.