paint-brush
Uma olhada no protocolo AT da BlueSky me ajudou a entender por que ele precisa existirpor@thebojda
1,716 leituras
1,716 leituras

Uma olhada no protocolo AT da BlueSky me ajudou a entender por que ele precisa existir

por Laszlo Fazekas15m2025/01/11
Read on Terminal Reader
Read this story w/o Javascript

Muito longo; Para ler

Descubra o BlueSky, a alternativa federada ao Twitter, alimentada pelo inovador Protocolo AT. Aprenda sobre sua estrutura descentralizada, sistema de repositório, integração DID e recursos exclusivos que priorizam a liberdade e a autenticidade do usuário. Explore como o BlueSky pode moldar o futuro das mídias sociais.

People Mentioned

Mention Thumbnail

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - Uma olhada no protocolo AT da BlueSky me ajudou a entender por que ele precisa existir
Laszlo Fazekas HackerNoon profile picture
0-item
1-item


Em 2022, Elon Musk adquiriu o Twitter, que desde então foi renomeado como X. Esta parte da história é amplamente conhecida. No entanto, poucas pessoas sabem que um projeto para descentralizar a plataforma estava tomando forma dentro do Twitter. Este projeto, chamado BlueSky , foi lançado em 2019. Em 2021, ele foi desmembrado na Bluesky Social Benefit Corporation, permitindo que continuasse independentemente do Twitter. De certa forma, o BlueSky pode ser considerado um sucessor do Twitter tanto quanto o X.


X é um serviço fortemente com fins lucrativos, oferecendo validação paga e recursos premium. Em contraste, BlueSky é um sistema completamente aberto construído em protocolos abertos semelhantes ao Fediverse , consistindo em uma multidão de nós independentes.


Como a equipe BlueSky não estava satisfeita com o padrão ActivityPub , eles desenvolveram seu próprio protocolo, chamado Protocolo AT .


O elemento central do protocolo é o repositório, que é semelhante a um banco de dados. É onde postagens, curtidas e todos os outros dados são armazenados. Cada usuário (ou qualquer entidade) tem um repositório. O repositório contém coleções (semelhantes a tabelas de banco de dados), e as coleções contêm registros em um formato de chave-valor. O repositório armazena dados como IPFS . Cada registro tem um CID , que é um hash baseado em conteúdo. Se um usuário modificar qualquer coisa no banco de dados, um hash de confirmação é gerado a partir dos dados (semelhante a uma confirmação do Git). Mesmo uma única alteração de bit no banco de dados resulta em um novo hash de confirmação. O proprietário do repositório assina digitalmente esse hash de confirmação após cada alteração, autenticando assim o banco de dados.


A vantagem dessa solução é que todo o repositório ou suas partes podem ser transferidos livremente entre sistemas, mantendo a capacidade de qualquer sistema verificar facilmente a autenticidade dos dados.


Os usuários podem hospedar seu repositório em um Personal Data Server (PDS) de sua escolha. Nesse sentido, o PDS funciona como um servidor de banco de dados. Por meio do PDS, os usuários podem modificar seu repositório e torná-lo acessível a outros. Além disso, o PDS fornece uma ampla gama de serviços adicionais. Ele permite acesso aos dados de outros usuários, recupera feeds e muito mais. Essencialmente, o PDS serve como um nó de mídia social totalmente funcional, permitindo que os usuários se conectem à rede.


Como o PDS é meramente o sistema que executa o repositório, os usuários têm a liberdade de mover seu repositório entre diferentes PDSs ou até mesmo operar seu próprio PDS. Essa flexibilidade é o que fornece ao sistema sua liberdade.


O conteúdo dos repositórios armazenados em PDSs é monitorado por geradores de feed, que criam feeds com base em critérios específicos. Em outras plataformas de mídia social (por exemplo, Facebook), geralmente há apenas um feed, mas no caso do BlueSky, os usuários são livres para escolher de qual feed desejam ver as postagens. Se um usuário sentir que um gerador de feed não está mostrando postagens relevantes aos seus interesses, está censurando postagens que ele deseja ver ou está tentando manipulá-las, ele pode simplesmente mudar para um provedor de feed diferente.


Essa rede frouxa de sistemas e a facilidade de transferência de repositórios fornecem liberdade completa sem sacrificar a eficiência. Por exemplo, o cliente não precisa reunir posts de várias fontes, pois isso é tratado pelo gerador de feed e pelo PDS.


Agora que entendemos a estrutura e os principais componentes do sistema, vamos nos aprofundar um pouco mais e ver como o protocolo funciona.


Cada usuário (e outras entidades) recebe um identificador descentralizado (DID) exclusivo. Esse DID é associado ao repositório e ao par de chaves usado pelo usuário para assinar commits do repositório. Como os DIDs são difíceis de lembrar, os usuários são identificados por nomes de domínio, que o sistema traduz em DIDs.


