Afluente: um leitor social para a web independente

Esta proposta parte do RSC — Really Simple Conversations, mas não pretende produzir apenas uma troca de logotipo ou uma interface mais bonita. A ideia é criar um produto reconhecível por conta própria: um excelente leitor de feeds, uma ferramenta de publicação e uma camada de conversa entre sites independentes.

O nome recomendado é Afluente. Cada blog, site ou perfil é uma nascente independente; seus feeds chegam ao leitor como afluentes; respostas de lugares diferentes formam uma conversa comum sem exigir que todos entreguem sua identidade e seu conteúdo à mesma empresa.

Frase principal: cada site mantém sua nascente. A conversa corre em comum.

Descrição curta: acompanhe pessoas e sites, publique no seu domínio e participe de conversas que continuam pertencendo à web aberta.

Resumo executivo

O RSC já prova que RSS pode transportar mais do que manchetes. O projeto reúne posts locais e remotos numa timeline, reconstrói respostas, publica feeds de saída, trabalha com RSS, Atom, JSON Feed, OPML, WebSub e rssCloud e oferece interoperabilidade com o rss.chat. Seu repositório informa, porém, que o sistema continua em pré-lançamento, sem versão oficial publicada, e que IndieAuth, Micropub, Webmention, categorias e mídia ainda fazem parte do roteiro futuro.

O Afluente deverá aproveitar esse núcleo técnico por meio de um fork responsável, preservando a licença MIT e os créditos. O esforço inicial deve se concentrar nas áreas em que um produto social autohospedado precisa ser realmente confiável:

experiência de leitura muito superior;
identidade principal baseada no domínio da pessoa;
conversas transparentes entre sites;
moderação, privacidade e controle comunitário;
painel operacional para feeds, filas, falhas e backups;
descoberta de autores e sites independentes;
instalação e atualização previsíveis por Docker Compose;
visual editorial próprio, acessível e responsivo.

A proposta evita começar com microserviços, aplicativo móvel nativo, três bancos de dados, inteligência artificial ou ActivityPub completo. A primeira versão deve continuar usando TypeScript, Hono, SvelteKit, SQLite, Docker Compose e Caddy, porque essa base já existe e é proporcional ao tamanho esperado de uma instalação pessoal ou comunitária.

O resultado não deve ser vendido como “um Mastodon de RSS”. A categoria mais clara é:

Leitor social da web aberta.

Metodologia e critérios

Esta ideia foi construída a partir de cinco frentes:

leitura do README, da licença e do documento fundador do RSC;
inspeção da aplicação pública do RSC em funcionamento;
comparação entre o que o projeto declara pronto e o que ainda está no roteiro;
consulta às especificações oficiais de RSS, JSON Feed, OPML, WebSub, Webmention, Micropub e IndieAuth;
análise das necessidades de uma instalação autohospedada pequena: operação, segurança, backup, moderação, acessibilidade e simplicidade de manutenção.

“Melhor” não significa ter mais funcionalidades. Nesta proposta, significa:

cumprir muito bem leitura, publicação e conversa;
mostrar claramente a origem e o estado de cada conteúdo;
continuar utilizável quando JavaScript ou serviços externos falharem;
não esconder erros de ingestão e entrega;
permitir instalação, backup e restauração por uma pessoa comum;
preservar padrões abertos e a saída dos dados;
oferecer uma identidade visual memorável sem prejudicar legibilidade.

As constatações sobre o estado atual do RSC foram verificadas em 22 de julho de 2026. O projeto está evoluindo rapidamente, portanto algumas lacunas podem ser resolvidas pelo upstream antes do início do fork.

O que o RSC realmente oferece

O RSC define a si próprio como uma timeline social nativa de feeds. Pessoas que publicam dentro da instância e pessoas que publicam em sites próprios aparecem como participantes do mesmo espaço. Posts, respostas e conversas viajam por feeds abertos em vez de dependerem de uma API proprietária.

Recursos já declarados como funcionais

Segundo o README oficial, já existem:

timelines Local, Federada, Pessoal e Pública;
atualização ao vivo por Server-Sent Events, mantendo links e formulários funcionais sem JavaScript;
assinatura de RSS, Atom e JSON Feed;
descoberta de feed a partir da página HTML;
leitura de h-feed e microformats2;
importação e exportação OPML;
publicação e edição em Markdown;
rascunhos persistentes no navegador;
histórico de revisões;
respostas organizadas em threads;
RSS e JSON Feed para cada usuário local;
WebSub e rssCloud para entrega em tempo real;
interoperabilidade com o rss.chat;
contas permanentes, visitantes e login por link mágico;
sanitização de HTML contra XSS;
proteção contra SSRF durante a busca de feeds;
instalação de desenvolvimento e produção por Docker Compose.

