Por que a AT Protocol DID é a identidade que o Bluesky nunca perde

O que é uma AT Protocol DID?

Toda conta do Bluesky carrega uma AT Protocol DID, um identificador persistente que o AT Protocol atribui uma vez e nunca reatribui a outra conta. A própria especificação do protocolo chama a DID de "primary account identifier in atproto" ("identificador principal de conta no atproto"), construída sobre o padrão W3C de identificador descentralizado, e uma DID típica se parece com isto: did:plc:ewvi7nxzyoun6zhxrhs64oiz. Trate a DID como o nome real da conta e o handle como um apelido que pode mudar ao redor dela.

O que são did:plc e did:web, e como eles se diferenciam?

O AT Protocol suporta exatamente dois métodos de DID, did:plc e did:web, e cada um resolve um identificador para os dados de uma conta de um jeito diferente. did:plc é um método construído especificamente para o AT Protocol e é autoautenticável, o que significa que o próprio identificador carrega informação criptográfica suficiente para verificar seu próprio histórico sem confiar em uma autoridade central além do diretório que o hospeda. did:web é um método da comunidade W3C que amarra o identificador diretamente a um nome de host via HTTPS, o que significa que a identidade da conta agora depende desse domínio permanecer sob o controle do mesmo dono.

O que é o diretório PLC e quem o administra?

O diretório PLC é um registro público e gratuito que resolve identificadores did:plc para seus documentos DID atuais, e a Bluesky Social PBC o construiu e opera como infraestrutura para a rede AT Protocol como um todo, não como um serviço exclusivo do Bluesky. O diretório se descreve como "strongly consistent, recoverable, and allows for key rotation" ("fortemente consistente, recuperável, e que permite rotação de chave"), usando registros de operação autocertificados que qualquer pessoa pode verificar criptograficamente, em vez de uma blockchain ou sistema de tokens. Em outubro de 2024, o diretório hospedava mais de doze milhões de identificadores registrados, segundo sua própria documentação.

Como uma DID se diferencia de um handle do Bluesky?

Uma DID é o identificador estável que nunca muda, enquanto um handle é um nome de usuário legível por humanos, baseado em DNS, que o próprio guia de protocolo do Bluesky trata explicitamente como reatribuível. O objetivo de design do protocolo é que as identidades permaneçam "portable across services" ("portáveis entre serviços"), então trocar de provedor ou de domínio "should not cause a user to lose their identity, social graph, or content" ("não deveria fazer um usuário perder sua identidade, seu grafo social ou seu conteúdo"). O handle é o que as pessoas veem e digitam, mas todo follow, post e interação no backend ainda aponta para a DID por trás dele.

Por que um handle pode mudar enquanto a DID permanece a mesma?

Um handle pode mudar porque ele funciona como um ponteiro para a conta, não como o endereço real da conta, então atualizar um handle de nome de domínio ou trocar de provedor de hospedagem só reescreve o ponteiro, não a identidade para a qual ele aponta. Um usuário que verifica um domínio próprio como seu handle, e depois abre mão desse domínio, pode atualizar seu handle de novo sem perder seguidores, posts ou histórico, porque cada um desses registros esteve ligado à DID o tempo todo. Essa separação é o mesmo motivo pelo qual uma senha de aplicativo do Bluesky pode ser revogada e reemitida sem tocar na identidade subjacente da conta: a revogação muda as credenciais de acesso, não a conta em si.

Como você resolve uma AT Protocol DID na prática?

Resolver uma DID significa transformar um handle em uma DID e depois transformar essa DID em um documento DID completo, e o próprio guia do AT Protocol detalha as duas etapas. A resolução de handle para DID funciona por meio de um registro DNS TXT em _atproto.<handle> ou por meio de um endpoint well-known de HTTPS no domínio do handle. Depois de ter a DID em si, uma did:plc se resolve por meio de um simples HTTP GET ao diretório PLC, como https://plc.directory/did:plc:ewvi7nxzyoun6zhxrhs64oiz, enquanto uma did:web se resolve diretamente pelo domínio de hospedagem. Qualquer um dos dois caminhos retorna um documento DID listando o handle atual da conta, a chave de assinatura e a URL do servidor de dados pessoal que hospeda seu conteúdo.

Por que isso importa para rastrear contas do Bluesky ao longo do tempo?

