Textcasting: texto aberto, interoperável e independente de plataformas

Esta pesquisa explica o que é o Textcasting, de onde veio a ideia, quais problemas tenta resolver, como pode funcionar tecnicamente e quais projetos já a colocam em prática. Também compara a proposta com RSS, ActivityPub, AT Protocol, Nostr e IndieWeb, separando a visão conceitual do software que existe hoje.

O tema é especialmente relevante para o Afluente, o leitor social da web aberta proposto anteriormente neste projeto. O RSC, base sugerida para o Afluente, declara explicitamente que foi inspirado pelo Textcasting e já implementa parte importante dessas convenções.

Resumo executivo

Textcasting é uma proposta para que textos circulem entre aplicativos e redes sem perder as características básicas de um documento da web. A expressão foi criada por Dave Winer, pioneiro de ferramentas de blogs, RSS, OPML e podcasting. A página foi iniciada em dezembro de 2022 e apresenta a ideia como a aplicação da filosofia do podcasting ao texto.

No podcasting, o produtor escolhe onde hospedar o programa, publica um feed RSS e pode ser ouvido em aplicativos de empresas diferentes. Nenhum aplicativo precisa ser o dono exclusivo do programa. O Textcasting deseja a mesma separação para textos: o autor deveria publicar em uma ferramenta ou domínio de sua escolha e o conteúdo deveria continuar legível, editável e identificável em outros leitores, redes e editores.

O manifesto define seis capacidades essenciais:

1. títulos opcionais;
2. links verdadeiros;
3. formatação simples, como negrito e itálico;
4. anexos ou enclosures;
5. tamanho não limitado por uma rede social;
6. edição depois da publicação, com atualização das cópias.

Markdown é sugerido como representação portátil para links e formatação. Nas implementações de Dave Winer, o texto costuma ser transportado em RSS 2.0 com HTML em <description> para compatibilidade e o Markdown original em <source:markdown>. Extensões mais recentes do namespace source: acrescentam identidade, respostas e feeds de comentários.

Contudo, Textcasting ainda não é um padrão formal completo. Não é uma recomendação W3C, RFC do IETF, especificação versionada ou protocolo com suíte oficial de conformidade. A página descreve resultados desejados e uma filosofia de interoperabilidade, mas não define sozinha autenticação, identidade, entrega, descoberta, moderação, privacidade, exclusão, bloqueios ou resolução de conflitos. Esses problemas precisam ser resolvidos por padrões complementares e pelas implementações.

Em julho de 2026, o ecossistema observável inclui:

• Textcaster, aplicativo experimental de publicação e cross-posting criado em 2023;
• WordLand, editor para WordPress que guarda Markdown e o inclui em feeds;
• FeedLand, leitor e ambiente social de feeds;
• rss.chat, rede social experimental baseada em RSS, OPML, Markdown e WebSockets;
• RSC - Really Simple Conversations, implementação independente, autohospedável e compatível com rss.chat;
• sistemas adjacentes, como WordPress com ActivityPub, Micro.blog, WriteFreely e ferramentas IndieWeb.

O veredito desta pesquisa é:

Textcasting é mais valioso como perfil de interoperabilidade e princípio de produto do que como protocolo pronto.

Para o Afluente, vale adotar seus objetivos, mas formalizá-los em um perfil técnico próprio, testável e documentado. O Afluente não deveria depender apenas do nome “Textcasting”; deveria declarar exatamente quais campos, formatos, atualizações, respostas, anexos, regras de segurança e comportamentos oferece.

Metodologia e critérios

A pesquisa foi realizada em 23 de julho de 2026 por meio de:

• inspeção do HTML e dos dados estruturados da página oficial do Textcasting;
• leitura da documentação do Textcaster, WordLand, source: namespace, rss.chat e RSC;
• inspeção de feeds RSS reais produzidos pelo rss.chat;
• consulta aos repositórios públicos e ao estado atual dos projetos;
• comparação com especificações primárias de RSS 2.0, ActivityPub, WebSub, Micropub, Webmention, JSON Feed, CommonMark, AT Protocol e Nostr;
• consulta ao conceito POSSE da comunidade IndieWeb;
• distinção entre fatos documentados, declarações dos próprios autores e inferências desta análise.

Os termos foram classificados assim:

• padrão formal: documento publicado por organismo como W3C ou IETF, com requisitos normativos;
• especificação independente: formato ou protocolo documentado publicamente por seus mantenedores;
• perfil de interoperabilidade: seleção de recursos que diferentes sistemas concordam em preservar;
• manifesto: declaração de objetivos e princípios, sem necessariamente definir todos os detalhes técnicos;
• implementação: software que realiza uma parte ou a totalidade da proposta.

Essa distinção é necessária porque chamar Textcasting simplesmente de “protocolo” cria uma impressão de maturidade e precisão que a página oficial ainda não oferece.

Resposta direta: o que é Textcasting?

Definição curta

Textcasting é a ideia de que um post deve ser um documento portátil da web, e não um objeto preso ao editor, banco de dados, limite de caracteres e interface de uma rede social.

Seu objetivo declarado é a interoperabilidade entre aplicativos sociais baseada nas necessidades de quem escreve. Um texto produzido em um aplicativo deveria poder atravessar outros serviços conservando, sempre que possível:

