Como o BlueSky funciona

• O BlueSky é um app de microblog parecido com Twitter e Mastodon, mas seu objetivo maior é verificar se aplicações sociais distribuídas em larga escala são viáveis sobre o AT Protocol (atproto)
• O atproto não é blockchain, DAO nem NFT; é um protocolo federado em que registros assinados pelo usuário são processados de forma distribuída por PDS, Relay e App View com uso de criptografia e Merkle tree, entre outras técnicas
• A escalabilidade vem de uma arquitetura em que o Personal Data Server (PDS) do usuário não envia posts diretamente a todos os seguidores; em vez disso, o Relay agrega os dados da rede e os oferece como firehose
• A moderação é dividida no modelo “speech vs reach”, separando a replicação do conteúdo do controle de exposição, com labeler, feed generator e App View aplicando filtros e bloqueios
• DID estável e handle baseado em domínio oferecem portabilidade de conta, mas o serviço de resolução did:plc operado pelo BlueSky continua sendo um ponto de debate sobre centralização

---

Relação entre BlueSky e atproto

• O BlueSky hoje funciona como uma aplicação de microblog, mas, no plano geral, é a aplicação inicial que demonstra o potencial do Authenticated Transfer Protocol, ou atproto
• O site do BlueSky afirma que “as redes sociais são importantes demais para serem controladas por algumas empresas, e estamos construindo uma base aberta para uma internet social em que todos possam ajudar a criar o futuro”
• Como o BlueSky é uma empresa, pode haver uma visão cética de que “uma empresa está criando algo que não deveria ser controlado por empresas”, mas o núcleo do projeto está mais no atproto do que no app
• O atproto é um protocolo federado para aplicações sociais distribuídas em larga escala

Um protocolo distribuído, não uma criptomoeda

• O atproto pode parecer algo ligado a criptomoedas por usar expressões como “rede distribuída” e “protocolo”, mas não é uma criptomoeda
• Não é blockchain, DAO nem NFT, embora use algumas técnicas como criptografia e Merkle tree

Estrutura básica do atproto

• O atproto adota uma estrutura federada em que vários participantes operam partes diferentes do sistema e se comunicam entre si
• Pensando em uma base de usuários grande, ele foi projetado para dar mais responsabilidades a quem consegue lidar com a carga e reduzir o peso sobre quem não consegue
• No momento citado no texto, o BlueSky havia passado de 5 milhões de usuários naquela semana e era avaliado como muito mais estável do que o Twitter inicial
• Atualmente, o atproto é 100% público e não tem recursos como mensagens privadas
  • Como é difícil implementar bem funções privadas em um sistema federado, a escolha foi fazer isso direito em vez de lançar algo com limitações sérias
  • Por enquanto, ele é mais adequado para conteúdos que podem ser públicos

Registros, repositório, App View e Relay

• O usuário cria um record assinado criptograficamente, e essa assinatura prova a autoria
• O record segue um esquema chamado Lexicon
• O record é armazenado em um repository, que funciona como um serviço expondo HTTP e WebSocket
  • Esse tipo de serviço normalmente é chamado de PDS (Personal Data Server)
  • O usuário pode operar o próprio PDS ou usar um PDS hospedado por outra pessoa
• As aplicações leem os records armazenados na rede e constroem funcionalidades sobre eles
  • Como esse tipo de serviço expõe uma determinada visão das informações, ele é chamado de App View
  • Criar uma aplicação significa definir um Lexicon, ler os records que usam esse Lexicon e ignorar o restante
• Um modelo em que os PDS notificam uns aos outros diretamente tem grandes problemas de escalabilidade
  • Se, a cada novo post, ele precisasse ser enviado diretamente ao repository de todos os seguidores, isso seria ineficiente e encareceria a operação de repositories populares