DIDs importam para rastrear contas do Bluesky ao longo do tempo porque um registro baseado só no handle quebra no momento em que alguém renomeia sua conta, enquanto um registro baseado em DID continua apontando para a mesma conta não importa quantas vezes o handle mude. Qualquer ferramenta construída sobre coleta de dados de redes sociais no Bluesky deveria resolver e guardar a DID junto com o handle, não o handle sozinho, ou menções históricas e dados de seguidores vão se desconectar silenciosamente de contas que renomeiam seu handle depois. O monitoramento do Bluesky da RedReplier rastreia menções no nível da conta exatamente por esse motivo, então uma conversa rastreada permanece atribuída à conta certa mesmo depois de uma mudança de handle.

Perguntas frequentes

Uma conta do Bluesky pode ter mais de uma DID?

Não. Cada conta do Bluesky é criada com exatamente uma DID que permanece fixa durante toda a vida dessa conta, e alternar entre did:plc e did:web não é uma operação suportada depois que uma conta já existe em um método.

O que acontece com uma DID se alguém deletar sua conta do Bluesky?

O documento DID pode ser marcado como tombstoned (com lápide) ou desativado dependendo do método de DID, mas o identificador em si não é reatribuído a uma nova conta depois disso. A DID de uma conta deletada não fica disponível para outra pessoa reivindicar.

Uma conta did:web é menos segura que uma conta did:plc?

Não é inerentemente menos segura, mas did:web amarra a continuidade da conta a manter o controle de um domínio específico, sem um caminho de recuperação embutido caso esse domínio seja perdido, enquanto did:plc suporta rotação de chave e recuperação por meio dos próprios mecanismos do diretório PLC. A compensação é independência de domínio contra recuperabilidade embutida.

Preciso entender DIDs para usar o Bluesky como usuário comum?

Não. A interface do Bluesky só mostra handles durante o uso normal, e a resolução da DID acontece automaticamente por trás das cenas. Entender DIDs importa principalmente para desenvolvedores, pesquisadores e qualquer pessoa que construa ferramentas em cima do AT Protocol.

Posso consultar eu mesmo a DID de qualquer conta do Bluesky?

Sim. Resolver um handle para sua DID usa uma consulta DNS TXT ou uma requisição well-known de HTTPS, ambas públicas e sem exigir acesso especial, e o próprio diretório PLC é um serviço público e consultável para contas did:plc.

Mudar o handle do Bluesky afeta os resultados de busca dessa conta?

O comportamento de busca depende de como uma determinada ferramenta indexa contas, mas o AT Protocol em si resolve menções e follows por meio da DID, não do handle, então uma implementação bem construída de operadores de busca do Bluesky deveria continuar retornando resultados para uma conta depois que ela mudar seu handle.

Como é, na prática, uma AT Protocol DID?

Uma AT Protocol DID segue o formato did:plc:... ou did:web:..., construído sobre o padrão W3C de identificadores descentralizados. Um exemplo real, tirado da própria documentação do protocolo, é did:plc:ewvi7nxzyoun6zhxrhs64oiz. O prefixo indica o método que a atribuiu, plc ou web, e tudo depois dele é uma string gerada ou um nome de domínio.

Que informações ficam armazenadas em um documento DID?

Um documento DID lista o handle atual da conta, sua chave de assinatura e a URL do servidor de dados pessoal que hospeda seu conteúdo. Resolver uma DID, pelo diretório PLC no caso de did:plc ou pelo domínio de hospedagem no caso de did:web, devolve exatamente esse documento. O endereço do PDS contido nele é o que um cliente usa para buscar de fato os posts e os dados de uma conta.

Por que o AT Protocol tem dois métodos de DID em vez de um só?

O AT Protocol suporta did:plc e did:web porque cada um cede algo diferente. did:plc é autoautenticável e permite recuperar a conta por rotação de chaves no diretório PLC, enquanto did:web entrega a posse total do identificador a quem controla um domínio, sem nenhuma forma embutida de recuperação caso esse domínio se perca. Oferecer os dois deixa cada titular escolher entre portabilidade e recuperação, ou independência do próprio domínio, conforme o que importa mais para ele.

Quantas contas o diretório PLC tem registradas?

Segundo sua própria documentação, em outubro de 2024 o diretório PLC tinha mais de doze milhões de identificadores registrados. A Bluesky Social PBC opera o diretório como infraestrutura para toda a rede do AT Protocol, não apenas como um serviço da sua própria aplicação. O diretório usa registros de operações autocertificados que qualquer pessoa pode verificar de forma criptográfica, sem blockchain nem sistema de tokens.