• seu conteúdo completo;
• título, quando houver;
• links;
• estrutura e ênfase;
• anexos;
• identidade e URL permanente;
• possibilidade de correção;
• relação com o texto original e com respostas.

O que o nome quer dizer

O nome combina “text” com a ideia de “casting”, por analogia com podcasting. Não significa:

• transformar texto em voz;
• transmitir a tela de um editor;
• enviar SMS em massa;
• criar fontes tipográficas;
• fazer apenas cross-posting para redes sociais.

O ponto é distribuir texto por uma infraestrutura aberta, permitindo que várias ferramentas publiquem e leiam o mesmo conteúdo.

O que existe em textcasting.org

A página oficial é um documento curto, não uma aplicação. Seu subtítulo é “Applying the philosophy of podcasting to text”. O conteúdo foi iniciado em 12 de dezembro de 2022, recebeu ampliações em maio de 2023 e registra modificação em 2 de novembro de 2024.

Ela contém:

• o objetivo geral;
• uma descrição do problema;
• seis recursos desejados por escritores;
• a sugestão de usar Markdown;
• a regra de que aplicativos podem não exibir todos os recursos, mas deveriam preservar o que recebem;
• observações sobre compatibilidade entre leitores de feeds e redes de microblog;
• a identificação de Dave Winer como autor.

A página não possui:

• número de versão da proposta;
• vocabulário normativo com MUST, SHOULD e MAY;
• esquema XML ou JSON completo;
• processo de governança;
• suíte de testes;
• registro de implementações conformes;
• política de segurança ou moderação.

Portanto, a descrição mais precisa é manifesto com um perfil funcional em formação.

Uma peculiaridade da própria página

O conteúdo de textcasting.org é armazenado como uma estrutura OPML convertida em JavaScript e renderizada no navegador. Leitores que não executam o JavaScript da página podem enxergar apenas “Last update” e “Posted”, embora o texto completo esteja embutido no HTML.

Isso não invalida a proposta, mas revela um problema prático importante: a web aberta também precisa de HTML progressivo e acessível diretamente, não apenas dados abertos escondidos atrás de uma etapa de renderização.

Origem e contexto histórico

Por que Dave Winer propôs isso

Dave Winer é uma figura importante no desenvolvimento e na popularização de blogs, RSS 2.0, OPML e do modelo técnico de podcasting. A história dessas tecnologias é coletiva e não deve ser reduzida a um único inventor. RSS começou na Netscape e teve várias linhagens; podcasting envolveu, entre outros, Winer, Adam Curry, Christopher Lydon e ideias anteriores de Tristan Louis. Ainda assim, Winer teve papel documentado na especificação do RSS 2.0 e na adoção do elemento enclosure.

A analogia com podcasting decorre dessa experiência. Um podcast pode:

1. hospedar o áudio em qualquer servidor;
2. publicar metadados e episódios num feed;
3. aparecer em múltiplos aplicativos;
4. trocar de aplicativo sem obrigar o produtor a recriar o programa;
5. manter um endereço que não pertence necessariamente ao tocador.

Winer argumenta que a escrita social tomou o caminho oposto. Serviços semelhantes ao Twitter transformaram texto em um objeto limitado pela plataforma, com nomes próprios, como tweet, toot ou skeet, interfaces específicas e compatibilidade incompleta.

O problema não é apenas o limite de caracteres

O limite chama atenção, mas o diagnóstico é mais amplo:

• o editor pertence à plataforma;
• o formato aceito é determinado pela plataforma;
• links e formatação podem ser removidos;
• textos longos viram imagens, sequências ou links externos;
• uma edição pode não alcançar cópias já distribuídas;
• exportar dados não garante que outro serviço consiga usá-los;
• o grafo social e a descoberta ficam presos a uma empresa;
• cada rede inventa nomes e comportamentos incompatíveis.

Textcasting tenta restaurar a ideia de que um post é primeiro um objeto da web e só depois um item de determinada interface.

Os seis requisitos do manifesto

1. Títulos opcionais

Posts curtos geralmente não precisam de título; ensaios, notícias e documentos longos frequentemente precisam. O autor, não a plataforma, deveria escolher.

Esse requisito aproxima microblog e blog. A própria especificação RSS 2.0 permite itens sem título, desde que exista uma descrição. JSON Feed também tornou o título opcional para acomodar microblogs.

O desafio não é representar o dado. É fazer todos os clientes lidarem corretamente com os dois casos:

• não inventar um título usando a primeira frase;
• não descartar um título real;
• não mostrar um campo vazio;
• não reduzir um artigo a título mais link quando há texto completo disponível.

2. Links

Links são parte estrutural da web. Eles permitem referenciar evidência, dar crédito, responder a outro documento e criar caminhos de descoberta.

Plataformas sociais normalmente reconhecem URLs, mas isso não equivale a suportar hipertexto completo. Um link com texto descritivo, como [especificação RSS](...), é mais legível e acessível do que expor uma URL longa.

No perfil proposto, Markdown fornece uma representação simples e HTML fornece a apresentação final.

3. Formatação simples

O manifesto pede ao menos negrito e itálico. Markdown também permite listas, citações, títulos, links e blocos de código.

