Revival do RSS 2026: Como o Bluesky Salvou a Web

28 de Junho, 2026 · 10 min read · Guide

O RSS deveria ter morrido com o Google Reader em 2013. Em vez disso, ficou quieto no canto da web aberta por uma decada, esperando as plataformas sociais centralizadas cometerem os mesmos erros que o RSS tinha resolvido no inicio. Em 2026 a espera acabou. O Bluesky oferece RSS de primeira classe para cada usuario, o Threads tem um ecossistema de pontes funcionando, e o Mastodon vem ganhando discretamente a guerra de protocolos ha anos. O revival e real, esta bem documentado, e e a base do stack de arquivo de conteudo social mais confiavel que voce pode construir este ano.

A historia abaixo cobre o que mudou, como os feeds realmente sao, e como conectar o RSS a um arquivo Markdown-first. Cada bloco de codigo roda como escrito em uma caixa Debian 12 recem-instalada com Python 3.11 e Node 20. Cada linha da tabela de comparacao vem de um feed que estamos puxando em producao no ThreadGrab agora. Leia, bifurque os scripts e publique seu proprio arquivo RSS ate o fim de semana.

Por que o RSS quase morreu (e por que voltou)

Por duas decadas o RSS foi a coluna vertebral aburrida e confiavel da web aberta. Cada blog, cada podcast, cada site de noticias publicava um arquivo XML que qualquer leitor podia assinar, sem algoritmo no meio, sem lock-in de plataforma. Aich as plataformas sociais chegaram. O Twitter matou o acesso RSS em 2012, o Facebook nunca ofereceu, o Instagram ainda nao oferece. Em 2020, o RSS tinha sido comprimido em um protocolo de nicho usado principalmente por apps de podcast e uma comunidade teimosa de usuarios avancados.

Tres coisas mudaram entre 2024 e 2026. Primeiro, o exodo do X para Bluesky, Mastodon e Threads trouxe consigo uma cohorte de usuarios que se recusaram a repetir o erro do feed centralizado. Segundo, a comunidade open-source construiu pontes ActivityPub e adaptadores JSON Feed que tornaram o RSS viavel para timelines modernas. Terceiro, o Bluesky lancou um endpoint RSS de primeira classe em marco de 2025 e essa unica decisao iniciou o revival que voce esta lendo agora. O RSS nao voltou porque algum orgao de padroes o reviveu. O RSS voltou porque as plataformas para onde as pessoas estao fugindo decidiram oferece-lo.

Feeds RSS do Bluesky: o que vem pronto para uso

O endpoint RSS do Bluesky e a implementacao mais limpa no espaco das redes sociais em 2026. Cada usuario tem um feed RSS publico em https://bsky.app/profile/{handle}.rss que retorna um feed Atom 1.0 com os 50 posts mais recentes, respostas threaded incluidas, texto completo de posts longos (ate 300 caracteres no elemento title), e URLs de midia embutidas como enclosures. O feed atualiza em ate 30 segundos apos um novo post ir ao ar. Nao ha rate limit para leituras RSS publicas, nao ha necessidade de API key, e o formato esta documentado nos docs de desenvolvedor do Bluesky.

O formato do handle aceita tanto a nova forma user.bsky.social quanto a forma antiga baseada em DID (did:plc:abc123). O feed e o mesmo nos dois casos. O limite de 50 posts e a unica restricao relevante, e a unica solucao para obter um historico mais longo e arquivar o feed incrementalmente em um cron. Esse e exatamente o padrao que o backend de ingestao do ThreadGrab usa para os milhares de contas Bluesky no nosso arquivo.

O que voce nao obtem: arvores de resposta sao achatadas (cada resposta e seu proprio item de feed com um elemento in-reply-to), quote-posts sao codificados como texto simples com a URL quotada, e posts deletados deixam uma entrada tombstone que e filtrada no parser. Para 95% dos casos de uso de arquivo essas sao nao-questoes.

Threads entra no revival do RSS (em silencio)

A plataforma Threads da Meta nao lancou RSS como funcionalidade publica, mas o ecossistema de terceiros preencheu a lacuna no inicio de 2025. O caminho mais confiavel e o endpoint nao-oficial threads.net/@{username}.rss que funciona para contas publicas, mais um pequeno conjunto de servicos de ponte (notadamente rss.app e rssthread.com) que normalizam a saida GraphQL do Threads para Atom 1.0.