Por exemplo, meu nome de usuário é thebojda.bsky.social . O DID pode ser vinculado a isso de duas maneiras: especificando-o no registro TXT do domínio com a chave apropriada ou simplesmente por meio do URI bem conhecido. O DID pode ser acessado nesta URL:


 https://thebojda.bsky.social/.well-known/atproto-did


Por exemplo, meu DID é: did:plc:4x7rynvskplz54p5pofj3jxa


O Protocolo AT suporta DIDs do tipo plc e web . Um DID web é uma URL simples, enquanto o DID plc é um padrão personalizado do Protocolo AT, gerado a partir da chave pública e alguns dados adicionais (os interessados em um mergulho mais profundo podem ler mais sobre isso aqui ).


Cada DID é associado a um documento DID, que contém a chave pública vinculada ao DID e a URL do PDS onde o repositório está hospedado.


Um DID pode ser resolvido assim:


 https://plc.directory/did:plc:4x7rynvskplz54p5pofj3jxa


O documento DID se parece com isto:


 { "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/multikey/v1", "https://w3id.org/security/suites/secp256k1-2019/v1" ], "id": "did:plc:4x7rynvskplz54p5pofj3jxa", "alsoKnownAs": [ "at://thebojda.bsky.social" ], "verificationMethod": [ { "id": "did:plc:4x7rynvskplz54p5pofj3jxa#atproto", "type": "Multikey", "controller": "did:plc:4x7rynvskplz54p5pofj3jxa", "publicKeyMultibase": "zQ3shaNKzE66K1Kr3dmbnDwXWHh6v4nUcBmpEaK7bVktKTwfh" } ], "service": [ { "id": "#atproto_pds", "type": "AtprotoPersonalDataServer", "serviceEndpoint": "https://fibercap.us-west.host.bsky.network" } ] }


Neste documento, a URL do PDS deve ser atualizada se alguém mudar para um novo PDS. Por exemplo, meu PDS atual está acessível em https://fibercap.us-west.host.bsky.network .


A comunicação com o PDS é feita por meio do XRPC , um protocolo simples baseado em HTTP/JSON. Cada chamada tem um nome de estilo DNS reverso. Por exemplo, se eu quiser buscar meu repositório inteiro, posso fazer assim:


 https://fibercap.us-west.host.bsky.network/xrpc/com.atproto.sync.getRepo?did=did:plc:4x7rynvskplz54p5pofj3jxa


O método com.atproto.sync.getRepo é usado para consultar o repositório e tem um parâmetro did .


A equipe BlueSky desenvolveu uma linguagem descritiva baseada em JSON chamada Lexicon para definir a API e as estruturas de dados. Ela é similar ao JSON Schema e pode ser usada para gerar interfaces de tipo seguro, por exemplo, para TypeScript, o que simplifica a implementação do protocolo.


A seguinte chamada pode ser usada para buscar minhas últimas 10 postagens:


 https://public.api.bsky.app/xrpc/app.bsky.feed.getAuthorFeed?actor=thebojda.bsky.social&limit=10


O resultado fica assim:


 { "feed": [ { "post": { "uri": "at://did:plc:4x7rynvskplz54p5pofj3jxa/app.bsky.feed.post/3le3esbhaek2l", "cid": "bafyreihagjnwrkakkajkaighz6kyqww3wznvbdcqpnl4wbfnpwrr2xwmmi", "author": { "did": "did:plc:4x7rynvskplz54p5pofj3jxa", "handle": "thebojda.bsky.social", "displayName": "Laszlo Fazekas", "avatar": "https://cdn.bsky.app/img/avatar/plain/did:plc:4x7rynvskplz54p5pofj3jxa/bafkreibxd4mx7rehgkc77diautavpcota6jotzkaagp4zv2t6w3a52n7sq@jpeg", "labels": [], "createdAt": "2024-11-24T01:36:39.146Z" }, "record": { "$type": "app.bsky.feed.post", "createdAt": "2024-12-24T21:20:56.891Z", "embed": { "$type": "app.bsky.embed.external", "external": { "description": "MyETHMeta is a decentralized metadata service for Ethereum accounts. It is something like Gravatar. There are no backend servers, you fully own your data.", "thumb": { "$type": "blob", "ref": { "$link": "bafkreifoezhkdtesuhkaoqt3yml44geozu6ckg2cfffg5t5omob2bdjmo4" }, "mimeType": "image/jpeg", "size": 669185 }, "title": "MyETHMeta v2 – Some Improvements on the Gravatar for Your Ethereum Account | HackerNoon", "uri": "https://hackernoon.com/myethmeta-v2-some-improvements-on-the-gravatar-for-your-ethereum-account" } }, "facets": [ { "features": [ { "$type": "app.bsky.richtext.facet#link", "uri": "https://hackernoon.com/myethmeta-v2-some-improvements-on-the-gravatar-for-your-ethereum-account" } ], "index": { "byteEnd": 270, "byteStart": 240 } } ], "langs": [ "en" ], "reply": { "parent": { "cid": "bafyreieipk3kgwonq3h62wyadauplzgcpdgcg6pxp2776oeldcstgybwha", "uri": "at://did:plc:4x7rynvskplz54p5pofj3jxa/app.bsky.feed.post/3le3es7kzmc2l" }, "root": { "cid": "bafyreieipk3kgwonq3h62wyadauplzgcpdgcg6pxp2776oeldcstgybwha", "uri": "at://did:plc:4x7rynvskplz54p5pofj3jxa/app.bsky.feed.post/3le3es7kzmc2l" } }, "text": "MyETHMeta is a decentralized metadata service for Ethereum accounts. It is something like Gravatar, but here the metadata and your profile picture is assigned to your Ethereum address. There are no backend servers, you fully own your data. hackernoon.com/myethmeta-v2..." }, "embed": { "$type": "app.bsky.embed.external#view", "external": { "uri": "https://hackernoon.com/myethmeta-v2-some-improvements-on-the-gravatar-for-your-ethereum-account", "title": "MyETHMeta v2 – Some Improvements on the Gravatar for Your Ethereum Account | HackerNoon", "description": "MyETHMeta is a decentralized metadata service for Ethereum accounts. It is something like Gravatar. There are no backend servers, you fully own your data.", "thumb": "https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:4x7rynvskplz54p5pofj3jxa/bafkreifoezhkdtesuhkaoqt3yml44geozu6ckg2cfffg5t5omob2bdjmo4@jpeg" } }, "replyCount": 0, "repostCount": 0, "likeCount": 0, "quoteCount": 0, "indexedAt": "2024-12-24T21:21:02.466Z", "labels": [] }, "reply": {} }, {}, {}, {}, {}, {}, {}, {}, {} ] }