Há um risco de ambiguidade. “Markdown” não identifica sozinho uma gramática única. CommonMark, GitHub Flavored Markdown e outras variantes tratam tabelas, quebras de linha, HTML embutido e extensões de maneiras diferentes. A especificação CommonMark existe justamente porque implementações de Markdown divergiram.

Uma implementação séria precisa declarar:

• qual dialeto aceita;
• quais extensões suporta;
• se HTML bruto é proibido;
• como sanitiza links e imagens;
• como preserva texto não compreendido;
• como lida com acessibilidade, incluindo texto alternativo.

4. Enclosures

Enclosure é um elemento do RSS que liga um item a um arquivo de mídia por URL, tipo MIME e tamanho. Ele permitiu o desenvolvimento do podcasting.

No Textcasting, anexos tornam possível publicar:

• áudio;
• vídeo;
• imagens;
• documentos;
• episódios de podcast;
• outros objetos associados ao texto.

Apenas transportar uma URL não resolve upload, armazenamento, direitos autorais, texto alternativo, miniaturas, limites, expiração e segurança. Mesmo assim, usar uma convenção já compreendida por leitores e podcatchers é uma vantagem.

5. Tamanho ilimitado

“Ilimitado” deve ser entendido como sem limite editorial arbitrário imposto pelo formato, não como ausência de limites operacionais.

RSS 2.0 não define um limite de caracteres para itens nas versões posteriores a 0.91. Contudo, servidores e clientes precisam aplicar limites razoáveis contra abuso, falhas de memória e negação de serviço.

Uma boa implementação deve:

• aceitar textos longos;
• permitir que o leitor recolha o conteúdo com um botão “mais”;
• limitar bytes por razões técnicas documentadas;
• não truncar silenciosamente;
• preservar um link canônico quando precisar mostrar um resumo.

6. Edição

Escritores corrigem erros, atualizam informações e acrescentam referências. O manifesto exige que a edição apareça onde o post circulou.

Este é o requisito tecnicamente mais difícil. RSS possui guid para identificar um item, mas sua especificação não define um protocolo completo de atualização distribuída. Leitores podem:

• substituir o item;
• ignorar a mudança por já conhecerem o guid;
• guardar a versão antiga;
• detectar apenas alterações de data;
• manter cache indefinidamente.

O RSC usa identificador estável e <atom:updated> para detectar mudanças, além de histórico local de revisões. ActivityPub possui uma atividade Update formal. Mesmo assim, nenhum sistema distribuído pode garantir que terceiros apaguem todas as cópias antigas.

O requisito correto é propagar uma atualização verificável, não prometer controle absoluto sobre dados já recebidos.

Como Textcasting funciona tecnicamente

A arquitetura em camadas

Textcasting não exige uma única pilha, mas as implementações atuais podem ser entendidas assim:

RSS, OPML e Markdown são formatos de intercâmbio. SQL, SQLite, SvelteKit, Hono e WebSockets são escolhas internas de determinados aplicativos, não requisitos do Textcasting.

Representação dupla: HTML mais Markdown

Uma das decisões mais úteis é transportar duas versões:

• <description> contém HTML renderizado e sanitizado para leitores RSS comuns;
• <source:markdown> contém o Markdown original para clientes capazes de editar ou renderizar com maior fidelidade.

Exemplo simplificado, baseado nos feeds reais do rss.chat:

