Uma lista prática de protocolos, redes e formatos que orbitam a ideia de small web, smolnet, indieweb, alt web, redes textuais, redes federadas e publicação pessoal fora do modelo pesado da Web moderna.

A ideia aqui não é fingir que todos são igualmente úteis. Não são. Alguns são vivos e usáveis hoje. Outros são históricos, obscuros ou interessantes apenas como referência técnica. Para projeto real, você deve separar o que é instalável e útil do que é apenas curiosidade de laboratório.

Resumo brutalmente honesto

Se você quer algo bonito, simples e realmente usável hoje, a ordem prática seria:

1. Gemini — melhor equilíbrio entre minimalismo, hipertexto e comunidade.
2. Gopher — histórico, charmoso, simples, ainda vivo em nichos.
3. Spartan — ainda mais simples que Gemini, bom para experimentação.
4. Finger — excelente para presença, perfil, status e micropublicação textual.
5. Nex — promissor no universo smolnet, mas bem menor.
6. Scroll — interessante como variação moderna textual.
7. NNTP — muito bom se você pensa em fóruns, grupos e mensagens distribuídas.
8. ActivityPub — não é “small” no sentido técnico, mas é essencial se você quer Fediverso.
9. Micropub/Webmention — fundamentais para IndieWeb moderno.
10. IPFS/Hypercore/SSB/Nostr — bons se você quer descentralização mais radical, mas aumentam complexidade.

Minha recomendação prática: para um site pessoal ou projeto tipo pablo.space, weirdnet, runv.club ou um diretório smallweb, eu começaria com HTTP leve + Gemini + Gopher + Finger + RSS/Atom + Webmention/Micropub. Depois adicionaria ActivityPub se fizer sentido social.

1. Protocolos diretamente ligados à SmolNet / Small Internet

1. Finger

• Esquema: finger://
• Porta comum: 79
• Tipo: consulta textual simples de usuário/host
• Uso clássico: ver informações de usuários em sistemas Unix
• Uso moderno: página de perfil, status, bio, presença, “agora estou fazendo...”
• Complexidade: muito baixa
• Vale usar? Sim, especialmente em pubnix, tilde, comunidade Unix ou projeto retro.

Finger é um dos protocolos mais simples e subestimados. Ele serve basicamente para perguntar a um servidor: “o que você sabe sobre este usuário?”. Em uma comunidade como runv.club, por exemplo, ele cairia muito bem para mostrar bio, site, última atividade ou status textual.

Exemplo conceitual:

finger pablo@runv.club

2. Gopher+

• Esquema: geralmente ainda gopher://
• Tipo: extensão do Gopher original
• Uso: adiciona atributos e metadados ao Gopher
• Complexidade: baixa a média
• Vale usar? Só se você já está no ecossistema Gopher.

Gopher+ tentou resolver limitações do Gopher original adicionando metadados, atributos e recursos extras. É interessante, mas não é tão universal quanto Gopher puro.

3. Gophers

• Esquema: gophers://
• Tipo: Gopher com TLS
• Uso: versão criptografada do Gopher
• Complexidade: baixa
• Vale usar? Sim, se você quer Gopher sem trafegar tudo em texto claro.

Gopher tradicional é simples demais, inclusive no sentido de segurança. gophers:// tenta corrigir isso usando TLS.

4. Nex

• Esquema: nex://
• Porta comum: 1900
• Tipo: protocolo textual minimalista
• Uso: documentos simples, páginas textuais, smolnet
• Complexidade: baixa
• Vale usar? Para experimentar, sim. Para público amplo, ainda é nichado.

Nex é um protocolo pequeno da smolnet. Ele aparece em proxies e navegadores alternativos junto de Gemini, Gopher e Spartan. A proposta é ser ainda mais simples e direto, com menos cerimônia.

Cuidado: existe também “NEX” no mundo Nintendo/Quazal, que não tem nada a ver com smallweb. Aqui estamos falando do nex:// da smolnet.

5. Text Protocol