• O Relay reduz esse problema reunindo as informações da rede e expondo tudo como firehose
  • Na prática, a App View olha para o Relay em vez de consultar diretamente os repositories
  • Quando o autor publica algo, o repository avisa o Relay, e os seguidores veem o resultado da filtragem que a App View faz da saída do Relay
  • O Relay pode ser grande e caro de operar, mas também é possível imaginar Relays menores que propagam apenas um subconjunto específico de usuários

Modelo de moderação “speech vs reach”

• Como o atproto é um protocolo para aplicações sociais, ele considera não só como conectar pessoas, mas também como desconectá-las
• O modelo de moderação do BlueSky é dividido em speech vs reach
  • A camada de speech replica o conteúdo pela rede sem considerar seu significado
  • A camada de reach oferece ferramentas para limitar o alcance daquilo que o usuário não quer ver
• Dizer que o BlueSky “não faz moderação” ou que “só valoriza liberdade de expressão” é impreciso
  • As ferramentas de moderação fazem parte do próprio protocolo e podem funcionar também em conteúdos de aplicações que não sejam o BlueSky
  • O usuário não fica preso às escolhas de moderação de outras pessoas nem à ausência delas; ele pode escolher seus próprios moderadores

Feed generator

• No atproto, os feeds são separados em um serviço próprio chamado feed generator
• O feed generator recebe o firehose produzido pelo Relay e mostra listas ao filtrar e ordenar o conteúdo conforme os critérios desejados
• O usuário pode compartilhar com outros usuários os feeds que criou
• Exemplos de feed:
  • Quiet Posters: mostra posts de pessoas que não publicam com frequência
  • the ‘Gram: mostra apenas posts com fotos anexadas
  • My Bangers: mostra seus posts mais populares
• Um dos pontos fortes do BlueSky é permitir que o usuário crie seu próprio feed algorítmico e o compartilhe com facilidade
• Feed é uma função relativamente recente no atproto, então talvez ainda não esteja completa e possa mudar no futuro

Labeler e moderação em nível de rede

• O Labeler é um serviço que aplica labels a conteúdos ou contas
• O usuário pode assinar um labeler específico e fazer sua experiência variar conforme os labels dos posts
• O labeler pode funcionar da forma que seu operador quiser
  • Pode executar algoritmos automáticos nos posts
  • Pode ter aprovação ou rejeição humana
  • Pode ser usado como blocklist ou filtro de NSFW
• A função de label existe, mas, no momento descrito no texto, não estava claro se usuários poderiam executar seu próprio labeler diretamente
  • O BlueSky opera seu próprio labeler
  • Ainda não havia uma liberação externa conhecida
• Ao combinar feed, App View e labeler, o usuário pode escolher sua experiência de moderação dentro e fora da aplicação
  • Em um feed, pode ver apenas conteúdo SFW; em outro, pode permitir conteúdo NSFW
  • Pode criar e compartilhar blocklists
• Como as ferramentas de moderação operam no nível do protocolo, e não no da aplicação, o mesmo labeler pode ser usado em outras aplicações sobre atproto
  • Mesmo que surja um clone do Instagram sobre atproto, ele pode usar o mesmo labeler de blocklist
  • Se o usuário quiser, pode bloquear a mesma pessoa em todos os lugares

Diferença em relação ao modelo de instâncias do Mastodon

• O modelo do atproto é diferente do esquema do Mastodon, em que existe uma “conta” dentro de uma “instância” específica
• Perguntas como “o que acontece se minha instância for defederated?” não se aplicam tão diretamente aqui
• Dá para atingir um objetivo parecido ignorando posts vindos de um PDS específico
• Mas essa escolha não é feita pelo dono do servidor em nome da conta do usuário, e sim pelo próprio usuário

DID, handle e portabilidade de conta

• O núcleo da identidade no atproto é o DID (Decentralized Identifier)
  • Um exemplo de DID tem o formato did:plc:3danwc67lo7obz2fmdg6jxcr
• A identidade que o usuário realmente vê também usa um handle, que é um nome de domínio
  • Exemplo: @steveklabnik.com
  • Quem se cadastra no BlueSky pode receber um handle no formato @username.bsky.social