Cada elemento contém uma postagem e suas respostas associadas. Conforme mencionado anteriormente, cada postagem é um registro no repositório e tem seu próprio identificador exclusivo. Cada postagem pode receber um URI exclusivo, que consiste no DID, no nome da coleção e no ID da postagem. No exemplo acima, o URI se parece com isto: at://did:plc:4x7rynvskplz54p5pofj3jxa/app.bsky.feed.post/3le3esbhaek2l


Isso significa que a postagem está localizada no repositório associado ao meu DID, dentro da coleção app.bsky.feed.post e seu ID é 3le3esbhaek2l .


Além do URI, o CID do post também está incluído, que é um hash exclusivo gerado a partir do conteúdo. Esses elementos juntos formam o hash de commit exclusivo do repositório.


Outro aspecto digno de nota é a seção thumb , que se refere a uma imagem associada ao post. Este é um objeto do tipo blob que não pertence a nenhuma coleção. O sistema armazena arquivos grandes (como imagens, vídeos, etc.) como blobs, que podem ser referenciados em registros individuais (por exemplo, posts) usando seu hash (CID).


Para aqueles interessados em uma visão mais profunda da estrutura do repositório e dos registros, a ferramenta go-repo-export pode ser bem útil. Com esse pequeno programa, você pode baixar todo o repositório do usuário e extrair as coleções e seus registros em um diretório no formato JSON. Isso permite que você veja exatamente como o BlueSky armazena os dados.


Outra boa fonte de informação é o Chrome DevTools. No site https://bsky.app , você pode ver claramente as chamadas de API e como o lado do cliente se comunica com o PDS.


E, claro, há a documentação oficial. O AT Protocol e o BlueSky têm uma documentação excelente, e no GitHub , você pode encontrar exemplos, bem como o código-fonte para os lados do cliente e do servidor.


Quando li pela primeira vez sobre o Protocolo AT, meu pensamento inicial foi por que precisamos de mais um protocolo federado junto com o ActivityPub . No entanto, o Protocolo AT de fato tem certos recursos que justificam totalmente sua existência. O protocolo, é claro, não é perfeito e provavelmente passará por um desenvolvimento significativo. Por exemplo, se quisermos construir uma rede verdadeiramente resistente à censura, ela não pode depender de um sistema de nome de domínio centralizado. Um sistema de nomenclatura baseado em blockchain, que seja genuinamente resistente à censura, seria valioso (talvez eu até escreva uma proposta sobre isso).


Atualmente, a BlueSky tem uma estimativa de 20 a 30 milhões de usuários, o que empalidece em comparação à base de usuários do X (Twitter), mas ainda é significativo. Quanto ao que o futuro reserva, ninguém pode dizer com certeza. A rede federada é uma grande vantagem, e há debates intensos sobre se é muito poder para uma entidade possuir uma plataforma de comunicação global como o Twitter ou o Facebook. Eu não descartaria completamente a possibilidade de que a BlueSky possa um dia superar seus concorrentes. Com bons geradores de feed e construção de comunidade eficaz, isso é possível. Em qualquer caso, vale a pena prestar atenção a este projeto e entender como ele funciona.