• Esquema: text://
• Porta comum: 1961 em algumas implementações
• Tipo: entrega de texto puro
• Uso: páginas minimalistas em texto
• Complexidade: muito baixa
• Vale usar? Como experimento, sim. Como base principal, provavelmente não.

A ideia é quase brutal: pedir texto e receber texto. Pouca estrutura, pouco peso, pouca mágica.

6. SuperText / SuperTXT

• Esquema: geralmente associado a ssh:// ou implementações próprias
• Tipo: publicação textual via SSH
• Uso: hospedagem e navegação textual minimalista
• Complexidade: média
• Vale usar? Interessante para comunidades técnicas.

SuperTXT mistura a ideia de small web com acesso via SSH. É bem alinhado com pubnix, tilde servers e cultura de terminal.

7. Scroll

• Esquema: scroll://
• Porta comum: 1961
• Tipo: protocolo textual inspirado por Gemini
• Uso: documentos textuais com metadados e negociação simples
• Complexidade: baixa a média
• Vale usar? Sim, se você gosta de testar protocolos novos.

Scroll é uma variação moderna dentro da smolnet. Tem ideias como metadados e negociação de idioma. É menor que Gemini, mas tecnicamente interessante.

8. Scorpion

• Esquema: scorpion://
• Tipo: protocolo alternativo experimental
• Uso: small internet / alt web
• Complexidade: baixa a média
• Vale usar? Mais para estudo.

Scorpion aparece nas listas de protocolos smolnet, mas é bem mais obscuro que Gemini, Gopher, Spartan ou Finger.

9. Mercury

• Esquema: mercury://
• Tipo: protocolo experimental da smolnet
• Uso: publicação textual alternativa
• Complexidade: baixa a média
• Vale usar? Só se você estiver explorando o ecossistema.

Mercury é outro protocolo pequeno, mais interessante como peça de pesquisa do que como base de projeto público.

10. Titan

• Esquema: titan://
• Tipo: protocolo complementar ao Gemini
• Uso: upload/publicação de conteúdo em servidores Gemini
• Complexidade: média
• Vale usar? Sim, se você usa Gemini e quer publicação remota.

Titan não é exatamente um substituto de Gemini. Ele é mais uma extensão/protocolo auxiliar para envio de conteúdo, frequentemente associado ao ecossistema Gemini.

11. Guppy

• Esquema: guppy://
• Tipo: protocolo experimental minimalista
• Uso: smallweb textual
• Complexidade: baixa
• Vale usar? Curiosidade técnica.

Guppy é outro protocolo pequeno da smolnet. O valor aqui é mais filosófico/técnico do que prático.

12. Molerat

• Esquema: molerat://
• Tipo: protocolo smolnet experimental
• Uso: publicação textual alternativa
• Complexidade: baixa a média
• Vale usar? Só por curiosidade.

Molerat é obscuro. Eu não colocaria como prioridade em nenhum projeto real.

13. Terse

• Esquema: terse://
• Tipo: protocolo extremamente minimalista
• Uso: texto curto, documentos simples, experimentação
• Complexidade: muito baixa
• Vale usar? Como estudo de minimalismo extremo.

O nome já entrega a filosofia: ser curto, direto, mínimo.

14. FSP

• Esquema: fsp://
• Tipo: protocolo antigo de transferência de arquivos
• Uso: alternativa leve a FTP
• Complexidade: média
• Vale usar? Hoje, raramente.

FSP é mais voltado para transferência de arquivos do que para publicação hipertextual. Historicamente interessante, mas pouco relevante para um site moderno.

2. Protocolos clássicos da internet que combinam com smallweb

15. NNTP / Usenet

• Esquemas: nntp://, news://, snews://
• Porta comum: 119; com TLS, 563
• Tipo: grupos de discussão distribuídos
• Uso: fóruns, newsgroups, comunidades assíncronas
• Complexidade: média
• Vale usar? Sim, se você quer comunidades textuais sérias.

NNTP é uma das melhores ideias antigas da internet. Ele não é “site”, é discussão distribuída. Se você quer algo tipo fórum, mas com espírito velho da internet, NNTP merece respeito.