Essa é uma fundação valiosa. Parser, normalização, threading, geração de feeds, autenticação e interoperabilidade são justamente as áreas mais fáceis de subestimar numa reescrita.

Recursos ainda indicados como futuros

O roteiro publicado pelo projeto ainda lista:

IndieAuth;
Micropub;
Webmention;
categorias vindas de OPML;
mídia e enclosures;
coleta de avatares.

O documento fundador descreve três tipos de identidade: usuário local, domínio remoto reivindicado e feed remoto não reivindicado. Entretanto, a reivindicação remota por IndieAuth aparece como parte do desenho, não como funcionalidade concluída. Essa distinção deve permanecer explícita em qualquer fork.

Estado de maturidade

Em 22 de julho de 2026, o repositório se apresentava como pré-lançamento e ainda não tinha uma versão oficial publicada. Isso não diminui o mérito do sistema, mas significa que o Afluente precisará criar sua própria disciplina operacional:

versões e changelog;
migrações testadas;
política de atualização;
testes de restauração;
matriz de interoperabilidade;
política de segurança;
canal público para bugs;
documentação de recuperação de incidentes.

Diagnóstico visual da referência

A aplicação pública foi inspecionada diretamente em desktop. Ela já é limpa, rápida e legível, usando uma estrutura de três colunas: ferramentas à esquerda, timeline ao centro e informações da instância à direita. Na visualização observada, o centro tinha aproximadamente 609 pixels, a barra esquerda 256 pixels e a direita 288 pixels. A interface usava Public Sans no corpo, títulos com aparência editorial, fundo claro, cartões discretos e laranja como cor principal.

O problema não é feiura. O problema é que a apresentação ainda se comporta como uma demonstração técnica:

textos curtos, artigos longos, notícias e respostas usam cartões muito parecidos;
“local” e “remote” aparecem como estado técnico, não como uma explicação humana de identidade;
o conteúdo domina a tela sem controles visíveis de não lidos, salvos, coleções ou densidade;
a barra lateral direita reserva muito espaço para um texto institucional estático;
a origem de uma resposta e o caminho de entrega entre sites não são facilmente compreensíveis;
uma timeline com artigos longos fica visualmente pesada;
descoberta, busca, biblioteca e saúde das assinaturas não formam áreas centrais do produto.

O Afluente deve conservar a sobriedade e o carregamento progressivo, mas organizar a informação de acordo com o tipo de conteúdo e a intenção do leitor.

O nome recomendado

Afluente

Afluente é melhor que uma sigla técnica porque comunica movimento, encontro e independência. Um afluente não perde sua origem quando encontra outro rio. Essa metáfora descreve exatamente o produto: cada pessoa pode continuar no próprio domínio, mas participar de uma corrente compartilhada.

Por que o nome funciona

é uma palavra portuguesa conhecida, mas pouco usada por software social;
conecta naturalmente feeds, fluxos e conversas;
permite uma identidade visual própria sem copiar o ícone clássico de RSS;
funciona tanto para leitor pessoal quanto para comunidade;
combina com a WeirdNet sem obrigar o produto a depender dessa marca;
gera nomes compreensíveis para áreas do produto.

Vocabulário de produto

Conceito técnico	Nome na interface
Timeline principal	Corrente
Feed ou site acompanhado	Fonte
Grupo de feeds	Canal
Thread de respostas	Confluência
Diretório de descoberta	Nascentes
Item salvo	Margem
Estado e entrega de resposta	Percurso
Importação OPML	Trazer minhas fontes

Esse vocabulário deve ser usado com moderação. Os termos técnicos continuam disponíveis em ajuda e administração. Uma pessoa não deve precisar aprender uma metáfora para encontrar “Configurações” ou “Backup”.

Frases de marca

Principal:

Cada site mantém sua nascente. A conversa corre em comum.

Curta:

A web volta a conversar.

Explicativa:

Leia sites, publique no seu domínio e converse pela web aberta.

Verificação obrigatória antes da adoção

A busca preliminar não encontrou um leitor social de RSS conhecido com o nome Afluente. Isso não é uma liberação jurídica de marca. Antes de publicar, será necessário consultar:

busca de marcas do INPI;
organizações e repositórios no GitHub;
pacotes npm;
domínios desejados;
contas em redes sociais;
uso comercial nas classes de software, hospedagem e comunicação.