• Como o DID é estável, dá para mudar o handle de @steveklabnik.bsky.social para @steveklabnik.com sem interromper os seguidores; na interface, só o handle muda
• Para usar um domínio como handle, é preciso pegar o DID gerado pelo PDS e adicionar um TXT record no DNS desse domínio
• Mesmo usuários que não conhecem DNS podem registrar um domínio e defini-lo como handle sem conhecimento técnico por meio da parceria entre BlueSky e NameCheap
• A portabilidade da conta se baseia em DID e assinaturas criptográficas
  • O conteúdo criado por quem usa um determinado DID é assinado e replicado na rede
  • Para encerrar uma “conta”, seria preciso forçar a impossibilidade de uso da chave que o usuário possui, mas, pelo desenho da rede, outros participantes não têm acesso a essa chave
  • Mesmo que o PDS saia do ar, é possível fazer backfill do conteúdo na rede e informar que houve migração para um novo PDS

Questões em torno de did:web e did:plc

• O BlueSky oferece suporte a duas formas de DID
  • did:web: abordagem baseada em nome de domínio
  • did:plc: abordagem própria implementada pelo BlueSky
• O plc de did:plc significa “placeholder”, e o BlueSky pretende continuar dando suporte a isso
• O did:plc tem a fraqueza de depender de um serviço operado pelo BlueSky para resolver as informações corretas
  • Um exemplo de consulta pode ser visto em plc.directory
  • Por causa dessa estrutura, há críticas de que o BlueSky pode banir usuários com mais força do que seria originalmente possível pelo desenho da rede
• Há também motivos para não considerar isso fatal
  • Quem não quiser pode usar did:web
  • O sistema foi projetado para permitir migração caso apareça uma opção melhor
  • No futuro, a governança de did:plc pode migrar para um modelo de consenso
  • Outros participantes também podem operar um serviço did:plc e usá-lo

Como o BlueSky se apoia sobre o atproto

• O BlueSky é uma aplicação construída sobre a rede atproto
• O BlueSky opera uma App View e a aplicação web que a utiliza
• Também opera PDS para quem se cadastra pelo app web e o Relay por meio do qual esses PDS se comunicam
• O BlueSky publica dois tipos de Lexicon
  • com.atproto.*: operações de baixo nível necessárias para qualquer aplicação da rede
  • app.bsky.*: operações específicas do BlueSky
• O objetivo do produto BlueSky é permitir que as pessoas usem tudo isso sem precisar conhecer os detalhes técnicos
  • Como não há instâncias, não existe o fluxo de escolher uma instância para criar a conta
  • Mesmo que o host saia do ar, é possível migrar, e os seguidores nem precisam perceber

Criando uma nova aplicação sobre o atproto

• Uma aplicação atproto começa pela criação de um Lexicon
• Depois disso, ela opera uma App View que processa, dentro dos dados da rede, aquilo que se relaciona com esse Lexicon
• A aplicação precisa permitir que o usuário grave dados em seu PDS usando esse Lexicon

A separação central do design

• A separação de papéis entre atproto e BlueSky é um elemento importante do design
• Uma “killer app” como o BlueSky dá às pessoas um motivo para usar a rede
• O próprio BlueSky também cumpre um papel de dogfooding, validando se realmente é possível criar uma aplicação real sobre o atproto

[GN⁺]

Opiniões no Hacker News

