--- title: "Afluente: um leitor social para a web independente" date: 2026-07-22 summary: "Proposta de produto, identidade visual, arquitetura e roteiro para transformar a base do RSC em uma plataforma social de feeds mais bonita, útil, segura e operável." tags: [pesquisa, ideia-de-projeto, rss, indieweb, rede-social, self-hosted, afluente] flowerColor: "#72d6c9" --- # Afluente: um leitor social para a web independente Esta proposta parte do [RSC — Really Simple Conversations](https://github.com/rmdes/rsc), 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: 1. experiência de leitura muito superior; 2. identidade principal baseada no domínio da pessoa; 3. conversas transparentes entre sites; 4. moderação, privacidade e controle comunitário; 5. painel operacional para feeds, filas, falhas e backups; 6. descoberta de autores e sites independentes; 7. instalação e atualização previsíveis por Docker Compose; 8. 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](https://github.com/rmdes/rsc), 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: 1. **Leitor de feeds:** acompanha sites e pessoas por RSS, Atom, JSON Feed e microformats. 2. **Biblioteca pessoal:** organiza não lidos, salvos, coleções, notas e histórico. 3. **Publicador:** permite criar posts locais ou publicar no domínio do usuário por Micropub. 4. **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: ```text 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 ```text ┌──────────────────┬──────────────────────────────────┬──────────────────────┐ │ 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. ```text 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: ```text 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](https://github.com/rmdes/rsc/blob/main/LICENSE). 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: 1. Corrente com quatro tipos de conteúdo; 2. conversa com Percurso da resposta; 3. 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 é: ```text 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 - [RSC — repositório oficial](https://github.com/rmdes/rsc) - [RSC — aplicação pública](https://rsc.rmdes.be/) - [RSC — documento fundador do Textcaster](https://github.com/rmdes/rsc/blob/main/docs/superpowers/specs/2026-07-15-textcaster-design.md) - [RSC — licença MIT](https://github.com/rmdes/rsc/blob/main/LICENSE) - [RSS 2.0 Specification](https://www.rssboard.org/rss-specification) - [JSON Feed 1.1](https://www.jsonfeed.org/version/1.1/) - [OPML 2.0](https://opml.org/spec2.opml) - [WebSub — recomendação W3C](https://www.w3.org/TR/websub/) - [Webmention — recomendação W3C](https://www.w3.org/TR/webmention/) - [Micropub — recomendação W3C](https://www.w3.org/TR/micropub/) - [IndieAuth — especificação](https://indieauth.spec.indieweb.org/) - [Textcasting](https://textcasting.org/) - [rss.chat](https://rss.chat/) --- ### 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.