Não se deve comprar identidade visual ou anunciar o produto antes dessa verificação.

Alternativas de reserva

Nome	Ponto forte	Limitação
Entrefios	Comunica conversas entre origens distintas	Já aparece em iniciativas sociais e negócios brasileiros
Ramal	Curto, sugere ramificação e conexão	Também significa extensão telefônica
Tecer	Ativo, humano e ligado à construção coletiva	Muito genérico para busca e domínio
Trama	Metáfora perfeita para threads e rede	Nome bastante ocupado por empresas e projetos
Confluência	Explica o encontro de fontes	Longo e institucional demais para aplicativo

A proposta de produto

O Afluente será uma aplicação autohospedável que combina quatro produtos sem transformá-los em quatro sistemas separados:

Leitor de feeds: acompanha sites e pessoas por RSS, Atom, JSON Feed e microformats.
Biblioteca pessoal: organiza não lidos, salvos, coleções, notas e histórico.
Publicador: permite criar posts locais ou publicar no domínio do usuário por Micropub.
Rede de conversas: encontra respostas, envia Webmentions e reconstrói threads entre sites.

Proposta de valor

Para o leitor:

“Tudo que você acompanha, sem algoritmo e sem perder o contexto.”

Para quem publica:

“Seu domínio é sua identidade; o Afluente distribui e reúne as conversas.”

Para quem hospeda:

“Uma instância que mostra o que está funcionando, o que falhou e como restaurar.”

Público inicial

O primeiro público não deve ser “todo mundo”. O produto deve servir bem a:

pessoas que já usam RSS e querem conversa;
autores com blog próprio;
comunidades IndieWeb e small web;
operadores de instâncias pequenas;
curadores de diretórios como a WeirdNet;
grupos de 5 a 200 participantes que valorizam controle e exportação.

Grandes redes públicas, celebridades e milhões de usuários não são requisitos da primeira arquitetura.

Princípios do produto

1. O domínio é a identidade mais forte

Uma conta local é conveniente, mas o nível mais confiável de identidade deve ser um endereço controlado pela pessoa, como https://pablomurad.com. O sistema descobre nome, foto, biografia, feeds, rel="me", endpoint Micropub e endpoint Webmention. A interface diferencia claramente:

Conta local: identidade mantida pela instância.
Site verificado: domínio comprovado pelo autor.
Fonte acompanhada: feed público sem reivindicação de identidade.

Um feed importado nunca deve receber aparência de perfil verificado apenas porque possui nome e avatar.

2. Ler vem antes de postar

O Afluente deve ser bom mesmo para quem nunca publicar uma resposta. Isso exige:

estado lido e não lido;
“marcar acima como lido”;
salvar para depois;
coleções manuais;
filtros por tipo, idioma, fonte e período;
busca por título, texto, autor e domínio;
modo compacto, confortável e editorial;
abertura em modo de leitura;
atalhos de teclado;
sincronização do progresso entre dispositivos.

3. Tipos de conteúdo merecem apresentações diferentes

O sistema identifica, sem esconder a origem:

nota curta;
artigo;
imagem;
galeria;
áudio ou podcast;
vídeo;
resposta;
repost ou citação;
atualização de um post existente.

Uma nota curta pode aparecer completa. Um artigo deve mostrar título, resumo, tempo estimado e imagem principal, abrindo numa leitura dedicada. Podcast precisa de player e duração. Resposta deve exibir o trecho ao qual responde. Esse tratamento reduz a sensação de que toda a internet foi comprimida no mesmo cartão.

4. Conversas devem mostrar o percurso

Ao publicar uma resposta, o sistema apresenta uma sequência compreensível:

Resposta salva
      ↓
URL pública criada
      ↓
Feed atualizado
      ↓
Webmention enviada
      ↓
Destino confirmou recebimento

Cada etapa pode estar pendente, concluída, recusada ou com erro. A pessoa vê uma explicação simples e, se desejar, os detalhes técnicos. A transparência evita a falsa sensação de que “federado” significa “entregue”.

5. Nenhum aprisionamento

O usuário deve poder exportar:

assinaturas e pastas em OPML;
posts em Markdown e JSON Feed;
perfil e configurações em JSON;
arquivos de mídia originais;
lista de bloqueios;
banco e filestore para restauração completa.

Excluir conta deve gerar um pacote antes da remoção, se solicitado, e publicar tombstones quando o protocolo permitir.

Como o Afluente será melhor