<rss version="2.0"
     xmlns:source="https://source.scripting.com/"
     xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Exemplo</title>
    <link>https://exemplo.org/</link>
    <description>Posts de Exemplo</description>

    <item>
      <title>Título opcional</title>
      <description>
        &lt;p&gt;Texto com &lt;strong&gt;ênfase&lt;/strong&gt;
        e um &lt;a href="https://example.com"&gt;link&lt;/a&gt;.&lt;/p&gt;
      </description>
      <guid>https://exemplo.org/posts/123</guid>
      <atom:updated>2026-07-23T12:00:00Z</atom:updated>
      <source:markdown>
        Texto com **ênfase** e um [link](https://example.com).
      </source:markdown>
    </item>
  </channel>
</rss>

O benefício é a degradação progressiva: leitores antigos ignoram o namespace desconhecido e continuam exibindo HTML; clientes modernos podem usar o original em Markdown.

O namespace source:

O namespace source: é uma coleção de extensões independentes para RSS 2.0. Entre os elementos relevantes estão:

RSS 2.0 permite extensões por namespaces, portanto isso não modifica o núcleo congelado do formato. A compatibilidade, porém, depende de adoção voluntária pelos aplicativos.

Respostas e conversas

No rss.chat, uma resposta também é um item RSS. Ela contém:

<source:inReplyTo>https://exemplo.org/posts/123</source:inReplyTo>

Um item que recebeu respostas pode apontar para um feed específico:

<source:comments
  count="2"
  feedUrl="https://exemplo.org/posts/123/comments.xml" />

O leitor percorre esses relacionamentos e reconstrói a árvore da conversa. O RSC também lê thr:in-reply-to, da extensão de threading de feeds definida na RFC 4685.

Essa abordagem é elegante porque respostas continuam sendo posts comuns. Entretanto, o leitor precisa resolver:

• resposta recebida antes do post pai;
• pai indisponível;
• duplicatas vindas de feeds diferentes;
• ciclos maliciosos;
• profundidade excessiva;
• mudança de URL;
• autoria falsa;
• exclusão e bloqueio.

Atualização em tempo real

Feeds são tradicionalmente consultados por polling. Para uma experiência social ao vivo, as implementações usam notificações:

• rssCloud avisa assinantes quando um feed muda;
• WebSub usa hubs e webhooks para distribuir conteúdo novo ou atualizado;
• WebSockets ou Server-Sent Events podem atualizar a interface conectada.

WebSub e rssCloud reduzem atraso e requisições repetidas. WebSockets não substituem o feed público: são um canal de experiência em tempo real entre uma aplicação e seus usuários.

OPML como lista de assinaturas

OPML 2.0 é usado há décadas para exportar e importar listas de feeds. No ecossistema Textcasting, ele pode representar:

• quem uma pessoa segue;
• todos os usuários de uma instância;
• blogrolls;
• categorias de assinaturas;
• listas editoriais.

OPML torna o grafo transportável, mas não oferece sozinho permissões, prova de identidade, bloqueios ou sincronização bidirecional.

Textcasting não é apenas RSS

As implementações atuais de Winer usam RSS como espinha dorsal, mas o manifesto é, em princípio, independente do transporte. Os seis requisitos poderiam ser realizados sobre ActivityPub, AT Protocol, Nostr, JSON Feed ou uma API própria.

O ponto central é o comportamento entre produtos:

receber um documento rico, preservar seus recursos e permitir que o usuário escolha ferramentas intercambiáveis.

RSS é atraente porque é simples, implantado há décadas, legível por inúmeros aplicativos e extensível. Porém, não resolve sozinho toda a rede social.

Estado das implementações em julho de 2026

Panorama

Textcaster

O Textcaster é diferente de Textcasting. Ele é um aplicativo que:

• cria posts em editor visual;
• converte e armazena o texto como Markdown;
• publica um feed RSS por usuário;
• aceita título, link e enclosure;
• funciona como linkblog por bookmarklet;
• pode enviar versões para Bluesky, Mastodon, Twitter e WordPress;
• permite editar e excluir itens de sua timeline.

Sua documentação foi criada em 2023 e registra última modificação em outubro de 2024. Em 23 de julho de 2026, o aplicativo exibia versão 0.4.0, mas os links “Platform” e “source” apontavam para um repositório do GitHub que retornava 404.

Isso sugere cautela. O site demonstra a experiência, mas não deve ser tratado como infraestrutura atual confiável sem nova auditoria. Ele solicita tokens ou credenciais de serviços. Para qualquer teste, devem ser usadas senhas específicas de aplicativo, permissões mínimas e contas sem dados críticos.

WordLand

WordLand é um editor criado por Winer para publicar em WordPress com uma experiência mais próxima de uma rede social. O usuário escreve num editor visual, o aplicativo mantém uma representação Markdown e gera feeds que incluem esse Markdown.

A ideia importante não é substituir WordPress, mas separar:

• editor;
• armazenamento;
• publicação;
• feed;
• leitor.

Assim, diferentes editores poderiam trabalhar sobre conteúdo pertencente ao usuário. A documentação oficial está em About WordLand, e o repositório wordlandSupport acompanha suporte e notas de desenvolvimento, não o código completo do produto.

rss.chat

rss.chat é a implementação mais direta de uma rede social Textcasting por Dave Winer. O repositório foi criado em julho de 2026, tem licença MIT e descreve um cliente e servidor baseados em RSS 2.0 e WebSockets.

Cada usuário possui:

• um feed próprio;
• posts com HTML e source:markdown;
• respostas com source:inReplyTo;
• metadados de conta;
• páginas de conversa;
• participação no feed geral da comunidade.

A instância publica também uma lista OPML dos usuários. O documento RSS as a social network explica como posts, comentários e autoria aparecem nos feeds.

Em 23 de julho de 2026, o repositório tinha atividade no mesmo dia, 26 estrelas, seis forks, dez questões abertas e nenhum release formal. Esses números mostram interesse inicial, não adoção consolidada.

RSC e o novo Textcaster.app

O domínio textcaster.app redirecionava, na data desta pesquisa, para uma instalação do RSC - Really Simple Conversations, criada por Ricardo Mendes. Não é o antigo Textcaster de Winer.

O RSC é uma implementação independente inspirada em Textcasting e rss.chat. Segundo seu README, já oferece:

• RSS, Atom, JSON Feed e microformats2 como entradas;
• RSS e JSON Feed como saídas;
• importação e exportação OPML;
• Markdown com pré-visualização;
• edição e histórico de revisões;
• conversas por feeds;
• WebSub e rssCloud;
• interoperabilidade com rss.chat;
• proteção contra SSRF e sanitização de HTML;
• contas locais;
• instalação por Docker Compose e Caddy.

O projeto declara claramente “pre-release, but deep”: funciona de ponta a ponta, mas não possui release. IndieAuth, Micropub, Webmention, mídia e alcance opcional por ActivityPub aparecem no roteiro.

Em 23 de julho de 2026, o repositório havia sido criado seis dias antes, tinha sete estrelas, nenhum fork e nenhuma versão publicada. É uma base promissora e muito jovem.

Comparação com tecnologias relacionadas

Quadro comparativo

ActivityPub já faz isso?

Em grande parte, o modelo de dados permite. A especificação ActivityPub define:

• atores;
• Create, Update e Delete;
• seguidores;
• inbox e outbox;
• likes, compartilhamentos e bloqueios;
• endereçamento por audiência;
• respostas por inReplyTo;
• anexos;
• propriedade source.

Essa propriedade source pode carregar exatamente:

{
  "content": "Eu *realmente* gosto disto.",
  "mediaType": "text/markdown"
}

Ou seja, a ideia de preservar Markdown para edição já aparece na recomendação W3C de 2018.

O problema apontado por Textcasting é menos a capacidade teórica do protocolo e mais a interseção efetivamente suportada pelos produtos. Mastodon e outros clientes podem:

• favorecer posts curtos;
• tratar artigos como título mais link;
• remover parte da formatação;
• não oferecer edição no formato original;
• exibir tipos de objeto de modo diferente;
• aceitar um subconjunto próprio de HTML.

Textcasting pode ser entendido como uma exigência de produto: mesmo que o protocolo suporte muito, os aplicativos deveriam concordar numa experiência mínima favorável à escrita.

IndieWeb e POSSE

POSSE significa “Publish on your Own Site, Syndicate Elsewhere”. O conteúdo nasce no domínio do autor e cópias ou links são enviados a outros serviços.

Textcasting e POSSE compartilham:

• controle do original;
• URL canônica;
• menor dependência de plataformas;
• liberdade de usar diferentes interfaces;
• distribuição para onde o público já está.

A diferença é de ênfase:

• POSSE é uma estratégia de publicação e propriedade;
• Textcasting é um conjunto de capacidades que o texto deveria manter ao circular.

Micropub resolve criação, atualização e exclusão de posts no site do usuário usando clientes de terceiros. Webmention notifica um documento quando outro o menciona. Juntos, eles complementam lacunas que o manifesto Textcasting não especifica.

AT Protocol

O AT Protocol oferece identidade por DID, repositórios verificáveis, servidores pessoais de dados, relays, firehose, AppViews e esquemas extensíveis chamados Lexicons.

É mais completo para:

• migração de conta;
• identidade criptográfica;
• sincronização em grande escala;
• schemas específicos de aplicações;
• serviços de moderação.

Também é muito mais complexo. O aplicativo Bluesky é apenas uma implementação e seu modelo de microblog não define todas as possibilidades do protocolo. Um Lexicon de publicação longa poderia implementar objetivos de Textcasting, mas outros clientes precisariam adotá-lo.

Nostr

O Nostr usa eventos assinados por chaves e distribuídos por relays. O NIP-23 define artigos longos com:

• Markdown;
• título opcional;
• imagem;
• resumo;
• data de publicação;
• versões substituíveis;
• comentários por outro NIP.

Ele demonstra que princípios semelhantes podem existir fora do RSS. Seus desafios são diferentes: gestão de chaves, descoberta de relays, moderação, remoção de cópias e experiência inconsistente entre clientes.

JSON Feed

JSON Feed oferece uma representação moderna e simples de feeds. Ele suporta:

• itens sem título;
• HTML ou texto;
• data de modificação;
• autores;
• múltiplos anexos;
• extensões.

Não possui um campo Markdown padrão no núcleo. Uma extensão poderia acrescentá-lo. O RSC publica RSS e JSON Feed, mas usa RSS com source: para o contrato Textcasting mais completo.

Pontos fortes da proposta

1. Começa pelas necessidades do escritor

O manifesto evita organizar a escrita em torno das limitações históricas de um produto. Isso é uma correção útil num mercado em que o formato do pensamento frequentemente é moldado pela interface.

2. Une microblog e blog

Título opcional e tamanho flexível permitem que uma única timeline contenha:

• uma frase;
• uma anotação;
• um link comentado;
• uma resposta;
• um artigo;
• um episódio de podcast.

O leitor pode escolher quanto mostrar sem obrigar o autor a empobrecer o conteúdo.

3. Usa formatos simples e antigos

RSS, OPML e Markdown são compreensíveis, possuem muitas bibliotecas e continuam legíveis fora de uma aplicação específica. Um arquivo XML ou Markdown pode ser arquivado e inspecionado décadas depois.

4. Permite degradação progressiva

Um leitor que não entende source:markdown ainda pode mostrar <description>. Um leitor que não entende conversas ainda pode exibir o post como item comum.

5. Favorece componentes substituíveis

Editor, armazenamento, leitor e rede não precisam pertencer à mesma empresa. Essa separação reduz aprisionamento e permite inovação em interfaces.

6. Pode aproveitar a base instalada da web

Milhões de sites já publicam feeds. Mesmo sem participar de uma rede social Textcasting, eles podem aparecer num leitor social. Isso reduz o problema de começar com uma timeline vazia.

Limitações e problemas ainda abertos

1. Não há conformidade objetiva

Duas ferramentas podem afirmar suporte a Textcasting e interpretar Markdown, edição e anexos de formas incompatíveis. Sem perfil versionado e testes, o termo corre o risco de virar apenas um rótulo promocional.

2. Identidade não está resolvida

Possibilidades atuais incluem:

• URL do feed;
• domínio;
• conta local;
• WordPress.com;
• IndieAuth;
• endereço no source:account;
• ator ActivityPub.

Elas não são equivalentes. Uma conta pode trocar de feed? Quem prova que um feed pertence a uma pessoa? Como impedir falsificação de autoria? O manifesto não responde.

3. Markdown não é uniforme

Sem escolher uma variante, o mesmo texto pode renderizar de formas diferentes. HTML bruto e URLs maliciosas também criam riscos de XSS e phishing.

4. Edição e exclusão não são garantidas

Feeds distribuídos podem ser armazenados. Uma atualização pode chegar, mas um consumidor hostil pode ignorá-la. Exclusão deve ser tratada como solicitação e sinal de estado, não apagamento universal garantido.

5. Moderação está fora do manifesto

Uma rede social precisa de:

• bloqueio;
• silenciamento;
• denúncia;
• filtros;
• limites de taxa;
• reputação;
• tratamento de spam;
• controles de mídia;
• listas comunitárias;
• administração transparente.

RSS público facilita leitura aberta, mas também facilita ingestão abusiva e spam.

6. Privacidade não é o caso padrão

Feeds públicos não oferecem, por si mesmos:

• mensagens privadas;
• grupos fechados;
• criptografia ponta a ponta;
• audiências por post;
• revogação confiável.

Textcasting é mais adequado inicialmente para publicação pública. Não deve ser vendido como substituto de mensageiros privados.

7. Descoberta pode recentralizar

Mesmo com feeds distribuídos, usuários podem depender de um grande diretório, buscador ou timeline. A camada de descoberta pode recriar o poder que a arquitetura pretendia dispersar.

8. Conversas distribuídas são difíceis

Reconstruir uma árvore a partir de feeds independentes exige resolução, cache, deduplicação, proteção contra ciclos e política de moderação. Uma conversa não é apenas um conjunto de links.

9. A governança do namespace é estreita

O namespace source: é publicamente documentado, mas é conduzido principalmente por Winer e não possui o processo de consenso de uma recomendação W3C. Isso permite velocidade, mas aumenta risco de decisões unilaterais e adoção limitada.

10. Acessibilidade precisa ser explícita

O manifesto menciona formatação e anexos, mas não define:

• texto alternativo obrigatório ou recomendado;
• idioma;
• direção de escrita;
• transcrições;
• legendas;
• hierarquia de títulos;
• comportamento de leitores de tela.

Um perfil moderno deve incorporar esses elementos desde o início.

Segurança e operação

Conteúdo remoto é entrada hostil

Um leitor Textcasting busca URLs fornecidas por terceiros. Ele deve tratar feeds, HTML, imagens e Markdown como conteúdo não confiável.

Controles mínimos:

• proteção contra SSRF, inclusive em redirecionamentos;
• bloqueio de redes privadas e metadados de nuvem;
• limite de tamanho e tempo;
• limite de profundidade e quantidade de itens;
• parser XML protegido contra entidades externas;
• sanitização rigorosa de HTML;
• esquema permitido de URLs;
• proxy ou política clara para mídia remota;
• prevenção de ciclos em conversas;
• isolamento de pré-visualizações;
• rate limiting.

O RSC declara possuir sanitização e proteção contra SSRF. Isso é uma boa base, mas precisa ser testado continuamente.

Credenciais e cross-posting

Ferramentas como o Textcaster original conectam várias redes. O princípio deve ser:

• nunca reutilizar senha principal;
• preferir OAuth;
• usar app passwords;
• limitar escopos;
• criptografar segredos em repouso;
• permitir revogação;
• registrar tentativas de publicação sem registrar tokens;
• mostrar prévia do que cada destino receberá.

Preservação do original

O sistema deve guardar:

• Markdown original;
• HTML sanitizado derivado;
• URL canônica;
• identificador estável;
• data de criação;
• data de modificação;
• histórico de revisões;
• anexos e seus metadados;
• relações de resposta;
• origem do item remoto.

Armazenar só o HTML final reduz a capacidade de editar em outro cliente.

Relevância direta para o Afluente

O Afluente já está dentro dessa linhagem

A pesquisa anterior definiu o Afluente como leitor social da web aberta baseado no RSC. Como o RSC é explicitamente inspirado por Textcasting e interoperável com rss.chat, o Afluente já herdaria:

• feeds como meio de transporte;
• Markdown preservado;
• títulos opcionais;
• posts longos;
• edição;
• respostas;
• OPML;
• atualizações em tempo real;
• componentes substituíveis.

Textcasting fornece uma boa filosofia editorial para o produto:

O Afluente deve adaptar a apresentação ao leitor sem destruir a intenção do escritor.

O que o Afluente deveria adotar

1. Perfil Afluente Textcasting 0.1

Criar um documento normativo próprio e pequeno, sem reivindicar um novo padrão universal. Ele deveria definir:

• RSS 2.0 como saída obrigatória;
• JSON Feed como saída recomendada;
• HTML sanitizado em description;
• Markdown original em source:markdown;
• guid estável e URL canônica;
• atom:updated para alterações;
• source:inReplyTo e thr:in-reply-to para respostas;
• source:comments quando houver feed de conversa;
• enclosure e metadados de acessibilidade;
• OPML para importação e exportação;
• WebSub e rssCloud opcionais para tempo real;
• comportamento de fallback;
• limites operacionais;
• regras de exclusão e tombstones;
• testes de compatibilidade.

2. CommonMark como base

Adotar CommonMark com um conjunto pequeno de extensões explicitamente listado. Recomenda-se:

• links;
• negrito e itálico;
• listas;
• citações;
• títulos;
• código inline e cercado;
• tabelas, se houver suporte consistente;
• imagens apenas com texto alternativo;
• HTML bruto desativado.

3. Representação dupla

Nunca obrigar leitores antigos a interpretar Markdown. Publicar simultaneamente:

• Markdown como fonte;
• HTML sanitizado como representação pronta.

4. Identidade por domínio

O domínio deve ser a identidade mais forte, com IndieAuth como caminho preferido. Contas locais podem existir, mas o sistema deve permitir:

• associar domínio verificado;
• exportar feeds;
• redirecionar feed antigo;
• migrar sem perder o guid;
• mostrar claramente autor original e instância que importou o item.

5. Micropub para editores externos

Micropub é uma resposta já padronizada para permitir múltiplos editores. Integrá-lo é mais sólido do que inventar uma API exclusiva do Afluente.

6. Webmention para alcance entre sites

Webmention pode complementar source:inReplyTo, notificando o site original sobre respostas publicadas em outro domínio.

7. ActivityPub como ponte opcional

O Afluente não precisa começar implementando toda a federação ActivityPub. Quando a ponte existir, deve:

• preservar a URL canônica;
• usar source com text/markdown;
• escolher corretamente entre Note e Article;
• enviar Update e Delete;
• mostrar prévia do resultado em clientes populares;
• registrar perdas de formatação.

8. Compatibilidade medida

Criar fixtures e testes com:

• post sem título;
• artigo longo;
• Markdown completo;
• link;
• imagem com alt;
• áudio por enclosure;
• edição;
• exclusão;
• resposta antes do pai;
• pai ausente;
• conteúdo malicioso;
• feed enorme;
• caracteres internacionais.

O que o Afluente não deveria copiar

• depender de um único servidor de identidade;
• armazenar senhas de redes quando OAuth estiver disponível;
• considerar todo RSS confiável;
• anunciar “edição em toda parte” sem explicar os limites;
• inventar outro dialeto de Markdown;
• ocultar conteúdo essencial atrás de JavaScript;
• depender de um único índice global;
• confundir feed público com mensageria privada;
• usar “compatível com Textcasting” sem publicar critérios.

Decisão recomendada

O Afluente deveria apresentar Textcasting como uma de suas inspirações, não como sua única fundação técnica:

Afluente implementa os princípios de Textcasting por meio de RSS, Markdown, OPML e padrões IndieWeb documentados, com compatibilidade testável e saída total dos dados.

Isso é mais preciso e defensável do que dizer apenas “Afluente é uma rede Textcasting”.

Casos de uso

Autor independente

Escreve no próprio domínio, publica RSS com Markdown e aparece em leitores sociais sem criar uma cópia canônica em cada rede.

Linkblog

Usa bookmarklet para comentar links. O post tem URL própria, link externo, texto e feed. Outros leitores podem republicar mantendo atribuição.

Jornal ou revista pequena

Publica notas curtas, reportagens longas e podcasts no mesmo sistema, usando título quando necessário e enclosures para mídia.

Comunidade técnica

Compartilha Markdown com blocos de código, listas e links sem transformar explicações em capturas de tela ou threads fragmentadas.

Rede comunitária autohospedada

Mantém uma instância RSC ou Afluente, segue feeds externos e conversa com outras instâncias sem exigir que todos migrem seus blogs.

Editor alternativo

Um novo editor publica no WordPress ou num endpoint Micropub. O documento continua pertencendo ao usuário e pode ser editado por outra ferramenta.

Perguntas frequentes

Textcasting é uma rede social?

Não por si só. É uma visão de interoperabilidade. rss.chat e RSC são redes ou timelines sociais que implementam essa visão.

Textcasting é um protocolo?

Em linguagem informal, algumas pessoas usam esse termo. Tecnicamente, é mais correto chamá-lo de manifesto ou perfil emergente. RSS, WebSub, ActivityPub e Micropub são protocolos ou especificações definidos com muito mais precisão.

Preciso instalar alguma coisa para ler?

Não necessariamente. Feeds Textcasting continuam sendo RSS. Um leitor comum pode mostrar o HTML e ignorar extensões que não conhece.

Um feed RSS comum já é Textcasting?

Ele cobre parte da ideia. Para suporte mais completo, precisaria preservar recursos como Markdown original, edição detectável, respostas e anexos.

Textcasting substitui ActivityPub?

Não. Pode coexistir, complementar ou ser transportado por ActivityPub. ActivityPub resolve federação social mais ampla; Textcasting enfatiza fidelidade e liberdade de escrita.

Textcasting substitui AT Protocol ou Nostr?

Não. São arquiteturas diferentes. AT Protocol e Nostr resolvem identidade e distribuição de outras formas e podem hospedar tipos de conteúdo alinhados ao manifesto.

Ele garante propriedade do conteúdo?

Não sozinho. Propriedade prática depende do domínio, hospedagem, licença, backups, URLs canônicas e termos dos destinos. Formatos abertos facilitam controle e migração, mas não substituem essas decisões.

É possível editar todas as cópias?

É possível publicar uma atualização que clientes cooperativos apliquem. Não é possível obrigar todos os terceiros a apagar versões que já armazenaram.

É privado ou criptografado?

O modelo observado é voltado à web pública. Privacidade e criptografia precisam de protocolos adicionais.

Vale usar o Textcaster original?

Somente como experimento cuidadoso. A aplicação continua acessível, mas sua documentação e código apontam sinais de legado. Não se deve entregar credenciais importantes sem auditoria.

Qual implementação parece mais interessante hoje?

Para desenvolvimento e autohospedagem, o RSC é a base mais completa e documentada, além de já estar associado ao plano do Afluente. Para observar a proposta original em funcionamento, rss.chat é a referência direta. Ambos são projetos muito jovens e ainda não devem ser tratados como plataformas maduras.

Recomendações práticas

Para quem quer apenas publicar

1. Mantenha um site ou blog com domínio próprio.
2. Garanta que ele publique RSS ou Atom com texto completo.
3. Use URLs permanentes.
4. Evite publicar o original apenas em redes fechadas.
5. Exporte e faça backup do conteúdo.
6. Use POSSE ou ActivityPub para alcance adicional.
7. Acompanhe WordLand e clientes Micropub se desejar trocar de editor.

Para quem quer experimentar agora

1. Observe rss.chat sem colocar informação sensível.
2. Teste o RSC localmente por Docker Compose.
3. Inspecione os feeds gerados.
4. Verifique como edições e respostas aparecem em outro leitor.
5. Teste importação e exportação OPML.
6. Use contas e credenciais descartáveis em cross-posters experimentais.

Para o desenvolvimento do Afluente

Prioridade sugerida:

1. congelar um perfil Textcasting mínimo;
2. construir fixtures e testes;
3. garantir RSS de entrada e saída impecável;
4. preservar Markdown e HTML sanitizado;
5. implementar identidade por domínio e IndieAuth;
6. integrar Micropub e Webmention;
7. fortalecer moderação e operação;
8. adicionar pontes ActivityPub somente depois do núcleo.

Critérios para considerar a ideia bem implementada

Uma implementação deveria conseguir:

• ler seu próprio feed em um leitor RSS genérico;
• transportar um post sem título e um artigo com título;
• preservar links e ênfase;
• não truncar texto silenciosamente;
• atualizar um item pelo mesmo identificador;
• exportar todas as assinaturas;
• reconstruir respostas mesmo fora da instância;
• sobreviver à troca de editor;
• informar perdas ao enviar para um destino limitado;
• funcionar em HTML básico;
• resistir a feeds maliciosos;
• permitir backup e migração.

Conclusão

Textcasting é uma resposta ao empobrecimento da escrita nas redes sociais. Sua proposta é simples e poderosa: texto publicado na web deve continuar sendo texto da web, com links, estrutura, tamanho escolhido pelo autor, anexos e possibilidade de correção.

A analogia com podcasting funciona porque destaca a separação entre criador, hospedagem, formato de distribuição e aplicativo de consumo. O autor não deveria precisar entregar todos esses papéis à mesma empresa.

Ao mesmo tempo, não se deve atribuir ao manifesto capacidades que ele não define. Textcasting não resolve sozinho identidade, autenticação, privacidade, moderação, entrega ou governança. Muitos de seus componentes já existem em RSS, ActivityPub, IndieWeb, AT Protocol e Nostr. Sua contribuição mais interessante é reuni-los sob uma exigência clara de produto: a interoperabilidade deve preservar o que escritores realmente usam.

Para o Afluente, a ideia é central e merece ser adotada. O caminho responsável é transformar princípios em um perfil técnico pequeno, versionado, seguro e testável, apoiado em padrões existentes. Assim, Textcasting deixa de ser apenas um bom manifesto e vira uma qualidade verificável do produto.

Fontes consultadas

• Textcasting - manifesto oficial
• Textcaster - aplicação experimental
• Documentação do Textcaster
• Source namespace para RSS 2.0
• RSS 2.0 Specification - Harvard
• RSS Advisory Board - história do RSS
• RssCloud API
• OPML 2.0 Specification
• CommonMark Specification 0.31.2
• rss.chat - repositório oficial
• RSS as a social network
• Feed RSS real de um usuário do rss.chat
• RSC - Really Simple Conversations
• RSC - página About
• FeedLand - documentação oficial
• Documentação do WordLand
• Repositório de suporte do WordLand
• WP Tavern - entrevista com Dave Winer sobre publicação aberta
• ActivityPub - recomendação W3C
• Mastodon - documentação de ActivityPub
• ActivityPub para WordPress
• WebSub - recomendação W3C
• Micropub - recomendação W3C
• Webmention - recomendação W3C
• JSON Feed 1.1
• IndieWeb - POSSE
• AT Protocol - especificação
• Bluesky - arquitetura de federação
• Nostr NIP-23 - conteúdo longo em Markdown
• Columbia Journalism Review - história técnica do podcasting
• Digital Humanities Quarterly - RSS e história do podcasting
• Jeffrey Zeldman - experiência prática com WordLand

Nota sobre atualidade

Pesquisa concluída em 23 de julho de 2026. rss.chat, RSC, WordLand e as extensões do namespace source: estão em evolução rápida. Estado de repositórios, versões, funcionalidades e compatibilidade deve ser confirmado nos links oficiais antes de decisões de implementação.