• Parece ter sido muito bem projetado e parece resolver alguns dos grandes problemas do ActivityPub
  Antes eu não tinha interesse no Bluesky, mas agora estou pensando em criar uma conta

  • O principal problema do Bluesky e do AT Protocol está menos nos méritos técnicos e mais em uma forte postura NIH (Not invented here)
    Em vez de protocolos existentes que todo mundo usa, como user@host e WebFinger, escolheram “usar domínios como identidade”; e, por não se inspirarem no modo como o ACME já trata isso em certificados, aconteceu até de alguém tomar o domínio s3.amazon.com no Bluesky https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
    Também criaram um novo protocolo de chamada remota, XRPC, e usam o Lexicon, um esquema de dados baseado em geração de código cujas vantagens, além de ser mais novo que protobuf ou jsonld, não são claras
    É difícil confiar em uma “rede aberta” que constantemente mostra não querer respeitar outros ecossistemas nem dialogar com eles, e também fico desconfiado de quantos outros erros comuns de design podem ter sido introduzidos ao rejeitar conhecimento compartilhado
  • O AT Protocol parece tecnicamente melhor, mas socialmente parece ter uma estrutura propensa ao fracasso
    Como não há incentivo social para alguém instalar e manter relays e serviços de moderação separados das comunidades reais, sobram apenas incentivos financeiros, como serviços pagos, inserção de anúncios, mineração de dados e manipulação de informações
    Se a distribuição de dados e a moderação forem centralizadas, tanto os custos de hospedagem quanto os custos humanos viram um grande negócio, e isso caminha para praticamente impedir que alguém que não seja o Bluesky opere seu próprio relay ou serviço de moderação
    Apesar das desvantagens do ActivityPub, uma abordagem como “comunidades com portão” faz com que usuários sintam pertencimento ao servidor e que operadores e moderadores tenham orgulho de prestar um serviço aos usuários
    O AT Protocol permite tecnicamente vários relays e serviços de moderação, mas é questionável quantos vão surgir na prática
    Acho um erro julgar um protocolo de rede social apenas de uma perspectiva puramente técnica e adversarial. Em troca de não ficar preso a um servidor, você também se separa de comunidades coesas, e deixa de haver algo em jogo
    Não ter nada a perder em termos de dados, identidade e comunidade é uma faca de dois gumes

• Pelo que sei, atualmente há apenas um relay
  Se surgirem vários relays, cada um passará a enxergar a rede de forma diferente, e o relay que incluir mais posts será o melhor
  Pode ser bem difícil garantir diversidade de relays em vez de um único relay dominante, e isso se parece com a tentativa de sistemas alternativos de DNS de ganhar tração. Nesse caso, se meu post não for capturado pelo relay dominante, parece que não há o que fazer
  Ainda é muito cedo, então talvez não aconteça assim; e, mesmo que exista um relay dominante, o GitHub também não é tão ruim, e há alternativas

  • Antes o Bluesky me confundia bastante, mas recentemente percebi que a confusão vinha principalmente da terminologia
    Seria mais fácil entender se chamassem o sistema de [microblog] -> [indexador] -> [cliente]
    Na prática há mais elementos, mas o funcionamento básico do Bluesky é mais ou menos esse, só que os nomes parecem ter sido escolhidos de forma diferente do esperado
    O motivo de precisar de um indexador é que o ID do usuário não permanece estático no sistema. O DID:PLC começa como uma substring de um hash, mas por causa da “rotação de chaves” ocorre, com o tempo, um estranho rearranjo criptográfico em que o ID do usuário muda sem que o próprio usuário perceba
    Imagine um sistema como o LiveJournal em que os identificadores mudam o tempo todo e é preciso haver uma autoridade para acompanhar essas mudanças. Claro, só é possível publicar mensagens curtas, sem suporte a títulos ou Markdown
    Pessoalmente, estou esperando um novo DID:PLC que receba uma chave pública estática e assine mensagens com a chave privada. Haveria muito menos coisas a rastrear, e o self-hosting e o desenvolvimento local-first ficariam muito mais fáceis
  • Se necessário, acho que o cliente, o App View, poderia usar vários relays em paralelo
    Seria como uma UI local do GitHub que busca dados de várias instâncias do GitHub hospedando conjuntos de repositórios diferentes, mas possivelmente sobrepostos
    Também se parece com um cliente Usenet que agrega newsgroups de vários servidores NNTP
  • Imagino que todos os relays terão todos os dados, exceto por diferenças de julgamento sobre conteúdo ilegal
    Fico curioso sobre por que você acha que cada relay passaria a enxergar a rede de forma diferente