Área	RSC observado/documentado	Proposta do Afluente
Leitura	Timeline única com quatro filtros principais	Não lidos, salvos, coleções, busca, densidade e modos por conteúdo
Identidade	Local e remoto; domínio reivindicado ainda no desenho	Domínio verificado como identidade central, com estados visíveis
Conversas	Threads por feeds e interoperabilidade rss.chat	Thread unificada, Webmention e painel do percurso de entrega
Descoberta	Assinatura por URL e feeds conectados	Diretório editorial, recomendações manuais e integração opcional com WeirdNet
Visual	Limpo, porém uniforme e próximo de demonstração	Sistema editorial próprio, hierarquia por tipo e interface responsiva
Administração	Operação pouco exposta na interface pública	Saúde de feeds, filas, entregas, duplicatas, armazenamento e backups
Moderação	Não é o foco visível	Aprovação, denúncias, bloqueios, quarentena e políticas por instância
Mídia	Ainda no roteiro	Imagens e `enclosures` após estabilizar leitura e operação
Atualização	Pré-lançamento, sem release oficial	Releases semânticos, changelog, migrações e rollback documentado
Interoperabilidade	RSS, Atom, JSON Feed, OPML, WebSub, rssCloud e rss.chat	Mantém tudo isso e acrescenta testes permanentes para IndieWeb
Exportação	OPML e feeds de saída	Exportação de conta e restauração completa da instância
Acessibilidade	Base sem JavaScript é positiva	WCAG 2.2 AA, teclado, foco, redução de movimento e testes de leitor de tela

Arquitetura da informação

Navegação principal

Hoje apresenta um resumo de novas publicações e conversas importantes, sem algoritmo opaco.

Corrente contém todos os itens das fontes acompanhadas.

Não lidos é a caixa de entrada real do leitor.

Conversas reúne threads iniciadas, seguidas ou com novas respostas.

Salvos funciona como biblioteca de leitura posterior.

Canais organiza fontes por tema, projeto ou pessoa.

Nascentes permite descobrir sites e autores.

Publicar abre o compositor e pergunta onde publicar: conta local ou site conectado por Micropub.

Estrutura de desktop

┌──────────────────┬──────────────────────────────────┬──────────────────────┐
│ Afluente         │ Corrente                         │ Contexto              │
│                  │                                  │                      │
│ Hoje             │ Filtros · densidade · busca     │ Fonte selecionada    │
│ Corrente         │                                  │ Conversa             │
│ Não lidos        │ Item editorial                  │ Percurso da resposta │
│ Conversas        │ Item curto                      │ Ações                 │
│ Salvos           │ Podcast                         │                      │
│ Canais           │ Resposta com contexto           │                      │
│ Nascentes        │                                  │                      │
│                  │                                  │                      │
│ + Publicar       │                                  │                      │
└──────────────────┴──────────────────────────────────┴──────────────────────┘

A terceira coluna não deve exibir permanentemente um texto “Sobre”. Ela se torna uma barra de contexto: mostra informações sobre a fonte, a conversa, o item selecionado ou o estado de entrega. Em telas menores, abre como painel lateral.

Estrutura móvel

No celular, a interface usa uma coluna e navegação inferior com cinco destinos:

Hoje;
Corrente;
Publicar;
Conversas;
Biblioteca.

Filtros aparecem numa folha inferior. Ações secundárias ficam no menu do item. O compositor pode ocupar a tela inteira e salvar rascunhos automaticamente. Nenhuma ação importante deve depender de gesto oculto.

Direção visual

O Afluente deve parecer uma mistura de revista independente, caderno de leitura e ferramenta de rede, não um painel corporativo e não uma cópia do Mastodon.

Personalidade

editorial, mas não elitista;
humana, mas não infantil;
técnica quando necessário, sem expor jargão o tempo inteiro;
tranquila para leitura longa;
viva o bastante para diferenciar fontes e conversas;
densa por escolha, nunca por acidente.

Símbolo

O símbolo recomendado combina três linhas fluidas que convergem sem se fundirem completamente. O espaço negativo forma simultaneamente:

uma letra “A” aberta;
um balão de conversa;
o encontro de cursos de água.

Não usar ondas genéricas, planeta, globo de rede, mascote tecnológico ou o ícone laranja de RSS como logotipo principal. O símbolo precisa funcionar em 16 pixels e numa única cor.

Paleta

Papel	Cor	Uso
Nascente	`#0E766E`	ações principais, links e foco
Tinta	`#17221D`	texto e superfícies escuras
Papel	`#F6F3EA`	fundo claro, menos agressivo que branco puro
Argila	`#D56745`	conversas, destaques e alertas não críticos
Musgo	`#86A36B`	estados saudáveis e fontes verificadas
Névoa	`#DCE7E1`	bordas, seleções e superfícies secundárias
Noite	`#101816`	fundo do tema escuro