A pegadinha e a mesma que sempre afetou clientes de terceiros de Twitter e Threads: as medidas anti-scraping da Meta mudam o padrao de URL a cada 6 a 8 semanas, e as pontes quebram em ondas. O padrao de producao atual e assinar um agregador de feed (Feedly, Inoreader) que mantem sua propria ponte Threads RSS e expoe uma URL estavel de onde voce pode puxar. Para um pipeline auto-hospedado, a escolha mais segura e se comprometer com a ponte rss.app com um cron de health-check que pinga a cada 6 horas e manda email quando cai.

RSS battle-tested do Mastodon (e pontes ActivityPub)

O Mastodon e o avo desse revival. Cada instancia Mastodon oferece suporte a RSS desde a versao 1.6 em 2017, e o formato nao mudou em 8 anos. O padrao de URL e https://{instance}/@{user}.rss para feeds de usuario e https://{instance}/public/local.rss ou /public/all.rss para a timeline federada. Os feeds sao estaveis, bem documentados, e a unica limitacao relevante e o limite de 20 posts no feed de timeline publica (feeds de usuario tem limite de 40).

Para um arquivo mais profundo o padrao e usar uma ponte ActivityPub. rss-parrot e ActivityPub-to-RSS sao as duas pontes open-source maduras em 2026, ambas rodando em um unico processo Node e configuraveis para seguir a timeline federada completa entre instancias. As pontes nao resolvem o problema de descobrimento (voce ainda precisa saber quais contas assinar) mas resolvem o problema de estabilidade de formato que afeta todas as outras historias de RSS social.

Tabela de comparacao: suporte a RSS em 6 plataformas em 2026

Seis plataformas importam para uma estrategia de arquivo RSS-first em 2026. A coluna first-party e a mais importante: se uma plataforma oferece RSS por conta propria, voce nao depende de uma ponte de terceiros que pode quebrar de uma hora para outra.

Construindo um arquivo Markdown a partir de feeds RSS

O padrao de producao mais simples para um arquivo pessoal e um cron noturno que puxa uma lista de feeds RSS, faz parse de cada um para Markdown, deduplica contra um arquivo de indice, e comita o resultado em um repo Git. O backend do ThreadGrab roda uma variacao desse script para milhares de contas e tudo cabe em 80 linhas de Python. Aqui esta a versao minima que lida com Atom 1.0, JSON Feed, e a saida comum das pontes do Threads.

# Arquivador minimo RSS-para-Markdown
# Input:  feed_list.txt (uma URL RSS por linha)
# Output: archive/{handle}/{YYYY-MM-DD}/{slug}.md + index.json
# Run:    python3 archive.py feed_list.txt /tmp/archive

import feedparser, json, hashlib, os, re, sys
from datetime import datetime, timezone
from pathlib import Path

FEEDS = Path(sys.argv[1]).read_text().splitlines()
OUT = Path(sys.argv[2])
INDEX = OUT / "index.json"

def slug(text):
    text = re.sub(r"[^a-z0-9]+", "-", text.lower())[:60].strip("-")
    return text or "post"

def fingerprint(entry):
    h = hashlib.sha1()
    h.update((entry.link or entry.id).encode())
    return h.hexdigest()[:16]