16. IRC

• Esquema: irc://, ircs://
• Porta comum: 6667; com TLS, 6697
• Tipo: chat em tempo real
• Uso: canais, suporte, comunidades técnicas
• Complexidade: baixa a média
• Vale usar? Sim.

IRC é velho, simples e ainda funciona. Não é protocolo de publicação, mas é perfeito para comunidade. Para projetos como pubnix, tilde, software livre e grupos técnicos, ainda faz todo sentido.

17. XMPP

• Esquema: xmpp:
• Tipo: mensagens federadas
• Uso: chat, presença, bots, notificações
• Complexidade: média
• Vale usar? Sim, mas exige paciência.

XMPP é federado, aberto e maduro. Pode servir para chat pessoal, comunidade, bots e notificações. É mais complexo que IRC, mas mais moderno em recursos.

18. Telnet

• Esquema: telnet://
• Porta comum: 23
• Tipo: terminal remoto sem criptografia
• Uso: BBS, sistemas retrô, demos textuais
• Complexidade: baixa
• Vale usar? Apenas em ambiente controlado ou retrô. Não use para login real sem túnel seguro.

Telnet é inseguro, mas culturalmente importante. Para BBS ou arte terminal, pode ser divertido. Para administração real, é loucura.

19. SSH

• Esquema: ssh://
• Porta comum: 22
• Tipo: shell remoto seguro
• Uso: pubnix, hospedagem pessoal, git, apps textuais, BBS modernas
• Complexidade: média
• Vale usar? Sim, muito.

SSH não é “web”, mas é um dos melhores protocolos para small communities. Um pubnix vive disso. Você pode criar dashboards, clientes TUI, leitores, menus, blogs via terminal e ambientes sociais inteiros.

20. FTP / FTPS / SFTP

• Esquemas: ftp://, ftps://, sftp://
• Tipo: transferência de arquivos
• Uso: publicação, upload, espelhamento
• Complexidade: baixa a média
• Vale usar? SFTP sim; FTP puro, melhor evitar.

FTP foi importantíssimo, mas hoje SFTP é a opção sensata para transferência simples e segura.

21. DICT

• Esquema: dict://
• Porta comum: 2628
• Tipo: consulta a dicionários
• Uso: definições, glossários, bancos textuais
• Complexidade: baixa
• Vale usar? Para projetos educacionais ou acervos, sim.

DICT é perfeito para consultar dicionários e bases textuais. Para um projeto educacional, pode ser uma ideia bonita: glossários técnicos acessíveis por protocolo simples.

22. WHOIS

• Porta comum: 43
• Tipo: consulta de registros
• Uso: domínios, IPs, informações de rede
• Complexidade: baixa
• Vale usar? Como ferramenta, não como base de site.

WHOIS é simples e textual. Não serve para publicar conteúdo pessoal, mas representa bem a internet textual antiga.

23. QOTD

• Porta comum: 17
• Tipo: quote of the day
• Uso: retornar uma frase curta
• Complexidade: ridiculamente baixa
• Vale usar? Como brincadeira retro.

QOTD é praticamente um haicai protocolar: conecta, recebe uma frase, fecha. Para arte, bots ou nostalgia, é simpático.

24. Daytime / Time Protocol

• Portas comuns: 13 / 37
• Tipo: hora/data via rede
• Uso: histórico, diagnóstico, sistemas simples
• Complexidade: muito baixa
• Vale usar? Hoje, quase nunca.

São protocolos antigos de tempo. Hoje NTP venceu, com razão.

25. TCPMUX

• Porta comum: 1
• Tipo: multiplexação de serviços TCP
• Uso: histórico/experimental
• Complexidade: baixa
• Vale usar? Não como prioridade.

TCPMUX aparece em listas de protocolos obscuros. Interessante para arqueologia de rede, não para produto.

3. Protocolos e padrões IndieWeb

26. RSS

• Tipo: feed XML
• Uso: assinaturas, blogs, notícias, podcasts
• Complexidade: baixa
• Vale usar? Sim. Sempre.