Argila não deve ser usada como única indicação de erro, e Musgo não deve ser a única indicação de verificação. Ícone e texto acompanham a cor.

Tipografia

Interface: Manrope, autohospedada e com subconjuntos necessários.
Textos e títulos editoriais: Literata, também autohospedada.
Código: ui-monospace, com a pilha nativa do sistema.

O corpo padrão deve ter pelo menos 16 pixels e entre 1,55 e 1,7 de altura de linha. Artigos usam coluna entre 65 e 75 caracteres. O usuário pode aumentar fonte e espaçamento sem quebrar os cartões.

Cartões e ritmo

Em vez de colocar todos os itens dentro de caixas pesadas, a Corrente usa divisores, espaço e uma pequena barra de origem. Cartões completos ficam reservados para:

áudio e vídeo;
citações e respostas;
avisos operacionais;
coleções editoriais.

Isso cria uma página mais parecida com publicação e menos parecida com painel administrativo.

Movimento

Animações devem explicar mudança de estado:

uma resposta se encaixa na conversa;
um item passa para lido;
a barra de contexto acompanha a seleção;
uma nova publicação chega sem deslocar a leitura atual.

Todas respeitam prefers-reduced-motion. Nenhuma animação automática fica em repetição.

Acessibilidade mínima

contraste WCAG 2.2 AA;
foco visível com pelo menos dois indicadores além de cor;
navegação integral por teclado;
botão “pular para o conteúdo”;
ordem lógica no DOM;
títulos hierárquicos;
região ao vivo silenciosa para novos itens, sem roubar o foco;
texto alternativo para imagens e indicação de mídia sem descrição;
controles de reprodução com rótulos;
zoom de 200% sem perda de função;
tema claro, escuro e preferência do sistema.

Funcionalidades essenciais

Leitor

RSS 2.0, Atom, JSON Feed 1.1 e h-feed;
descoberta automática de feeds;
importação e exportação OPML preservando categorias;
atualização condicional com ETag e Last-Modified;
não lidos, salvos e histórico;
filtros e busca local;
deduplicação de URLs canônicas e GUIDs;
detecção de idioma quando disponível no feed;
modo de leitura com retorno destacado ao original;
cache de imagens opcional e limitado;
política de retenção configurável.

Publicação

notas, artigos e respostas em Markdown;
visualização fiel ao conteúdo final;
rascunho automático;
revisão e histórico de edição;
publicação local com RSS e JSON Feed;
publicação remota por Micropub;
anexos apenas depois que limites, armazenamento e backup estiverem prontos;
URL permanente e tombstone para exclusão.

Identidade

conta local por e-mail e senha ou link mágico;
IndieAuth para entrar com o próprio site;
descoberta de h-card, avatar e rel="me";
vínculo de mais de um site à mesma conta;
explicação do que foi e do que não foi verificado;
recuperação de conta sem transformar domínio remoto em senha universal;
exportação de identidade e conteúdo.

Conversas

threads locais;
referências source:inReplyTo e thr:in-reply-to preservadas;
envio e recebimento de Webmention;
processamento assíncrono e idempotente;
adoção de respostas órfãs quando o pai chega depois;
moderação antes de exibir Webmentions externas;
estado de entrega por destino;
possibilidade de seguir apenas uma conversa.

Descoberta e curadoria

catálogo de sites mantido por pessoas, não ranking opaco;
coleções públicas assináveis em OPML;
páginas por assunto e idioma;
sugestões baseadas nas coleções escolhidas, não em vigilância comportamental;
integração opcional com a WeirdNet;
botão “seguir no Afluente” que aceita a URL de uma página, não exige URL exata do XML;
destaque de fontes abandonadas ou redirecionadas.

Administração

O painel administrativo deve responder rapidamente:

quais feeds estão quebrados;
quando cada fonte foi atualizada;
qual foi o último HTTP status;
quais URLs redirecionaram;
quais feeds são duplicados;
quais tarefas estão pendentes ou falharam;
quais Webmentions aguardam moderação;
quanto espaço banco, cache e mídia ocupam;
quando ocorreu o último backup testado;
qual versão está instalada e se há migração pendente.

Cada erro deve trazer uma ação possível: tentar novamente, editar URL, aceitar redirecionamento, pausar fonte, mesclar duplicata ou abrir detalhes.

Moderação e segurança

Uma rede baseada em URLs públicas continua sujeita a spam, perseguição, conteúdo malicioso e abuso de infraestrutura.