• O que me pergunto é como o BlueSky pode prometer de forma confiável que vai usar apenas as partes abertas do protocolo
  Como o BlueSky parece, na prática, bastante centralizado, não vejo motivo técnico para que o cliente first-party tenha necessariamente de ser um cliente ATProto
  No curto ou médio prazo, fazer isso seria uma grande traição da confiança dos usuários, mas a estrutura efetivamente distribuída do ActivityPub parece, nesse caso, uma salvaguarda mais forte

  • Não sei o que você quer dizer com cliente first-party do BlueSky
    Se quer dizer que o relay e o PDS first-party poderiam se comunicar por outro protocolo, não entendo bem qual é a preocupação
    Dois clientes ActivityPub também podem conversar entre si por um protocolo que não seja ActivityPub
  • Dá para confiar porque todo o código é open source
    Eles de fato estão fazendo isso e, se começarem a mudar para não fazer, as pessoas perceberão muito rapidamente

• É bom que tenham chegado até a distinção entre “fala e alcance”, mas, no longo prazo, por causa da simplicidade, Mastodon parece uma escolha mais inteligente
  No curto prazo, a curadoria de feeds do Mastodon é claramente mais difícil, então ele pode ser menos divertido ou menos útil
  A pergunta central é: se um agente malicioso hipotético, talvez rico ou poderoso, quisesse bagunçar o jogo aqui, como poderia fazer isso?
  O texto passa rápido demais por essa parte, dizendo algo como “não sabemos bem como o feed funciona”, o que é muito suspeito. Parece que eles sabem muito bem como o feed vai funcionar, sabem que há poder e dinheiro nesse ponto, e querem se agarrar a isso

  • Esse resumo de “não sabemos bem como o feed funciona” não parece adequado
    O autor diz: “Feeds são um recurso recente no atproto, então eles existem, mas talvez ainda não estejam completos e possam mudar no futuro. Vamos acompanhar. Do meu ponto de vista, funcionam bem, mas não estou acompanhando os detalhes técnicos de baixo nível.”
    O parágrafo imediatamente anterior também traz este contexto: “Uma das killer features do BlueSky em comparação com outras ferramentas de microblog é a escolha total do usuário. Se eu quiser criar meu próprio algoritmo de feed, posso criar, e posso compartilhá-lo facilmente com outras pessoas.”
  • Não sei de onde saiu a ideia de que não se sabe como os feeds funcionam
    Os feeds são open source, existem hoje e você também pode executá-los por conta própria
    Também não está claro que “bagunçar o jogo” se refere a que jogo, nem em que sentido. Há muitas partes móveis aqui

• A ideia de que o usuário possa escolher um provedor de moderação independente do provedor de hospedagem parece ótima, porque reduziria a preocupação com a escolha da instância
  Ainda assim, a instância provavelmente continuará tendo que moderar para não hospedar conteúdo ilegal localmente
  No fim, isso vira algo bem difícil para quem opera instâncias e pode levar a bastante confusão. Talvez eu tenha entendido errado

  • Quem hospeda conteúdo precisa lidar com as consequências legais do conteúdo que hospeda, e no fim não há como evitar isso
    Mas isso é igual independentemente do protocolo usado
  • Você não entendeu errado. Vejo a descentralização do Bluesky como algo próximo de falsa
    Um PDS pode rodar em uma máquina Ubuntu razoável, mas até este texto admite que o relay é caro e um enorme ponto central de controle
    Qual é o plano do Bluesky para lidar com spam? Provavelmente bloquear no relay
    O servidor DID também é outro ponto central de controle
    Ainda assim, você poderá rodar um PDS à vontade