RSS não é exatamente um protocolo de transporte, mas é essencial. É uma das tecnologias mais importantes para uma web independente. Se seu site não tem RSS, ele está incompleto.

27. Atom

• Tipo: feed XML mais formal que RSS
• Uso: blogs, atualizações, leitores de feed
• Complexidade: baixa a média
• Vale usar? Sim.

Atom é mais rigoroso e limpo que RSS em alguns pontos. Na prática, ofereça RSS e/ou Atom. O importante é ter feed.

28. JSON Feed

• Tipo: feed em JSON
• Uso: leitores modernos, apps, integrações
• Complexidade: baixa
• Vale usar? Sim, como extra.

JSON Feed é confortável para programadores. Eu não substituiria RSS por ele, mas ofereceria como opção adicional.

29. Webmention

• Tipo: padrão IndieWeb para menções entre sites
• Uso: comentários distribuídos, replies, likes, reposts entre sites
• Complexidade: média
• Vale usar? Sim, se você quer IndieWeb de verdade.

Webmention permite que um site avise outro: “eu linkei você”. É a base para comentários e interações distribuídas sem depender de plataforma social centralizada.

30. Micropub

• Tipo: API padrão para publicar em sites
• Uso: postar notas, artigos, fotos, replies, likes
• Complexidade: média
• Vale usar? Sim, muito.

Micropub é excelente se você quer postar no seu site a partir de clientes externos. Para sua ideia de facilidade de postagem, Micropub é mais importante do que parece.

31. Microsub

• Tipo: API para leitores/feed readers IndieWeb
• Uso: separar backend de assinatura/leitura da interface
• Complexidade: média
• Vale usar? Sim, se você quer construir leitor social próprio.

Microsub é menos famoso que Micropub, mas é muito bom para criar uma experiência de leitura pessoal.

32. WebSub

• Tipo: pub/sub para feeds
• Uso: notificar atualizações de RSS/Atom quase em tempo real
• Complexidade: média
• Vale usar? Sim, se atualização rápida importa.

WebSub evita que leitores precisem ficar consultando seu feed o tempo todo. Muito útil para feeds vivos.

33. IndieAuth

• Tipo: autenticação descentralizada baseada em domínio/site pessoal
• Uso: login para ferramentas IndieWeb
• Complexidade: média
• Vale usar? Sim, se você vai usar Micropub/Webmention seriamente.

IndieAuth permite que seu domínio seja sua identidade. É peça importante do ecossistema IndieWeb.

4. Protocolos federados e sociais

34. ActivityPub

• Tipo: protocolo federado social
• Uso: Mastodon, GoToSocial, Pixelfed, PeerTube, Lemmy, BookWyrm etc.
• Complexidade: alta
• Vale usar? Sim, se o objetivo é federação social.

ActivityPub não é minimalista. É pesado, chato, cheio de bordas estranhas. Mas é o protocolo social federado mais importante hoje. Se você quer interação social com o Fediverso, é ele.

35. OStatus

• Tipo: protocolo social federado antigo
• Uso: StatusNet, GNU social antigo
• Complexidade: alta
• Vale usar? Não para projeto novo.

OStatus foi importante historicamente, mas ActivityPub tomou o lugar.

36. Diaspora Protocol

• Tipo: federação social
• Uso: rede Diaspora
• Complexidade: alta
• Vale usar? Só se você quer interoperar com Diaspora.

Diaspora foi relevante na história das redes sociais federadas. Hoje eu não escolheria como base para projeto novo.

37. AT Protocol

• Tipo: protocolo social federado/portável
• Uso: Bluesky e ecossistema ATProto
• Complexidade: alta
• Vale usar? Sim para pesquisa, mas ainda menos “faça você mesmo” que ActivityPub.

AT Protocol é tecnicamente interessante, especialmente por identidade, repositórios pessoais e portabilidade. Mas não tem a mesma cultura smallweb do IndieWeb/Gemini/Gopher.

38. Nostr