Controles comunitários

cadastro aberto, fechado ou por convite;
aprovação manual opcional;
papéis de administrador e moderador;
denúncia com contexto;
silenciamento e bloqueio de pessoa, domínio, feed, palavra e thread;
quarentena para novas fontes remotas;
aprovação de Webmentions antes da publicação;
limites por conta, domínio e endereço de rede;
registro de decisões administrativas;
página pública de regras e contato.

SSRF e busca de conteúdo remoto

Todo fetch de feed, avatar, imagem ou Webmention deve:

aceitar somente protocolos permitidos;
bloquear loopback, link-local, redes privadas e metadados de nuvem;
resolver DNS novamente em cada redirecionamento;
limitar redirecionamentos;
impor tempo, tamanho e tipo de conteúdo;
não enviar cookies ou credenciais do usuário;
usar fila separada da requisição web;
registrar destino final e motivo de bloqueio.

A própria recomendação do W3C para Webmention alerta que endpoints podem induzir o servidor a realizar requisições arbitrárias e recomenda limites, processamento assíncrono e proteção de recursos internos.

Conteúdo e navegador

sanitização de HTML no servidor;
Content Security Policy restrita;
imagens remotas com política de privacidade configurável;
nenhum script vindo de feeds;
iframe desabilitado por padrão;
links externos com proteção adequada;
Markdown processado pela mesma cadeia na prévia e na publicação;
anexos verificados por MIME, tamanho e extensão;
proteção CSRF em ações autenticadas;
rate limiting em login, postagem, assinatura e callbacks.

Direitos autorais e atribuição

Um feed disponível publicamente não transforma o conteúdo em domínio público. O Afluente deve:

preservar autor, fonte, URL original e data;
mostrar apenas o conteúdo que o próprio feed fornece;
não remover avisos de licença;
permitir que administradores reduzam a exibição a resumo e link;
respeitar remoções, atualizações e 410 Gone quando detectados;
documentar um canal para solicitação de remoção.

Arquitetura técnica recomendada

Estratégia: fork controlado

O caminho recomendado é criar um fork e manter uma trilha clara de alterações. Isso reaproveita o que já funciona e permite comparar o comportamento com o upstream.

RSC upstream
     ↓
Fork Afluente
     ↓
Testes de comportamento existente
     ↓
Camada operacional e nova experiência de leitura
     ↓
Identidade por domínio e IndieWeb
     ↓
Decisão futura: continuar fork ou separar implementação

Uma reescrita imediata provavelmente entregaria uma tela melhor e interoperabilidade pior.

Stack inicial

Linguagem: TypeScript.
Core HTTP: Hono em Node.js.
Interface: SvelteKit com renderização no servidor e aprimoramento progressivo.
Banco: SQLite em modo WAL.
Consultas e migrações: Kysely, mantendo a escolha já usada pelo projeto.
Proxy e TLS: Caddy.
Empacotamento: Docker Compose.
E-mail: SMTP real em produção; Mailpit apenas em desenvolvimento.
Busca inicial: FTS5 do SQLite.
Filas iniciais: tabela de tarefas no próprio SQLite, com leases, tentativas e backoff.

Não adicionar Redis apenas para executar polling. Não adicionar PostgreSQL apenas porque o projeto “pode crescer”. Esses componentes entram quando medições reais demonstrarem contenção ou volume incompatível com SQLite.

Componentes

Core

contas e sessões;
identidades locais e remotas;
feeds e descoberta;
ingestão e normalização;
conversas;
publicação e feeds de saída;
WebSub, rssCloud e Webmention;
fila e tarefas agendadas;
API interna e SSE.

Web

leitor e biblioteca;
compositor;
perfis e fontes;
conversas;
descoberta;
administração;
proxy autenticado para o Core.

Armazenamento

SQLite para metadados e texto;
diretório persistente para anexos e cache;
S3 compatível somente como opção posterior;
nenhum arquivo essencial dentro da camada efêmera do container.

Entidades principais

conta;
identidade;
site;
fonte;
assinatura;
canal;
item bruto;
publicação normalizada;
revisão;
conversa;
relação de resposta;
Webmention;
tentativa de entrega;
arquivo;
regra de moderação;
denúncia;
tarefa de fila;
evento de auditoria.

Separar item bruto de publicação normalizada ajuda a corrigir o parser sem perder o material recebido e permite reprocessamento controlado.

Implantação simples

A distribuição inicial deve oferecer:

caddy
web
core + worker
volume de dados