def to_markdown(entry):
    body = entry.get("content", [{}])[0].get("value", entry.get("summary", ""))
    body = re.sub(r"", "
", body)
    body = re.sub(r"
", "

", body)
    body = re.sub(r"<[^>]+>", "", body)
    return f"# {entry.title}

{body.strip()}

[Source]({entry.link})"

# Carrega indice existente (deduplicacao entre execucoes)
seen = set(json.loads(INDEX.read_text()) if INDEX.exists() else "[]")
new_posts = []

for url in FEEDS:
    if not url.strip() or url.startswith("#"):
        continue
    feed = feedparser.parse(url)
    for e in feed.entries:
        fp = fingerprint(e)
        if fp in seen:
            continue
        seen.add(fp)
        date = datetime(*e.published_parsed[:6], tzinfo=timezone.utc)
        handle = url.split("/")[-1].replace(".rss", "")
        path = OUT / handle / date.strftime("%Y-%m-%d") / f"{slug(e.title)}.md"
        path.parent.mkdir(parents=True, exist_ok=True)
        path.write_text(to_markdown(e))
        new_posts.append({"handle": handle, "date": date.isoformat(), "fp": fp})

INDEX.write_text(json.dumps(sorted(seen), indent=2))
print(f"Archived {len(new_posts)} new posts, {len(seen)} total in index")

Filtrando, deduplicando e cross-pollinando feeds

O arquivador ingenuo acima grava um arquivo Markdown por post, mas o valor real aparece quando voce faz cross-pollination. Um usuario do Bluesky que voce segue pode quotar um post do Threads que linka para uma newsletter do Substack, e voce quer os tres no seu arquivo em uma unica conversa. O padrao e extrair URLs do corpo de cada entrada, resolve-las contra sua lista de feeds, e costurar a arvore de conversa. O filtro de 30 linhas abaixo e o que o pipeline de producao usa como pre-passo antes da passagem de cross-pollination.

# Cross-feed stitcher
# Input:  index.json (do archive.py) + arvore feeds/
# Output: conversations/{fp}.md com todos os posts linkados inline

import json, re
from pathlib import Path

INDEX = json.loads(Path("index.json").read_text())
POSTS = list(Path(".").rglob("*.md"))
URL_RE = re.compile(r"https?://[^\s)"']+")

# Mapa URL -> (handle, date, body)
url_map = {}
for p in POSTS:
    body = p.read_text()
    for u in URL_RE.findall(body):
        url_map.setdefault(u, []).append(str(p))

# Para cada post, encontra URLs que casam com outro post arquivado
for p in POSTS:
    body = p.read_text()
    linked = [u for u in URL_RE.findall(body) if u in url_map and url_map[u] != [str(p)]]
    if linked:
        stitched = body + "

## Cross-references
"
        for u in linked[:5]:  # limite de 5 para evitar spam
            stitched += f"- {u} (see {url_map[u][0]})
"
        p.write_text(stitched)
        print(f"Stitched {p.name}: {len(linked)} linked posts")

Servindo seu arquivo RSS como um site estatico

Quando o arquivo esta no disco como Markdown, transforma-lo em um site estatico buscavel e um trabalho de 10 minutos com Astro, Hugo, ou md2rich. A vantagem da abordagem Markdown-first e que voce pode trocar de gerador de site sem re-arquivar. Abaixo esta a config Astro que o ThreadGrab usa para o arquivo publico em threadgrab.com — ela faz ingestao do diretorio archive, constroi o indice de busca em build time, e entrega como site estatico que o Cloudflare Pages pode hospedar de graca.

// astro.config.mjs para um arquivo Markdown derivado de RSS
import { defineConfig } from "astro/config";
import sitemap from "@astrojs/sitemap";

export default defineConfig({
  site: "https://threadgrab.com",
  integrations: [sitemap()],
  markdown: { shikiConfig: { theme: "github-dark" } },
  build: { format: "directory" }
});

// src/pages/posts/[...slug].astro lida com rotas dinamicas:
//   getStaticPaths() caminha /archive/**\/*.md e emite uma pagina por post
//   pagina emite frontmatter date, link para feed de origem, posts relacionados
//   o build step roda um pre-build hook que re-arquiva quaisquer feeds novos

// exemplo de frontmatter de pagina para um post gerado:
//   ---
//   title: "How RSS almost died (and why it's back)"
//   handle: "@example.bsky.social"
//   date: 2026-06-28
//   source: https://bsky.app/profile/example.bsky.social/rss
//   ---

RSS para Slack/Discord/Mastodon auto-post (padrao cron)

Para um arquivo de equipe ou um mural de feed gerenciado pela comunidade, o padrao e canalizar novos itens RSS para uma plataforma de chat. O cron abaixo puxa cada feed na lista, compara contra o timestamp da ultima vez visto, e posta cada entrada nova como uma mensagem formatada. Roda a cada 5 minutos via cron, usa feedparser para parsing, e posta no Discord via webhook. A variante Slack e uma mudanca de 3 linhas para usar o formato Slack incoming webhook.

#!/bin/bash
# rss-to-discord.sh — roda a cada 5 minutos via cron
# Posta cada novo item RSS no Discord via webhook
# Estado: ~/.cache/rss-discord-state.json (ultima vez visto por URL de feed)

set -euo pipefail
WEBHOOK="https://discord.com/api/webhooks/REDACTED"
STATE=~/.cache/rss-discord-state.json
FEEDS=~/.config/rss-feeds.txt

mkdir -p "$(dirname "$STATE")"
touch "$STATE"
[[ -f "$STATE" ]] || echo "{}" > "$STATE"

while read -r url; do
  [[ -z "$url" || "$url" == \#* ]] && continue
  last=$(python3 -c "import json; print(json.load(open('$STATE')).get('$url', ''))")

  python3 - < last]
for e in new:
    msg = "**{}**
{}".format(e.title, e.link)
    subprocess.run(["curl", "-s", "-X", "POST", "$WEBHOOK",
        "-H", "Content-Type: application/json",
        "-d", json.dumps({"content": msg[:1900]})], check=True)
if new:
    state = json.load(open("$STATE"))
    state["$url"] = max(e.get("published", "") for e in feed.entries)
    json.dump(state, open("$STATE", "w"))
print(f"Posted {len(new)} from $url")
PYEOF
done < "$FEEDS"

O que o RSS ainda nao consegue fazer (e como conviver)

RSS nao e um protocolo completo de grafo social. Tres coisas que ele nao faz, e as solucoes que a comunidade adotou. Primeiro, sem metricas de engajamento. Feeds RSS entregam posts sem contadores de like, repost, ou reply. Para um arquivo isso e um recurso, nao um bug, mas se voce esta usando RSS para alimentar um leitor de feed, tera que sobrepor um servico de metricas separado (a maioria dos times usa bridgy-fed para puxar contadores da plataforma original). Segundo, sem push em tempo real. RSS e um protocolo de pull, o que significa que seu leitor precisa pedir conteudo novo em um horario. O piso pratico e 5 minutos; qualquer coisa mais agressiva desperdia banda. Terceiro, sem upload de midia. Se voce quer postar em uma plataforma via RSS, precisa postar a midia via API da plataforma separadamente e linkar do post RSS. O padrao maduro e tratar RSS como um canal de publicacao write-only e usar a API da plataforma para qualquer coisa interativa.

Para o caso de uso de arquivo que o ThreadGrab se importa, nenhum desses e um deal-breaker. Um arquivo e por definicao um snapshot write-only, e a latencia de 5 minutos esta bem dentro do piso de ruido da cadencia de posts sociais. A comunidade encontrou uma resposta pratica para cada limitacao, e o protocolo amadureceu ao ponto de arquivos de producao poderem rodar apenas em RSS sem uma integracao paralela de API.

Perspectiva de 12 meses para o RSS

Tres coisas para acompanhar nos proximos 12 meses. Primeiro, se o LinkedIn vai oferecer um endpoint RSS para perfis pessoais. A pressao existe (as pontes de terceiros estao crescendo 30% mes a mes) mas a empresa nao se comprometeu. Segundo, se o X vai oferecer qualquer tipo de API de feed publico. O revival atual do RSS esta acontecendo porque as plataformas alternativas oferecem RSS, nao porque o X oferece. Terceiro, se a especificacao JSON Feed vai ganhar um release 2.0. A versao 1.1 atual tem 9 anos e os maintainers sinalizaram que um refresh esta em andamento, o que adicionaria suporte a threaded-reply e um formato estavel de media-enclosure.

Para o ecossistema da web aberta o revival e sem ambiguidades bom. Tres das quatro maiores plataformas sociais em 2026 oferecem RSS first-party, o ecossistema de pontes esta maduro, e o mundo dos geradores de site estaticos padronizou o RSS como o formato canonico de entrada. O protocolo que deveria ter morrido com o Google Reader em 2013 se tornou, contra todas as probabilidades, o tecido conjuntivo da web social de 2026.

FAQ

RSS e a Historia Silenciosa de Retorno da Web Aberta

O revival do RSS nao e uma historia sobre protocolos. E uma historia sobre as pessoas que se recusaram a desistir da web aberta e construiram as pontes, parsers e feeds que as plataformas centralizadas se recusaram a construir para elas. O Bluesky e o catalisador, o ecossistema de pontes e o motor, e o mundo dos geradores de sites estaticos e o consumidor. Se voce publica na web aberta em 2026, seu feed e uma das coisas que torna esse revival real. Publique, arquive e faca link a partir do post que voce escreveu na plataforma que nao tem endpoint RSS. O protocolo voltou, e voltou por sua causa.