Não existem instâncias no atproto
(overreacted.io)- A pergunta sobre encontrar uma “instância do Bluesky” aplica diretamente ao atproto o modelo de instâncias do Mastodon, mas o atproto foi projetado separando hospedagem e agregação de apps
- Como no RSS e no Google Reader, os dados não ficam presos dentro do app, e sim em um repositório hospedado, e vários apps funcionam buscando e exibindo esses dados
- Uma instância do Mastodon é uma estrutura em que hospedagem, app, identidade e relações de federação ficam amarradas em uma mesma caixa, então decisões do administrador ou falhas da instância afetam diretamente a experiência do usuário
- No atproto, o usuário pode mudar de hospedagem ou criar e testar novos apps, e apps como Tangled, Semble e Sidetrail funcionam separadamente do Bluesky
- Para enxergar a descentralização do atproto, em vez de olhar para o número de instâncias do Bluesky, é preciso ver se a migração para hospedagens alternativas e o ecossistema de novos apps realmente estão funcionando
Um modelo mais próximo de RSS e Google Reader
- Na era do RSS, o usuário publicava textos em seu próprio blog, e apps como Google Reader ou Feedly agregavam os posts de vários blogs
- Os textos não “moravam” dentro do Google Reader, mas permaneciam em cada blog ou local de hospedagem
- O ponto central é a separação entre hospedagem e agregação
- Hospedagem é onde o conteúdo de fato existe
- O app agregador é mais próximo de uma projeção (
projection) que mostra conteúdo de várias fontes
Redes sociais centralizadas e a resposta do Mastodon
- As redes sociais tradicionais operam reunindo todos os usuários dentro de um único app e de um único espaço
- Nessa estrutura surgem centralização e fortes efeitos de rede, e a discussão sobre redes sociais descentralizadas parte de como dividir esse problema
- A abordagem ao estilo Mastodon faz com que cada comunidade opere seu próprio “pequeno Facebook” ou “pequeno Twitter”, e essa caixa é a instância
O que uma instância do Mastodon agrupa
- O usuário passa a pertencer “dentro” de uma instância específica
- O formato de login do Mastodon ser
[email protected]também acontece porque a instância faz parte da identidade - O usuário deixa de ser uma “Alice” abstrata e passa a ser “Alice da instância #1”
- O formato de login do Mastodon ser
- Para usuários de instâncias diferentes se comunicarem, as instâncias precisam trocar mensagens entre si
- Se Alice está na instância #1 e Bree está na instância #2, quando Alice segue Bree, os posts de Bree são enviados para a instância #1
- Essa relação de envio é a federação
- Como hospedagem e app ficam amarrados juntos, o usuário acaba fortemente dependente da instância
As limitações criadas por esse acoplamento à instância
- Se surgir conflito entre administradores de instâncias, eles podem interromper a federação entre si
- Nesse caso, o usuário pode deixar de ver os posts dos amigos
- Se a instância do usuário sair do ar, a identidade vinculada àquela instância também desaparece
- Isso porque os seguidores passaram a seguir “o usuário daquela instância”
- As setas de conexão entre instâncias crescem em O(n²)
- Hoje isso talvez não seja um grande problema, mas pode se tornar importante se esse tipo de rede social ganhar popularidade
A diferença central do atproto
- O atproto não parte do conceito de instância no estilo Mastodon, e volta ao modelo de RSS e Google Reader
- No nível da rede, ele separa hospedagem e agregação
- Os dados ficam na hospedagem
- Os apps agregam dados a partir da hospedagem de várias pessoas
- Por isso, não existem instâncias no atproto
- A hospedagem pode ser trocada
- Os apps agregam dados de várias hospedagens
- Essa estrutura sugere uma forma de descentralização mais rica do que “operar várias cópias do mesmo app”
A descentralização que o próprio usuário pode fazer
- O usuário pode trocar de hospedagem
- O autor afirma que moveu seus dados do atproto para o Eurosky e que, tirando alguns problemas de UX, o processo ocorreu automaticamente
- Se quiser ir mais longe, também pode hospedar por conta própria de graça na Cloudflare
- Também é possível testar novos apps ou criar um diretamente
- Tangled e Semble são exemplos de apps atproto sem relação com o Bluesky
- O autor criou um app chamado Sidetrail, e esse app é open source
- O atproto também tem um tutorial do Statusphere para criação de apps
Por que “número de instâncias do Bluesky” é uma métrica equivocada
- No Mastodon, faz sentido medir a descentralização pelo número de instâncias
- Isso porque, no Mastodon, a principal forma de descentralização é operar mais caixas em que hospedagem e app estão acoplados e fazê-las conversar entre si
- No atproto, todos os apps são mais parecidos com uma projeção da Atmosphere inteira
- É a mesma estrutura em que Feedly e Google Reader mostram toda a Blogosphere
- É possível operar várias cópias completas do servidor de banco de dados do Bluesky, mas isso em geral não é tão útil quanto operar várias cópias do Google Reader
- Algumas cópias existem para atender necessidades específicas
- O Blacksky é um exemplo voltado para demandas específicas, como uma filosofia diferente de moderação
- O cliente reddwarf.app não usa um banco de dados próprio, e sim o constellation, um cache gratuito operado pela comunidade
- Diz-se que infraestruturas de rede compartilhadas, como Relay, vêm sendo operadas a baixo custo ao longo de um ano
O que observar no atproto
- Para avaliar a descentralização do atproto, em vez do “número de instâncias do Bluesky”, é preciso olhar para o seguinte
- As pessoas estão migrando para hospedagens alternativas?
- As pessoas estão criando e usando novos apps?
- Separar hospedagem e app pode corrigir incentivos quebrados tanto em redes sociais fechadas quanto em redes sociais federadas
- O ponto central do atproto é manter os dados do usuário fora do app, enquanto os apps fazem agregação sobre esses dados
1 comentários
Comentários no Hacker News
A pergunta “onde está a instância do Bluesky?” parece ser interpretada de forma deliberadamente equivocada para enaltecer o ATProto e rebaixar o ActivityPub
Isso acaba omitindo ou distorcendo fatos técnicos interessantes, como os relays do ATProto e seus prós e contras, ou a migração de contas no ActivityPub e seus prós e contras, além de criar conflito desnecessário entre duas plataformas que resolvem problemas parecidos
Também deve haver gente usando “instância” no sentido geral de servidor, software em execução, máquina virtual ou contêiner, então não entendo por que insistir em interpretar isso só no sentido mastodoniano
Os diagramas e a explicação foram bons, mas as alfinetadas sutis contra o ActivityPub passaram a impressão de vir mais de antagonismo do que de uma tentativa de informar
Acho que a comparação com “onde está a instância do Google Reader?” deixa bem clara a estranheza dessa pergunta, e também considero que os dois diagramas no fim do texto explicam muito bem pontos que costumavam passar batido nas discussões iniciais sobre atproto/ActivityPub
O motivo de eu não ter incluído relays está explicado aqui: https://news.ycombinator.com/item?id=48600963
Relay está mais para otimização de desempenho do que para parte central do modelo, então no texto eu quis focar no próprio modelo
Quando a palavra passa a carregar um conceito e uma estrutura específicos, muita gente, ao ver “rede social descentralizada”, pensa numa estrutura federada ao estilo ActivityPub e, ao olhar para o ATProto, acaba perguntando: “por que só existe uma instância do Bluesky onde as pessoas se cadastram?”
Talvez não seja uma perspectiva totalmente nova, mas parece um texto útil para voltar a linkar depois para pessoas que já fixaram essa associação prévia na cabeça
Em vez do decreto do “filioque”, os dois lados trocam posts de blog falando de coisas diferentes sobre a definição de “federação”
O modelo do Fediverse é fácil de entender a partir da perspectiva das redes sociais existentes, mas o ATProto é um conceito novo que tenta dar soberania de dados ao usuário sem abrir mão da escalabilidade das redes sociais centralizadas
Na minha visão, a analogia aqui está quebrada
RSS não dependia em nada do Google Reader e, mesmo no auge, dependia menos dele do que o e-mail hoje depende do Gmail
No ATProto, para um AppView se tornar útil ele depende fortemente de relays, e operar relays também custa uma boa grana
Além disso, o círculo amarelo no diagrama de RSS representa blogs, enquanto os círculos que representam posts do Facebook têm outra natureza. Blogs são independentes por si só
Não quero dizer que o ATProto seja ruim, mas este texto parece mais confundir do que esclarecer
Antes era um pouco mais caro porque armazenava todo o tráfego, mas essa parte saiu no sync 1.1, e hoje dá para rodar com bastante facilidade até numa máquina virtual de 20 dólares por mês
O que realmente é caro e difícil, tanto em sistemas centralizados quanto descentralizados, continua sendo a moderação
O autor deste texto tratou de um equívoco comum sobre relay há 9 meses: https://news.ycombinator.com/item?id=45077291#45078223
Para mim, o relay é a cola que faz o ATProto funcionar bem em termos de desempenho
Ele parece servir para transportar dados sem se importar com o conteúdo e para reduzir a quantidade de serviços que cada AppView precisa conhecer
Como o texto diz, uma grande melhoria em relação ao Mastodon é que relay, AppView e PDS são serviços separados com exigências de escala diferentes, e isso é uma solução bastante elegante para um problema de arquitetura de sistemas
[1] https://atproto.com/guides/glossary
Só que é uma otimização invisível, e existem outras estratégias, por isso foi em grande parte omitido no texto
Por exemplo, hoje muitos apps pequenos não constroem seu próprio índice de banco de dados e dependem do Constellation(https://constellation.microcosm.blue/), então não usam relay nenhum
Alegam que removem apenas conteúdo que seria ilegal hospedar, mas não sei o quanto isso é verdade, e sempre existe o risco de isso mudar no futuro
https://docs.bsky.app/blog/blueskys-moderation-architecture#...
Foi bom explicar a diferença entre as duas abordagens
Mas ficou frustrante não responder à pergunta: “como o ATProto resolve o problema que as instâncias resolvem?”
Por exemplo, se a defederação for tratada como apenas algum motivo obscuro pelo qual você pode não ver as postagens de amigos, então não se consegue responder à pergunta “então como o atproto resolve o problema que a defederação resolve?”
Nesse enquadramento, a resposta básica que surge naturalmente é “não resolve”
No nível de hospedagem, assim como o blogspot.com ou a Cloudflare bloqueiam em certos casos específicos, uma empresa de hospedagem pode suspender contas por conteúdo claramente ilegal
No nível da aplicação, administradores do app e moderadores fazem a curadoria como em outros serviços web com conteúdo gerado por usuários
É uma escolha do desenvolvedor do app: ele pode fornecer elementos básicos de moderação de espaços de usuários, como o Reddit, ou plugar um serviço de moderação separado, como o Bluesky
Como não existe nada equivalente a “instâncias de comunidade” que possam brigar entre si, também não existe defederação. Só existe hospedagem, app e moderação no nível do app conforme a escolha do desenvolvedor do app
Isso é essencialmente parecido com o que a Microsoft faz com e-mail. Tirando os maiores provedores, ela descarta mensagens e, na prática, federa de um jeito que força usuários a usarem a Microsoft ou outro grande operador estabelecido para conseguir entregar mensagens
Aí novas instâncias não conseguem entregar mensagens nem conquistar usuários. Grandes operadores já estabelecidos passam a ter um incentivo perverso para não federar com novas instâncias
Esse tipo de escolha arquitetural tem, no longo prazo, o efeito de consolidar um oligopólio
Dizem que isso é necessário para combater spam, mas há provedores que não fazem isso e, se você configurar corretamente DKIM, DNS reverso etc., normalmente ainda consegue entregar para o Gmail, e eles também não sofrem mais com o problema de spam
A alternativa óbvia é filtrar no cliente. Se os filtros forem fornecidos por listas com uma lógica mais parecida com o uBlock, e não por operadores como a Microsoft, então não haverá incentivo para empurrar todo mundo para a própria instância, porque esses fornecedores de lista não operam uma instância específica
A menos que exista um universo alternativo em que haja muitos AppViews capazes de consumir o firehose inteiro, entre os quais se possa escolher livremente, e que também possam ser operados diretamente a baixo custo
O ATProto se parece mais com um RSS de um mundo em que só dá para ler RSS pelo Google Reader ou por um serviço-clone do mesmo porte, sem leitores RSS de desktop ou mobile
Se grasna como um pato, é um pato
Cada conta tem um único PDS, e o DID aponta para o PDS, que é o feed de dados canônico do usuário e também o destino de escrita
Os dados podem ser replicados, mas o PDS é tratado como a fonte de verdade
Isso está muito mais perto de uma arquitetura cliente/servidor do que de uma arquitetura distribuída
Não há banco de dados P2P, nem DHT, nem escrita em peers. Escreve-se no PDS, e essa escrita é espelhada seletivamente
A descoberta também é feita por DNS, então nem sequer se pergunta a peers pelos dados
Você se conecta ao relay não como um peer, mas como um cliente pedindo uma cópia dos dados hospedados canonicamente no PDS
Não acho forçado chamar o PDS de instância e o relay de espelho
Só que isso é diferente do que as pessoas geralmente querem dizer com “instância” quando falam de Mastodon
No Mastodon, uma instância é um pacote inseparável que combina hospedagem de dados, app, comunidade e moderação
Entendo que o ATproto sacrifica a descentralização de verdade em troca de consistência, enquanto o Mastodon e o ActivityPub sacrificam a consistência de verdade em troca de uma descentralização mais acessível.
Isso porque operar um nó ActivityPub é muito mais acessível para um usuário comum de self-hosting do que operar um relay de conteúdo do AT.
No AT, o que no fim dá para “descentralizar” são apenas os próprios dados, então isso fica mais próximo de posse dos próprios dados do que de propriedade compartilhada de uma parte da rede.
Isso também é algo que já foi repetido várias vezes no HN.
No ActivityPub, operar uma instância significa assumir tudo: dados, aplicação e até os problemas de escalabilidade depois, então você precisa escolher entre carregar essa responsabilidade diretamente ou ficar preso à instância de outra pessoa.
Mesmo que você não goste da instância escolhida e queira migrar, se isso ainda não mudou, o estado atual é que você quase precisa recomeçar do zero.
No AtProto, é fácil migrar para outra plataforma de aplicação mantendo a mesma identidade, e também é possível exportar os dados da plataforma e fazer self-hosting deles — a experiência do usuário é difícil, mas pelo menos isso é possível.
Por exemplo, usei o Tangled pela primeira vez recentemente e consegui entrar com meu domínio baseado em bsky já existente (h14h.com). Não precisei criar uma conta nova nem um novo nome de usuário; parecia que eu já estava lá.
A configuração para fazer self-hosting de um repositório git num VPS levou, no máximo, uma tarde, e roda como um serviço de backend que quase não exige atenção.
No pior caso, aparece um banner no tangled.org dizendo algo como “o repositório está desatualizado e pode não ser compatível com o Tangled mais recente”, e isso se resolve reconstruindo e publicando a imagem Docker com a versão mais nova.
Em termos de arquitetura, o AtProto com certeza é mais difícil de entender de cabeça, mas acho que colocá-lo em contato com usuários reais é muito mais simples.
Na minha cabeça, isso se parece menos com um único controle deslizante e mais com um bufê de trade-offs.
Como referência, no mundo AP indivíduos e equipes pequenas também operam relays, mirrors, caches e AppViews. Só é verdade que isso pode ficar mais caro conforme escala.
O AT não oferece só consistência, mas também um modelo de dados compartilhado entre aplicativos.
Por isso os apps conseguem referenciar e renderizar conteúdo de outros apps. É como uma espécie de web de JSON tipado, e apps diferentes são lentes para olhar a mesma rede.
Qualquer um pode criar novas experiências em cima dos dados existentes, e no AP quase não existe equivalente a isso.
O AP acopla os dados ao app, mas no AT é mais próximo de todos os apps consultarem um único banco de dados global com os dados do mundo inteiro.
Não sei por que a discussão sempre trava nos relays. Hoje em dia, se quiser, dá para rodar um relay por algo em torno de US$ 30 por mês, e também é possível usar os relays da Bluesky ou da comunidade de graça.
Muitos apps nem usam relay nenhum e dependem de índices comunitários como o Constellation(https://constellation.microcosm.blue/). Há até apps que não rodam nem servidor nem banco de dados próprios.
Mas, na verdade, eu gostaria de argumentar o contrário: que o ATproto é mais descentralizado, ou pelo menos tenta ser.
No mundo ActivityPub, identidade, aplicação e hospedagem estão essencialmente ligadas entre si.
Para usar o Lemmy, você precisa criar uma segunda conta ActivityPub permanente e separada naquela instância Lemmy, ou então usar o Lemmy apenas até o ponto em que sua instância Mastodon saiba enviar mensagens que o Lemmy entende.
Cada novo app ActivityPub cria novos problemas de interoperabilidade, porque cada app possui sua própria identidade e sua própria hospedagem.
Não existe um jeito de minha instância Mastodon auto-hospedada fornecer minha identidade a um servidor Lemmy e esse servidor Lemmy dizer para minha instância hospedar conteúdo por mim.
Para alcançar pelo menos o nível de que o ATProto fala, seria preciso algo assim. Mas não sei o quanto isso se aplica ao ATProto que realmente existe, e o ActivityPub que realmente existe também não é tão interoperável quanto seus defensores dizem.
Este blog explica bem a arquitetura.
Mas, na prática, eu achava que o “problema” era que a empresa Bluesky opera o app principal e hospeda a maior parte dos dados dos usuários.
No nível do protocolo ele é descentralizado, mas o sistema real ainda é bem centralizado do ponto de vista de quem controla tudo.
Não quer dizer necessariamente que isso seja culpa da Bluesky, mas parece que foi assim que as coisas caminharam até agora.
Isso não é algo específico da Bluesky nem do ATProto; seja uma organização com fins lucrativos, sem fins lucrativos ou um grupo de voluntários, sempre vai haver alguém procurando algo para criticar.
Não sou investidor e não tenho conflito de interesse com a Bluesky além de ter sido um usuário inicial. Dentro dos meus limites, também entendo o protocolo, a empresa e o site.
O site e o app funcionam bem. As pessoas estão focadas demais em caçar problemas em vez de construir soluções maiores e melhores.
A maioria não quer soluções P2P improvisadas como Lemmy ou Mastodon. Quer que o conteúdo esteja em um lugar só e quer poder cobrar responsabilidade dessa entidade.
Por isso acho que redes sociais P2P nunca vão se popularizar. Houve mais drama em torno de Lemmy e Mastodon do que em Twitter, Reddit e Facebook somados.
Esses são meus 2 centavos, e parece que meu cônjuge e meus amigos pensam o mesmo.
É descentralizado tanto na teoria quanto na prática.
Só que, como a Bluesky opera a maior parte, dá para dizer que isso não é descentralizado no nível da comunidade ou do mindshare, embora isso também esteja mudando.
Só diz que “não há instâncias”, mas não explica como essa arquitetura contorna problemas como autenticação, sincronização e descoberta.
A escolha da analogia com o Google Reader pareceu agourenta
O RSS sobreviveu ao fim do Google Reader, mas nem todas as comunidades que usavam RSS sobreviveram, e muitas delas hoje nem sabem mais o que é RSS
Ficar dizendo que algo é descentralizado enquanto continua apontando a enorme centralização social do ecossistema descentralizado como se fosse um bom exemplo parece quase freudiano
Especialmente porque nós já sabemos como isso termina
O Google Reader reuniu muitas casas de RSS em um só lugar e agregou valor com coisas como grafo social e comentários, mas desmoronou por capricho de executivos do Google, quase matando o RSS e destruindo um impressionante grafo social
Com uma analogia dessas, não dá para confiar muito no ATProto
O app só indexa isso
Então, nessa analogia, qualquer pessoa poderia ressuscitar o Google Reader ou competir com ele usando o mesmo grafo
Se tiver curiosidade, o http://leaflet.pub já funciona assim na prática
Basta imaginar que você não pode usar leitores de RSS para desktop ou mobile, e só pode ler RSS com o Google Reader ou com algum serviço clone de escala parecida
Recentemente alguém até mencionou o NetNewsWire
A diferença importante é que blogs têm seus próprios sites, e não é obrigatório colocar o texto completo no feed RSS
O Bluesky normalmente não funciona assim. Tudo que está no PDS é replicado
E ainda incentiva colocar o post completo do blog no PDS para facilitar a replicação
Aí qualquer um que queira indexar pode pegar uma cópia, e você não tem controle sobre o que eles fazem com ela
Não precisa ser assim. Você também pode publicar o blog no seu próprio site e colocar só o link no Bluesky
Colocar um frontend HTTP em cima de uma conta atproto é a forma recomendada, e muita gente realmente faz isso
Eu mesmo faço isso em pfrazee.com, e até os posts do meu blog leaflet, cujo original está no atproto, são renderizados no meu blog
A comparação com RSS induz ao erro
Apps do Atproto não são como leitores de RSS que rodam no computador do usuário e se conectam diretamente à origem do conteúdo
Apps do Atproto são servidores que controlam, filtram e moldam o conteúdo a ser entregue ao leitor
Apps do Atproto podem censurar, aplicar shadowban, exibir anúncios e transformar o feed em algo algorítmico como bem entenderem
O usuário fica impotente, e o criador vira uma vítima sem poder fazer nada além de reclamar
O fato de qualquer um poder hospedar os dados em qualquer lugar é totalmente sem sentido se não houver como distribuir esses dados
Para começar, você pode usar outro AppView que não faça essas coisas
Os feeds podem ser algoritmizados da forma que o usuário quiser, e se houver vários apps, você não fica preso ao algoritmo que um produtor central quiser impor