Banco, arquivos, chaves e configurações persistem em caminhos explícitos. Um comando cria a configuração; outro inicia; outro produz backup consistente. A documentação deve incluir Debian e Ubuntu, proxy externo, Tailscale e restauração num servidor vazio.

Backup e restauração

O backup precisa incluir:

snapshot consistente do SQLite;
anexos e avatares armazenados localmente;
configuração sem segredos impressos no terminal;
chaves necessárias para sessões e integrações;
manifesto com versão da aplicação e schema;
hash dos arquivos.

O projeto só poderá declarar backup “funcional” depois de restaurá-lo automaticamente num ambiente limpo durante testes de release.

Roteiro de desenvolvimento

Os prazos abaixo são estimativas de planejamento, não compromissos. Pressupõem uma pessoa trabalhando com apoio de automação e reaproveitando o código do RSC.

Etapa 0 — provar a base

Duração estimada: 1 a 2 semanas.

instalar o RSC sem alterações;
importar feeds reais da WeirdNet;
testar posts, edições, threads, OPML e rss.chat;
documentar comportamentos atuais;
criar testes de regressão antes de mudar a interface;
catalogar migrações e volumes persistentes;
confirmar a licença de cada ativo visual e dependência.

Saída: relatório de compatibilidade e decisão formal de fork.

Versão 0.1 — leitor operacional

Duração estimada: 4 a 8 semanas.

marca Afluente e sistema visual;
nova navegação;
não lidos, salvos, busca e canais;
tipos de conteúdo e modos de densidade;
painel de saúde dos feeds;
fila com tentativas e backoff;
bloqueios e aprovação de cadastro;
backup e restauração;
releases e migrações documentadas;
testes desktop, móvel, teclado e tema escuro.

Critério de lançamento: uma pequena comunidade consegue usá-lo diariamente e o operador consegue explicar e recuperar falhas.

Versão 0.2 — domínio como identidade

IndieAuth;
descoberta de h-card e rel="me";
reivindicação e desvinculação de domínio;
múltiplos sites por conta;
estados de verificação claros;
perfil público com fontes e endpoints descobertos.

Versão 0.3 — conversas entre sites

envio e recebimento de Webmention;
moderação de respostas externas;
Micropub para publicar em site próprio;
painel Percurso;
suíte de interoperabilidade;
atualização e exclusão idempotentes.

Versão 0.4 — mídia

imagens e galerias;
enclosures de áudio e vídeo;
player acessível;
limites e cotas;
armazenamento local e S3 opcional;
remoção de metadados sensíveis configurável;
backup incremental de arquivos.

Versão 0.5 — alcance opcional

avaliação de ActivityPub como ponte, não como núcleo;
importação de diretórios externos;
APIs documentadas para clientes alternativos;
PWA com cache cuidadoso;
suporte experimental a comunidades maiores.

O que não construir agora

aplicativo Android ou iOS nativo;
mensagens privadas criptografadas;
chamadas de áudio ou vídeo;
marketplace de plugins;
algoritmo de recomendação comportamental;
geração ou resumo por IA;
microserviços;
compatibilidade simultânea com SQLite, PostgreSQL e MongoDB;
CDN própria;
monetização e assinaturas pagas;
federação ActivityPub completa;
promessa de milhões de usuários.

Cada item aumenta manutenção, superfície de ataque e suporte. Nenhum é necessário para provar que um leitor social de feeds pode ser excelente.

Critérios de sucesso

Experiência

adicionar uma página e descobrir seu feed em menos de três ações;
importar OPML preservando pastas;
encontrar não lidos, salvos e conversas sem treinamento;
diferenciar visualmente artigo, nota, resposta e podcast;
usar as funções centrais apenas com teclado;
continuar lendo e navegando com JavaScript desativado;
não perder a posição quando novos itens chegam.

Operação

instalar numa VPS limpa seguindo apenas a documentação;
atualizar com migração automática e backup anterior;
restaurar num servidor vazio em teste de release;
identificar feed quebrado e motivo pelo painel;
reexecutar tarefas sem duplicar posts ou respostas;
exportar assinaturas e publicações sem ferramenta proprietária.

Segurança

bloquear casos conhecidos de SSRF, inclusive por redirecionamento e DNS rebinding;
sanitizar a suíte de payloads XSS;
limitar tamanho e tempo de downloads remotos;
moderar Webmentions antes da publicação quando configurado;
não expor Core, banco ou painel de e-mail diretamente à internet;
documentar processo de divulgação de vulnerabilidades.

Metas de referência

Estas são metas internas sugeridas e devem ser medidas numa VPS definida pelo projeto:

