ATProto e Bluesky 2026: Portabilidade na Onda Eurosky

1 de Julho, 2026 · 9 min de leitura · Guia

No primeiro semestre de 2026, organizacoes na Europa comecaram discretamente a mover seus dados do Bluesky para fora da infraestrutura de AppView hospedada nos EUA e para stacks de PDS e relay hospedados na Europa. A Waag, uma organizacao holandesa sem fins lucrativos de tecnologia, publicou um relato claro da movida no final de junho: eles destacaram que o mesmo protocolo ATProto pode rodar em servidores europeus, que o conforto com GDPR e a menor latencia sao ganhos reais, e que a arquitetura finalmente esta pronta para suportar splits de relay multi-regiao sem quebrar a identidade. Para criadores de conteudo social, esse e o momento em que o ATProto deixa de ser teorico e passa a ser pratico. Seu handle, seus seguidores e seu arquivo podem viajar com voce.

Este artigo explica o que a onda Eurosky muda de fato para um criador que escreve no Bluesky hoje, como ler posts do Bluesky a partir de um PDS europeu com as mesmas ferramentas que voce ja usa, e como o ThreadGrab se encaixa em um fluxo de arquivo portatil que funciona contra bsky.app, Eurosky e um PDS auto-hospedado. Vamos cobrir as tres pecas do ATProto que voce precisa entender (PDS, AppView, relay), uma exportacao de PDS em um comando, uma receita de assinatura de firehose que funciona entre relays, e um pequeno script Python que transforma um feed XRPC em um arquivo Markdown pesquisavel offline.

O que o ATProto entrega de fato a um criador que o Bluesky nao entregava

ATProto (Authenticated Transfer Protocol) e o protocolo aberto que alimenta o Bluesky. Tres pecas importam para um criador: o PDS, a AppView e o relay. O PDS (Personal Data Server) e onde os dados da sua conta vivem: posts, likes, follows, blocks, lists. A AppView e o front-end read-optimized que constroi um feed. O relay e o stream de eventos que distribui novos posts para cada AppView em tempo real. As tres pecas sao intercambiaveis, e esse e o ponto inteiro.

O motivo pelo qual a onda Eurosky e noticia real para um criador que escreve long-form no Bluesky e simples: ate o inicio de 2026, quase todo PDS era hospedado pela Bluesky Social PBC, e quase toda AppView era o bsky.app. Hoje, provedores de PDS hospedados na UE como Black Forest, Greenhost e alguns co-ops regionais operam PDSes em producao que falam o mesmo protocolo, aceitam os mesmos DIDs e resolvem os mesmos handles. Uma conta Bluesky criada no bsky.app pode ser movida para um PDS Eurosky sem perder um unico seguidor, e os endpoints publicos de leitura funcionam contra qualquer backend.

Por que a onda de migracao esta acontecendo em 2026 (nao em 2024 ou 2025)

Tres coisas mudaram em 2025 e 2026 que tornaram a onda Eurosky tecnicamente possivel. Primeiro, a especificacao ATProto atingiu um ponto estavel em que o formato de exportacao CAR (Content Addressable aRchive) cobria o estado completo da conta, o que significou que migrar um PDS nao exigia mais tooling customizado por provedor. Segundo, a especificacao do relay se dividiu de forma limpa, de modo que um relay em Frankfurt pode se inscrever em um relay em Ashburn sem duplicar ou perder eventos. Terceiro, a Bluesky Social PBC publicou um compromisso por escrito de que o bsky.app oficial continuaria a federar com PDSes fora dos EUA, o que removeu o risco legal para organizacoes com requisitos estritos de residencia de dados.

Para a Waag e os outros primeiros movers, a decisao foi menos sobre ideologia e mais sobre conformidade e latencia. PDSes hospedados na UE reduzem o round-trip time para usuarios europeus de 100-180ms para 10-30ms. Auditorias de GDPR se tornam triviais quando os dados nem saem da UE em primeiro lugar. E as questoes de moderacao que pairam sobre o bsky.app desde 2024 sao mais faceis de responder quando o PDS e operado por uma organizacao sem fins lucrativos com uma politica de moderacao publicada.

As tres pecas que voce realmente precisa conhecer

O insight chave: sua conta vive em um PDS, mas pode ser lida por qualquer AppView que alcance esse PDS, e descoberta por qualquer AppView que assine o relay que carrega o firehose. Nao ha servidor central, nao ha dono, e nao ha lock-in.