• Tipo: rede social descentralizada baseada em relays e chaves públicas
• Uso: posts, mensagens, identidade, pagamentos, comunidades
• Complexidade: média
• Vale usar? Sim, se você aceita o estilo cripto/cypherpunk.

Nostr é simples em alguns aspectos e caótico em outros. A ideia de identidade por chave pública é forte, mas a experiência social pode virar bagunça rápido.

39. Matrix

• Tipo: comunicação federada em tempo real
• Uso: chat, comunidades, bridges
• Complexidade: alta
• Vale usar? Sim, mas prepare servidor forte.

Matrix é poderoso, mas não é leve. Para smallweb raiz, é pesado demais. Para comunicação moderna federada, é muito relevante.

40. Secure Scuttlebutt / SSB

• Tipo: rede social peer-to-peer/offline-first
• Uso: feeds pessoais replicados, comunidades descentralizadas
• Complexidade: média a alta
• Vale usar? Como inspiração, sim. Como projeto público novo, cuidado.

SSB é uma das ideias mais bonitas de rede social distribuída: cada pessoa tem um log assinado e replica com pares. Mas o ecossistema não é tão popular quanto já pareceu que seria.

5. Protocolos e redes peer-to-peer / descentralizadas

41. IPFS

• Tipo: rede de conteúdo endereçado por hash
• Uso: arquivos, sites estáticos, distribuição descentralizada
• Complexidade: média
• Vale usar? Sim, para arquivamento e distribuição.

IPFS é bom para conteúdo imutável ou versionado. Para site dinâmico, não é tão simples. Para arquivos, acervos e espelhos, é excelente.

42. IPNS

• Tipo: camada de nomes mutáveis sobre IPFS
• Uso: apontar um nome para conteúdo IPFS atualizado
• Complexidade: média
• Vale usar? Sim, se você usa IPFS para site.

IPNS resolve o problema básico do IPFS: hashes mudam quando o conteúdo muda. Ele permite publicar um nome que aponta para a versão atual.

43. Hypercore / Hyperdrive

• Tipo: logs append-only e drives P2P
• Uso: sites, bancos replicados, apps locais-first
• Complexidade: média
• Vale usar? Sim, tecnicamente muito interessante.

Hypercore é uma tecnologia elegante para dados replicáveis e append-only. O ecossistema mudou bastante desde a época do Dat/Beaker Browser, mas a ideia continua forte.

44. Dat

• Tipo: antecessor/ecossistema ligado ao Hypercore
• Uso: compartilhamento P2P de arquivos e sites
• Complexidade: média
• Vale usar? Mais como referência histórica.

Dat foi muito empolgante na época do Beaker Browser. Hoje, Hypercore é o nome mais relevante.

45. BitTorrent

• Tipo: distribuição P2P de arquivos
• Uso: arquivos grandes, mídia, datasets, espelhos
• Complexidade: baixa a média
• Vale usar? Sim, para distribuição de arquivos.

BitTorrent não é web alternativa no sentido de páginas, mas é excelente para distribuir conteúdo pesado sem depender de um servidor central.

46. GNUnet

• Tipo: framework de rede descentralizada
• Uso: identidade, publicação, nomes, privacidade
• Complexidade: alta
• Vale usar? Para pesquisa séria, sim. Para projeto simples, não.

GNUnet é ambicioso e tecnicamente interessante, mas não é plug-and-play.

47. Freenet / Hyphanet

• Tipo: rede descentralizada anônima/resistente à censura
• Uso: publicação anônima, armazenamento distribuído
• Complexidade: alta
• Vale usar? Apenas se privacidade/resistência for prioridade.

Freenet, hoje Hyphanet em parte do ecossistema, é mais sobre resistência à censura do que smallweb simpática.

48. I2P

• Tipo: rede anônima overlay
• Uso: sites internos, mensagens, torrents, serviços anônimos
• Complexidade: média a alta
• Vale usar? Sim, para privacidade forte.

I2P cria uma internet interna anônima. Não é substituto simples de site público, mas é excelente se o foco é privacidade e autonomia.