• Uma curiosidade divertida sobre o Bluesky, ligando com um texto de pouco tempo atrás: este também é, de certa forma, derivado do nome de uma pessoa
  O nome da CEO em chinês significa literalmente blue sky

  • Curiosamente, o Twitter já tinha dado ao projeto o nome bluesky antes de eu entrar
    Foi coincidência. Mas meu nome do meio em chinês significa bluesky

• Este quadrinho curto também é bom: https://bsky.social/about/welcome-to-bluesky-comic

• Se o Bluesky encerrar o suporte a did:plc, todas as identidades PLC existentes quebram?
  Fiquei curioso porque o PLC funciona enviando pings para aquele serviço

  • https://plc.directory pode ser espelhado e, se algo assim acontecer, um novo espelho pode se tornar o servidor autoritativo

• Sou cético em relação a labelers de terceiros
  Como impedir abusos?

  • O usuário escolhe quais labelers de terceiros assinar
    Se um serviço de labeler começar a abusar da sua posição, o usuário pode simplesmente cancelá-lo
    Há uma explicação detalhada de como o Bluesky pretende encaixar labelers no ecossistema em https://github.com/bluesky-social/proposals/tree/main/0002-l...
  • A resposta depende do tipo de abuso de que você está falando
    Posso dar minha opinião, mas a pergunta é ampla demais e não sei por onde começar a responder
  • Em breve vamos divulgar muito mais sobre moderação, mas o básico dos labelers é o seguinte
    Qualquer pessoa na rede pode rotular qualquer coisa, incluindo outros labelers
    Apps podem expor os labelers que o usuário pode assinar, como os feeds personalizados atuais do Bluesky
    Assim como apps hoje expõem e ranqueiam feeds personalizados segundo popularidade expressa por curtidas e salvamentos, eles também podem fazer curadoria de como labelers são expostos e ranqueados

• A abordagem de que “as ferramentas de moderação pertencem à camada de alcance. Elas pegam todas as falas, mas oferecem uma forma de limitar o alcance daquilo que eu não quero ver” acaba parecendo uma moderação do tipo “se não quer ver, feche os olhos”
  Sei que essa é uma filosofia querida no Silicon Valley, mas a considero fundamentalmente falha
  Há situações legítimas em que é preciso impedir que outras pessoas não relacionadas falem sobre determinado assunto ou tenham acesso a certo conteúdo
  Exemplos típicos são assédio cibernético, doxxing e pornografia de vingança. Duas ou mais pessoas podem falar sobre maneiras de prejudicar um terceiro, ou divulgar informações privadas, humilhantes ou falsas
  Remover essa informação do feed da vítima é completamente inútil e, para começo de conversa, é provável que ela nem apareça no feed da vítima. O dano vem do fato de outras pessoas verem esse conteúdo ou participarem da discussão, mas esse dano é real
  Em sistemas tradicionais de moderação, um moderador pode remover a publicação para todos ou bloquear os agressores para interromper esse comportamento. Em um sistema que “apenas oculta conteúdo”, isso é impossível
  Listas de bloqueio compartilhadas ou “rótulos” também não funcionam. Os consumidores do conteúdo não têm incentivo para bloqueá-lo; pelo contrário, querem ver pornografia de vingança
  Quem quer bloquear é a vítima, mas a vítima não tem poder para obrigar todos a usar uma lista de bloqueio específica. Isso porque o ponto central desse sistema é que ninguém pode impor uma lista de bloqueio a outra pessoa

  • Ainda há mais a surgir nessa área. Neste texto, foquei nos casos normais e não tratei dos casos ruins
    A equipe analisou esses problemas e “também consultou especialistas”, mas, como ainda é um trabalho em andamento, não sinto que eu tenha autoridade para falar sobre isso
    A parte de que “os rótulos não funcionam porque as pessoas querem ver aquilo, em vez de bloqueá-lo” faz parte de um espaço de problemas que a equipe reconheceu explicitamente
    Além disso, veja isto aqui: https://lobste.rs/s/shseqz/how_does_bluesky_work#c_vjvmei