primeira resposta do servidor abaixo de 500 ms no percentil 95 para uma timeline já indexada;
busca abaixo de 300 ms no percentil 95 com 100 mil itens;
ingestão de uma coleção de pelo menos 100 feeds heterogêneos sem travar a interface;
zero falhas críticas de contraste WCAG 2.2 AA;
nenhuma perda de dados em teste automatizado de backup e restauração.

Estratégia jurídica e relação com o upstream

O RSC usa licença MIT. Ela permite usar, copiar, modificar, mesclar, publicar, distribuir, sublicenciar e vender o software. A condição essencial é conservar o aviso de copyright e o texto da permissão em cópias ou porções substanciais reaproveitadas.

Para o Afluente:

manter LICENSE com o aviso original dos contribuidores do RSC;
adicionar o aviso de copyright das contribuições do Afluente;
documentar claramente que é um fork independente;
não sugerir endosso dos autores do RSC;
preservar histórico Git quando possível;
manter uma página de créditos e linhagem;
usar marca, logotipo, textos e ilustrações próprios;
enviar correções genéricas ao upstream quando fizer sentido;
verificar separadamente licenças de fontes, ícones e dependências.

Uma forma respeitosa de apresentação seria:

Afluente é um fork independente do RSC, construído sobre ideias de Textcasting, rss.chat e padrões IndieWeb. Não é afiliado nem endossado pelos projetos de origem.

Esta seção é orientação prática, não parecer jurídico.

Recomendações práticas

Primeiro passo

Não comece pelo logotipo nem por uma reescrita. Instale o RSC numa URL de laboratório, importe 50 a 100 feeds reais, publique, responda, edite, exporte OPML e provoque falhas. O produto novo deve nascer de problemas observados, não apenas da lista de funcionalidades do README.

Primeira mudança de código

Crie testes de regressão para:

ingestão dos formatos suportados;
atualização do mesmo GUID;
resposta chegando antes do pai;
redirecionamento de feed;
bloqueio de endereço privado;
importação e exportação OPML;
postagem, edição e histórico;
backup e restauração.

Só depois altere a experiência de leitura.

Primeira entrega visual

Construa três telas de alta fidelidade antes de redesenhar toda a aplicação:

Corrente com quatro tipos de conteúdo;
conversa com Percurso da resposta;
painel de saúde de feeds.

Essas telas testam as partes mais distintivas da proposta. Landing page e diretório podem esperar.

Decisão de nome

Use Afluente como nome de trabalho. Antes de criar domínio público, faça a busca de marca e colisões. Se houver conflito relevante na área de software ou comunicação, a alternativa recomendada é Ramal.

Prioridade real

A ordem correta é:

Confiabilidade da base
        ↓
Leitura excelente
        ↓
Operação e moderação
        ↓
Identidade por domínio
        ↓
Conversas cross-site
        ↓
Mídia e alcance adicional

O projeto será melhor que a referência se as três primeiras camadas forem excelentes, mesmo antes de concluir as demais.

Conclusão

O RSC é uma referência valiosa porque trata RSS como infraestrutura social, não apenas como lista de links. Ele já resolve uma parte difícil: fazer conteúdos locais e externos coexistirem, publicar feeds, transportar edições e reconstruir conversas.

A oportunidade do Afluente está em transformar essa prova técnica num produto que as pessoas queiram usar todos os dias. A vantagem não será uma lista maior de protocolos, mas a combinação de:

leitura realmente boa;
identidade baseada em domínio;
conversas com entrega transparente;
curadoria da web independente;
administração compreensível;
segurança e moderação desde o início;
visual editorial próprio.

Afluente é uma direção de marca forte porque traduz a arquitetura do produto sem recorrer a sigla ou jargão. A frase “cada site mantém sua nascente” expressa a promessa central: juntar pessoas sem capturar suas identidades e seus conteúdos.

A recomendação final é criar um fork pequeno, testado e operacional, lançar primeiro o melhor leitor social possível e adicionar IndieAuth, Micropub e Webmention em etapas verificáveis. Assim o projeto pode ser mais bonito que o RSC, mas, principalmente, mais confiável, compreensível e útil.

Fontes consultadas

Nota sobre atualidade

Pesquisa concluída em 22 de julho de 2026. O RSC estava em desenvolvimento acelerado e se declarava pré-lançamento, portanto funcionalidades, arquitetura, documentação, licença e estado de releases podem mudar. Confirme o repositório oficial antes de iniciar o fork. O nome Afluente passou apenas por uma busca preliminar e exige verificação jurídica de marca, domínios e identificadores antes de qualquer lançamento público.