49. Tor Onion Services

• Esquema: geralmente acessado via .onion
• Tipo: serviços anônimos sobre Tor
• Uso: sites, APIs, SSH, serviços privados
• Complexidade: média
• Vale usar? Sim, como camada extra.

Um site onion é uma boa adição para projetos de privacidade, espelhos e acesso alternativo. Não é exatamente smallweb, mas combina com autonomia.

50. ZeroNet

• Tipo: sites P2P com BitTorrent e Bitcoin crypto primitives
• Uso: sites descentralizados
• Complexidade: média
• Vale usar? Hoje, eu teria cautela.

ZeroNet foi uma ideia legal, mas o ecossistema perdeu força. Vale estudar, mas eu não apostaria um projeto novo nele sem motivo forte.

6. Protocolos de publicação, sincronização e colaboração

51. WebDAV

• Tipo: extensão HTTP para edição/arquivos remotos
• Uso: sincronização, edição remota, calendários/contatos via extensões
• Complexidade: média
• Vale usar? Sim.

WebDAV é velho, mas útil. Nextcloud, calendários e vários apps ainda dependem dele ou de parentes próximos.

52. CalDAV

• Tipo: calendários via WebDAV
• Uso: agenda sincronizada
• Complexidade: média
• Vale usar? Sim.

CalDAV é essencial se você quer agenda aberta e independente de Google/Microsoft.

53. CardDAV

• Tipo: contatos via WebDAV
• Uso: agenda de contatos sincronizada
• Complexidade: média
• Vale usar? Sim.

CardDAV faz para contatos o que CalDAV faz para calendários. Não é glamouroso, mas é infraestrutura aberta útil.

54. Git protocol / Git over SSH / Git over HTTP

• Tipo: versionamento distribuído
• Uso: código, sites estáticos, notas, wikis
• Complexidade: média
• Vale usar? Sim, muito.

Git é uma das melhores tecnologias de publicação pessoal. Um site estático versionado por Git é simples, auditável e portátil.

55. rsync

• Tipo: sincronização eficiente de arquivos
• Uso: deploy, backups, espelhos
• Complexidade: baixa a média
• Vale usar? Sim.

rsync é feio, velho e maravilhoso. Para deploy de site estático, backup e espelho, é difícil bater.

7. Protocolos de email e comunicação assíncrona

56. SMTP

• Tipo: envio de e-mail
• Uso: comunicação assíncrona universal
• Complexidade: alta quando autohospedado
• Vale usar? Sim, mas autohospedar é dor.

SMTP é o grande protocolo social federado que todo mundo esquece que é federado. O problema é reputação, spam, DKIM, SPF, DMARC e entregabilidade.

57. IMAP

• Tipo: acesso a caixas de e-mail
• Uso: clientes de e-mail, sincronização de mensagens
• Complexidade: média
• Vale usar? Sim.

IMAP é essencial para e-mail moderno com múltiplos clientes.

58. POP3

• Tipo: recebimento simples de e-mail
• Uso: baixar mensagens localmente
• Complexidade: baixa
• Vale usar? Só em casos específicos.

POP3 é simples, mas limitado. IMAP normalmente é melhor.

59. JMAP

• Tipo: API moderna para e-mail/calendário/contatos
• Uso: alternativa moderna ao IMAP/SMTP em alguns cenários
• Complexidade: média
• Vale usar? Sim, se o servidor suportar.

JMAP é uma tentativa bem mais moderna de lidar com e-mail e dados pessoais. Tecnicamente interessante, mas ainda menos universal que IMAP/SMTP.

8. Protocolos de busca, descoberta e diretórios

60. OpenSearch

• Tipo: descrição de mecanismo de busca
• Uso: integrar busca de sites no navegador/leitores
• Complexidade: baixa
• Vale usar? Sim.

OpenSearch é simples e útil: permite que outros clientes saibam como pesquisar no seu site.

61. Sitemap XML

• Tipo: mapa de URLs para indexação
• Uso: descoberta por buscadores
• Complexidade: baixa
• Vale usar? Sim.