Exporte seu arquivo do Bluesky em um comando

A exportacao oficial do Bluesky fornece uma lista JSONL de cada post publico mais um arquivo CAR com o repositorio completo da conta. Voce pode executa-la pela pagina de configuracoes, ou dispara-la programaticamente com o SDK do atproto. O arquivo CAR e o ativo que voce quer manter: ele e um arquivo auto-contido e content-addressed que qualquer PDS ou AppView pode reimportar. O script Python abaixo exporta o arquivo CAR e verifica seu hash.

from atproto import Client
import hashlib, sys

client = Client(base_url="https://api.bsky.app")
client.login("you.bsky.social", "your-app-password")

# 1. Request a CAR export of your full repo
export = client.com.atproto.server.requestAccountExport()
print(f"Export job: {export.id}, status={export.state}")

# 2. Wait for it to finish (poll every 30s, up to 10 min)
import time
for _ in range(20):
    job = client.com.atproto.server.getAccountExportStatus(export.id)
    if job.state == "ready":
        break
    time.sleep(30)
else:
    sys.exit("Export did not finish in 10 minutes")

# 3. Download the CAR file and verify
car_bytes = client.com.atproto.server.getAccountExport(job.id, decode=False)
sha = hashlib.sha256(car_bytes).hexdigest()
with open(f"bluesky-export-{job.id}.car", "wb") as f:
    f.write(car_bytes)
print(f"CAR file saved: {len(car_bytes)} bytes, sha256={sha[:16]}...")

Rode isso uma vez por trimestre e voce tem um backup portatil completo. O arquivo CAR e o que voce entregaria a um novo provedor de PDS se decidisse migrar para o Eurosky, e tambem e o formato que o ThreadGrab le diretamente para produzir um arquivo Markdown limpo.

Assine varios relays para cobertura completa do firehose

Apos a divisao do Eurosky, nenhum relay cobre a rede inteira sozinho. O bsky.network ainda serve os PDSes hospedados nos EUA, o eu.relay cobre os PDSes hospedados na UE, e um pequeno numero de relays da comunidade agrega ambos. Para um criador que quer descobrir e arquivar posts de toda a rede, voce precisa se inscrever em mais de um. A receita abaixo abre duas assinaturas WebSocket em paralelo e grava cada evento em um arquivo JSONL que voce pode usar com grep ou converter depois.

import asyncio, json, websockets

async def subscribe_relay(url, out_file, label):
    async with websockets.connect(url) as ws:
        await ws.send(json.dumps({
            "type": "com.atproto.sync.subscribeRepos",
            "wantTlds": ["bsky.social"] if "us" in label else ["eurosky"]
        }))
        with open(out_file, "a") as f:
            async for msg in ws:
                evt = json.loads(msg)
                # Only persist create/post events with text
                if evt.get("action") == "create":
                    rec = evt.get("record", {})
                    if rec.get("$type") == "app.bsky.feed.post":
                        f.write(json.dumps({
                            "did": evt["repo"],
                            "rkey": evt["path"].split("/")[-1],
                            "text": rec.get("text", ""),
                            "created": rec.get("createdAt"),
                            "relay": label,
                        }) + "\n")

async def main():
    await asyncio.gather(
        subscribe_relay("wss://bsky.network/xrpc/com.atproto.sync.subscribeRepos",
                        "firehose-us.jsonl", "us"),
        subscribe_relay("wss://eu.relay/xrpc/com.atproto.sync.subscribeRepos",
                        "firehose-eu.jsonl", "eu"),
    )

asyncio.run(main())

Rode por 24 horas, deduplique por (did, rkey), e voce tera um arquivo quase completo do dia anterior na rede ATProto. Para a maioria dos criadores, deduplicar para algumas centenas de milhares de posts e suficiente para capturar cada reply e quote-post relevante.

Leia de qualquer PDS ou AppView com o mesmo codigo

Um dos ganhos subestimados da onda Eurosky e que os endpoints de leitura XRPC sao a nivel de protocolo, nao de servidor. O mesmo codigo Python que le do bsky.app tambem le de um PDS Eurosky ou de um relay auto-hospedado, desde que voce o aponte para a URL base correta. O ThreadGrab usa essa propriedade para ler posts do Bluesky de qualquer backend compativel sem mudanca de codigo, o que significa que um criador pode trocar de hospedagem sem perder seu pipeline de leitura.