Sitemap não é protocolo alternativo, mas é infraestrutura essencial de descoberta.

62. robots.txt

• Tipo: arquivo de política para crawlers
• Uso: controle básico de indexação
• Complexidade: baixa
• Vale usar? Sim.

Outro padrão simples e importante. Smallweb também precisa de boas maneiras com crawlers.

63. Well-known URIs

• Exemplo: /.well-known/
• Tipo: convenção de descoberta
• Uso: WebFinger, NodeInfo, security.txt, host-meta etc.
• Complexidade: baixa a média
• Vale usar? Sim.

O diretório .well-known é uma peça discreta mas poderosa da web moderna descentralizada.

64. WebFinger

• Tipo: descoberta de identidade
• Uso: Fediverso, contas tipo @user@domain
• Complexidade: baixa a média
• Vale usar? Sim, se você mexe com Fediverso.

WebFinger permite descobrir informações de uma identidade em formato usuario@dominio. É fundamental para ActivityPub.

65. NodeInfo

• Tipo: metadados de servidores federados
• Uso: expor software, versão, estatísticas e recursos
• Complexidade: baixa
• Vale usar? Sim, para serviços federados.

NodeInfo é usado por servidores do Fediverso para se descreverem.

9. Protocolos mais obscuros, mas interessantes

66. Plan 9 9P

• Tipo: protocolo de sistema de arquivos distribuído
• Uso: Plan 9, Inferno, sistemas distribuídos elegantes
• Complexidade: média a alta
• Vale usar? Como inspiração técnica, sim.

9P é uma joia conceitual. Ele trata recursos como arquivos de maneira muito elegante. Não é para site público comum, mas é muito bonito tecnicamente.

67. Gemini over Tor / Gopher over Tor

• Tipo: combinação de protocolos smallweb com rede onion
• Uso: publicação minimalista privada/anônima
• Complexidade: média
• Vale usar? Sim, para espelhos privados.

Não é um protocolo novo, mas uma combinação poderosa: Gemini ou Gopher expostos como serviço onion.

68. UUCP

• Tipo: troca de arquivos/mensagens store-and-forward
• Uso: redes antigas, sistemas offline/intermitentes
• Complexidade: média
• Vale usar? Como inspiração para redes lentas/offline.

UUCP é importantíssimo historicamente. A ideia de redes assíncronas e intermitentes conversa muito com permacomputação.

69. Fidonet / FTN

• Tipo: rede de BBS store-and-forward
• Uso: mensagens, fóruns, BBS
• Complexidade: média
• Vale usar? Para projeto retrô/comunitário, talvez.

Fidonet foi uma rede social antes das redes sociais. Para comunidades nostálgicas, ainda tem charme.

70. Hotline

• Tipo: sistema cliente-servidor para chat, arquivos e fóruns
• Uso: comunidades fechadas, arquivos, mensagens
• Complexidade: média
• Vale usar? Mais nostalgia do que futuro.

Hotline marcou época. Não é o caminho mais racional hoje, mas é uma referência cultural interessante.

10. Protocolos que eu priorizaria para um projeto seu

Stack smallweb realista

Se a ideia é criar algo bonito, útil e sustentável, eu faria assim:

Camada pública principal

• HTTP/HTTPS leve
• Site estático ou CMS simples
• RSS/Atom
• JSON Feed
• Sitemap XML
• robots.txt
• OpenSearch

Camada IndieWeb

• Webmention
• Micropub
• IndieAuth
• h-card / h-entry / microformats2

Camada Small Internet

• Gemini
• Gopher ou Gophers
• Finger
• Spartan, se quiser experimentar
• Nex ou Scroll como extra experimental

Camada social/federada

• ActivityPub se quiser interação com Mastodon/GoToSocial/etc.
• WebFinger
• NodeInfo

Camada comunitária

• IRC ou XMPP
• SSH para pubnix
• NNTP se quiser fóruns estilo old internet

Camada preservação/distribuição