from atproto import Client

def read_bluesky_feed(handle_or_did, base_url, limit=50):
    # Read the latest posts from any Bluesky account on any backend.
    client = Client(base_url=base_url)
    profile = client.app.bsky.actor.get_profile({"actor": handle_or_did})
    feed = client.app.bsky.feed.get_author_feed(
        {"actor": profile.did, "limit": limit}
    )
    return [
        {
            "text": item.post.record.text,
            "created_at": item.post.record.created_at,
            "uri": item.post.uri,
            "backend": base_url,
        }
        for item in feed.feed
    ]

# Same code, three different backends
us_posts = read_bluesky_feed("you.bsky.social", "https://api.bsky.app")
eu_posts = read_bluesky_feed("you.eurosky.social", "https://api.eurosky.social")
self_posts = read_bluesky_feed("you.example.com", "https://pds.example.com")

Essa e a propriedade da qual a onda Eurosky depende: o handle de um criador resolve nos tres backends, e a superficie da API de leitura e identica. As 30 linhas acima sao a historia inteira de migracao do lado de leitura.

Converta uma exportacao CAR em um arquivo Markdown portatil

Uma vez que voce tem uma exportacao CAR, pode converte-la em um arquivo Markdown pesquisavel com algumas linhas de Python. O script abaixo le um arquivo CAR, percorre os registros do repo e grava um arquivo Markdown por post em um diretorio archive/. Esse formato e o que o ThreadGrab produz nativamente para X, LinkedIn e Bluesky, o que significa que o mesmo tooling de busca offline e diff funciona atraves das tres plataformas.

from atproto.car import read_car
from atproto.xrpc_client import models
import os, pathlib

def car_to_markdown(car_path, out_dir):
    pathlib.Path(out_dir).mkdir(exist_ok=True)
    with open(car_path, "rb") as f:
        car_data = f.read()
    # Walk every record in the CAR file
    records = []
    for cid, block, _path in read_car(car_data):
        rec = models.get_or_create(block)
        if rec.py_type == "app.bsky.feed.post":
            records.append(rec)
    records.sort(key=lambda r: r.created_at)
    for r in records:
        slug = r.created_at.replace(":", "-")[:19]
        fname = f"{out_dir}/{slug}.md"
        with open(fname, "w") as out:
            out.write(f"# {r.created_at}\n\n")
            out.write(r.text + "\n")
    return len(records)

# Convert your Bluesky export
n = car_to_markdown("bluesky-export-12345.car", "archive/bluesky")
print(f"Wrote {n} posts to archive/bluesky/")

O diretorio archive/bluesky/ resultante e texto plano. Voce pode usar grep, versiona-lo em Git, busca-lo com ripgrep, ou alimenta-lo em um LLM. O mesmo fluxo funciona contra um thread do X, um post do LinkedIn ou uma newsletter do Substack, que e o ponto inteiro do padrao de arquivo portatil.

O que o ThreadGrab faz para esse cenario

ThreadGrab e a ferramenta read-side nessa historia. Ele recebe uma URL do X, Bluesky, LinkedIn ou um URI de post do Bluesky, busca o post e retorna Markdown limpo. A onda Eurosky e uma boa noticia para usuarios do ThreadGrab porque a API de leitura nao mudou: o ThreadGrab fala XRPC, XRPC funciona contra qualquer PDS, e entao um post hospedado no Eurosky nao e mais dificil de capturar do que um post do bsky.app. O angulo de arquivo portatil e o mesmo que sempre foi para o X: voce deve possuir uma copia do que escreveu, em um formato que nao dependa de nenhum provedor unico.

Para um criador que esta migrando para o Eurosky, a sequencia pratica e: exporte seu arquivo CAR do PDS atual, importe-o no novo PDS, e rode o ThreadGrab contra o novo handle para confirmar que a contagem de posts bate. Se voce quer um arquivo Markdown junto com o arquivo CAR, o ThreadGrab pode ler o arquivo CAR diretamente e produzir o diretorio archive/ mostrado no snippet acima. Os dois formatos se complementam: o arquivo CAR e o backup autoritativo, e o arquivo Markdown e a camada legivel por humanos.

Perguntas frequentes