• IPFS para arquivos e espelhos
• BitTorrent para pacotes grandes
• Git para versionamento e publicação
• rsync para deploy e backup

11. Ranking prático

Excelentes para usar agora

1. RSS/Atom
2. Gemini
3. Gopher/Gophers
4. Finger
5. Micropub
6. Webmention
7. IndieAuth
8. ActivityPub
9. IRC
10. SSH
11. Git over SSH
12. rsync
13. IPFS
14. NNTP
15. XMPP

Bons, mas mais nichados

1. Spartan
2. Nex
3. Scroll
4. Titan
5. JSON Feed
6. WebSub
7. Microsub
8. DICT
9. Tor Onion Services
10. Hypercore
11. Nostr
12. Matrix

Mais experimentais/obscuros

1. Text Protocol
2. SuperTXT
3. Scorpion
4. Mercury
5. Guppy
6. Molerat
7. Terse
8. FSP
9. QOTD
10. TCPMUX
11. UUCP
12. Fidonet
13. Hotline

12. Ideias concretas de implementação

Para site pessoal

• https://pablomurad.com como site principal
• gemini://pablomurad.com com textos limpos
• gopher://pablomurad.com com menus e arquivos
• finger pablo@pablomurad.com mostrando bio/status
• RSS/Atom para posts
• Webmention para comentários distribuídos
• Micropub para postar de qualquer cliente

Para pubnix / comunidade

• SSH para contas de usuários
• Finger para perfis
• Gopher para diretórios pessoais
• Gemini para blogs dos usuários
• IRC para comunidade
• NNTP para fóruns persistentes
• RSS global agregando atividade dos usuários

Para um diretório smallweb

• Catálogo HTTP leve
• Espelho Gemini
• Espelho Gopher
• Indexação de Finger/Gemini/Gopher
• Feeds RSS por categoria
• OpenSearch para busca
• Webmention para submissões externas

Para educação / Portal IDEA

Aqui eu seria seletivo. Não faz sentido enfiar Gemini e Gopher no Portal IDEA principal como se aluno comum fosse usar. Mas faz sentido criar uma área experimental:

• Glossários via DICT ou HTTP leve
• Biblioteca textual com Gemini
• RSS/Atom por categoria de curso
• WebSub para notificação de novos cursos
• Micropub para publicação interna rápida
• IPFS para acervos públicos ou materiais estáticos

13. Conclusão

Spartan, Gemini e Gopher são ótimos, mas eles são só a porta de entrada. O universo maior inclui protocolos textuais antigos, experimentos smolnet, padrões IndieWeb, redes federadas, redes P2P e ferramentas clássicas de Unix.

O erro seria tentar usar tudo. Isso vira zoológico técnico.

O caminho inteligente é escolher uma pilha coerente:

HTTP leve + RSS/Atom + Gemini + Gopher + Finger + Webmention + Micropub

Depois, se houver motivo real:

ActivityPub + IPFS + NNTP + IRC/XMPP

E só depois brincar com:

Nex + Scroll + Titan + Text + Scorpion + Mercury + Guppy + Terse

A regra é simples: protocolo bom não é o mais exótico. É o que ajuda você a publicar, descobrir, preservar e interagir com menos dependência de plataformas gigantes.

Fontes e referências consultadas

• ArchiveTeam — SmolNet: lista vários protocolos associados ao ecossistema smolnet, incluindo gemini://, gopher://, finger://, spartan://, text://, nex://, scroll://, titan://, guppy://, molerat://, terse://, fsp://, além de protocolos relacionados como telnet://, nntp://, dict://, QOTD e TCPMUX.
• SmolNet Portal / DeepWiki: documenta suporte a Gemini, Gopher/Gophers, Scroll, Finger, Spartan, Text e Nex, com portas e características gerais.
• Documentação e comunidades IndieWeb: Micropub, Webmention, IndieAuth, Microsub e WebSub.
• Ecossistemas federados e descentralizados: ActivityPub, AT Protocol, Nostr, Matrix, IPFS, Hypercore, SSB, Tor e I2P.