Da camada física às redes sociais descentralizadas — uma visão completa do ecossistema além da web comercial.
Índice
- Por Que Isso Importa
- Como Organizar Este Mapa
- Protocolos de Acesso e Navegação
- Protocolos de Comunicação e Mensagens
- Sistemas de Comunidades e Redes Históricas
- Redes Descentralizadas e o Fediverso
- Protocolos de Distribuição de Arquivos
- Redes Anônimas e Privadas
- Micro-protocolos e Formatos Alternativos
- Tabela Comparativa Geral
- Como as Camadas Se Relacionam
- O Que Tudo Isso Tem em Comum
1. Por Que Isso Importa
Quando se fala em internet, a maioria das pessoas pensa em navegadores, aplicativos e plataformas comerciais. Mas a internet real, a pilha de protocolos que sustenta tudo, é muito mais vasta e diversa do que a camada visível sugere.
Abaixo e ao lado da web dominada por grandes empresas existe um ecossistema inteiro de protocolos, sistemas e comunidades que seguem lógicas diferentes: mais simples, mais leves, mais descentralizadas, mais antigas, ou deliberadamente construídas para escapar das falhas do modelo comercial. Muitos foram criados décadas antes das plataformas atuais. Outros são respostas técnicas modernas a problemas que o HTTP e o HTML nunca resolveram bem: privacidade, censura, dependência de servidores centrais, rastreamento e abusos de moderação.
Esses protocolos não são, em geral, superiores em conforto. Muitos exigem mais esforço técnico, têm interfaces brutas ou comunidades menores. Mas cada um revela algo sobre o espaço de design possível da comunicação digital e sobre escolhas que foram feitas, e poderiam ter sido feitas de outra forma.
2. Como Organizar Este Mapa
Para entender este ecossistema, é útil pensar em camadas, não as camadas do modelo OSI, mas agrupamentos por função e propósito:
| Camada Funcional | Exemplos de Protocolos |
|---|---|
| Acesso e navegação de conteúdo | Gopher, Gemini, HTTP, Finger |
| Comunicação em tempo real | IRC, Matrix, XMPP |
| Comunicação assíncrona | NNTP/Usenet, SMTP/email, FidoNet |
| Comunidade e presença social | BBS, Tildeverse, twtxt |
| Redes sociais descentralizadas | ActivityPub, Nostr, SSB |
| Distribuição de arquivos | BitTorrent/DHT, IPFS |
| Anonimato e privacidade | Tor, I2P |
| Descoberta e identidade | WebFinger, DNS |
Cada seção a seguir aprofunda um ou mais desses protocolos, cobrindo sua arquitetura técnica, história, limitações reais e como se relaciona com os demais.
3. Protocolos de Acesso e Navegação
3.1 Gopher — O Precursor da Web
RFC: 1436 (março de 1993) | Porta: 70 (TCP) | Esquema de URL: gopher://
O Gopher foi criado em 1991 pela Universidade de Minnesota. A especificação RFC 1436, publicada em março de 1993, descreve um protocolo de busca e recuperação de documentos distribuídos: o cliente envia uma linha de seleção ao servidor, o servidor responde com um bloco de texto e fecha a conexão. Sem estado, sem cookies e sem sessões.
O formato de resposta central do Gopher é o gophermap: um arquivo de texto onde cada linha define um item de menu com tipo, nome, seletor, host e porta separados por tabulações. Os tipos de item incluem texto (0), diretórios (1), binários (9), imagens GIF (g), HTML (h) e sons (s).
# Exemplo de gophermap
1Meu diretório de notas /notas meuservidor.net 70
0Sobre mim /sobre.txt meuservidor.net 70
hLink para a web URL:https://exemplo.com meuservidor.net 70O Gopher foi amplamente usado antes de 1993 e 1994, quando o Mosaic e o HTTP começaram a dominar. A Universidade de Minnesota tomou uma decisão controversa de cobrar por licenças do software Gopher em 1993, o que acelerou a migração para o HTTP, que a CERN declarou de domínio público. O resultado foi que o Gopher perdeu praticamente todo o crescimento para a web em dezoito meses.
Hoje, o protocolo ainda tem adeptos na comunidade de pubnixes e tildes, que mantêm gopherholes ativos. Clientes modernos incluem Lagrange, Bombadillo, Lynx e a extensão OverbiteNX para Firefox via proxy.
Limitações honestas: sem TLS nativo, sem formatação rica, sem imagens inline e sem JavaScript. O próprio RFC 1436 não define autenticação.
3.2 Gemini — O Caminho do Meio
Iniciado: junho de 2019 | Porta: 1965 (TCP+TLS) | Esquema: gemini:// | Versão atual: 0.16.1 (janeiro de 2022)
O Gemini foi criado por um desenvolvedor pseudônimo chamado Solderpunk como resposta explícita à complexidade da web e à brutalidade do Gopher. Conforme a especificação de trabalho, Gemini roda sobre TCP na porta 1965, referência à missão Gemini 3, com TLS obrigatório.
O ciclo de vida de uma requisição Gemini é intencionalmente simples:
- Cliente abre conexão TCP+TLS ao servidor
- Cliente envia uma URL completa seguida de
\r\n - Servidor responde com uma linha de status + MIME type, seguida do corpo
- Servidor fecha a conexão
# Exemplo de transação Gemini
→ Cliente: gemini://tilde.town/~usuario/\r\n
← Servidor: 20 text/gemini\r\n
← Servidor: # Minha cápsula Gemini\n
Bem-vindo...\nO gemtext é o formato nativo. A especificação define apenas seis tipos de linha: texto normal, link (=>), cabeçalho (#, ##, ###), lista (*), citação (>) e bloco pré-formatado.
# Exemplo de arquivo .gmi
# Minha Página Gemini
Parágrafo normal aqui.
=> gemini://outro.site/ Um link para outra cápsula
=> https://web.exemplo.com/ Um link externo para a web
## Seção
* Item de lista um
* Item dois
> Uma citação
```código
echo "bloco pré-formatado"
```O design é deliberadamente não extensível. Não há headers opcionais como no HTTP, não há cookies, não há JavaScript e não há formas simples de injetar tracking pixels. Essa inflexibilidade é uma feature.
Projetos que servem Gemini incluem Agate, Molly Brown e Jetforce. Clientes populares incluem Lagrange, Amfora, Elpher e Kristall.
3.3 Finger — A Presença Social de 1971
RFC: 742 (dezembro de 1977), atualizado pelo RFC 1288 (1991) | Porta: 79 (TCP)
O Finger foi escrito em 1971 por Les Earnest na Universidade de Stanford como resposta a uma necessidade prática: usuários queriam saber quem estava logado no sistema antes de ir fisicamente ao laboratório. É provavelmente a primeira forma de informação de presença remota em rede de computadores.
Do ponto de vista técnico, o protocolo é trivial: o cliente abre uma conexão TCP na porta 79, envia uma linha de consulta e aguarda a resposta do daemon fingerd. O servidor retorna informações sobre o usuário, como nome real, localização, tempo de login e o conteúdo dos arquivos ~/.plan e ~/.project, se existirem.
# Consultar informações sobre um usuário
finger usuario@tilde.town
# Consultar todos os usuários logados
finger @sdf.org
# Ver quem está online localmente
fingerO ~/.plan se tornou o equivalente pré-web de uma bio ou feed de status. Nos anos 1990, John Carmack ficou famoso por manter um .plan detalhado com atualizações técnicas sobre o desenvolvimento de Quake.
Nos pubnixes modernos, o Finger ainda funciona e é parte da cultura social do ambiente.
4. Protocolos de Comunicação e Mensagens
4.1 IRC — O Chat em Texto Puro
RFC: 1459 (maio de 1993), atualizado pelos RFCs 2810-2813, 7194 | Portas: 6667 (plaintext), 6697 (TLS)
O Internet Relay Chat foi criado em 1988 por Jarkko Oikarinen na Universidade de Oulu, Finlândia, originalmente como substituto de um protocolo de chat multiusuário em um BBS local. Em maio de 1993, o RFC 1459 formalizou o protocolo como padrão experimental da internet.
A arquitetura do IRC é cliente-servidor federada: múltiplos servidores se interconectam para formar uma rede, como Libera.Chat, IRCnet, EFnet e tilde.chat. Um cliente conecta a um servidor da rede e pode se comunicar com usuários em qualquer outro servidor da mesma rede.
# Exemplo de comandos IRC em texto puro
NICK seunome
USER seunome 0 * :Nome Completo
JOIN #canal
PRIVMSG #canal :Olá a todos!
PRIVMSG outro_usuario :Mensagem privada
PART #canal :Saindo
QUIT :Até logoOs bots IRC são um aspecto técnico notável: qualquer programa que consiga abrir uma socket TCP e enviar e receber texto ASCII pode ser um bot. Isso criou um ecossistema rico de bots para moderação, jogos, RSS, notificações de CI/CD e integração com Git.
Redes IRC relevantes hoje:
- Libera.Chat — herdeira do Freenode, foco em software livre
- IRCnet — uma das redes originais
- tilde.chat — rede dedicada ao tildeverse
- EFnet — uma das mais antigas ainda ativas
- Rizon — popular em comunidades de anime
Clientes populares: WeeChat, irssi, HexChat, Kiwi IRC e TheLounge.
Uma limitação importante: o IRC tradicional não tem persistência de mensagens. A solução comum são os bouncers IRC, como ZNC ou Soju.
4.2 NNTP e a Usenet — Fóruns Distribuídos Desde 1979
RFC: 977 (fevereiro de 1986), atualizado pelo RFC 3977 (outubro de 2006) | Portas: 119 (plaintext), 563 (NNTPS)
A Usenet foi criada em 1979 por Tom Truscott e Jim Ellis, estudantes da Universidade Duke, inspirados pela ARPANET. O primeiro software, netnews, funcionava sobre UUCP, transferência de arquivos por linha telefônica discada. O NNTP surgiu em 1986 para adaptar a Usenet ao TCP/IP.
Tecnicamente, a Usenet é um sistema de propagação de artigos: quando alguém posta uma mensagem em um servidor, ela é automaticamente propagada para outros servidores que carregam aquele newsgroup. Os artigos têm formato baseado no RFC 2822, com headers como From:, Subject:, Newsgroups:, Message-ID: e References:.
# Exemplo de cabeçalho de artigo Usenet
Path: server1!server2!poster
From: usuario@example.com
Newsgroups: comp.lang.python, comp.programming
Subject: Re: List comprehensions vs generator expressions
Message-ID: <unique-id@example.com>
References: <original-message-id@example.com>
Date: Wed, 08 Apr 2026 20:00:00 -0300A Usenet se organiza em hierarquias. As Big 8 incluem comp.*, sci.*, rec.*, soc.*, talk.*, news.*, misc.* e humanities.*. A hierarquia alt.*, criada em 1987, surgiu como resposta à rigidez das hierarquias moderadas e se tornou a mais populosa da Usenet.
No pico da Usenet, entre os anos 1990 e o início dos 2000, havia dezenas de milhares de grupos ativos. Hoje ela segue viva em nichos técnicos e em provedores focados em alt.binaries.*.
Clientes comuns: Thunderbird, tin, slrn e Pan.
4.3 SMTP — O Email Ainda é Descentralizado
RFC: 821 (agosto de 1982), atualizado até o RFC 5321 (2008) | Porta: 25 (server-to-server), 587 (submission), 465 (TLS)
O email é talvez o mais bem-sucedido protocolo descentralizado em uso massivo. O SMTP define como servidores de email se comunicam entre si para entregar mensagens.
# Diálogo SMTP simplificado
S: 220 mail.exemplo.com ESMTP
C: EHLO meuservidor.com
S: 250-mail.exemplo.com
C: MAIL FROM:<remetente@meuservidor.com>
S: 250 OK
C: RCPT TO:<destinatario@exemplo.com>
S: 250 OK
C: DATA
S: 354 Start mail input
C: Subject: Teste
C: De: remetente@meuservidor.com
C:
C: Corpo da mensagem aqui.
C: .
S: 250 OKA descentralização do email é real, mas difícil para usuários comuns hoje: entregabilidade para Gmail, Outlook e Yahoo exige reputação, SPF, DKIM, DMARC e outros mecanismos que tornam o cenário mais duro do que parece.
Para quem quer email autogerido, a combinação clássica costuma ser Postfix + Dovecot + Rspamd. Alguns pubnixes, como SDF, thunix e tilde.team, também oferecem contas de email como parte do serviço.
4.4 Matrix — Federação com Criptografia Moderna
Especificação: matrix.org | Porta: 8448 (federation), 443 (clients via HTTPS) | Lançamento: 2014
O Matrix é um protocolo aberto para comunicação descentralizada em tempo real, mantido pela Matrix.org Foundation. Funciona como uma rede federada onde qualquer um pode hospedar um homeserver, e servidores se comunicam entre si para sincronizar conversas em rooms.
A arquitetura central do Matrix é o DAG de eventos: cada mensagem, reação, edição ou outro evento em uma sala é representado como um nó num grafo acíclico dirigido, referenciando eventos anteriores por hash criptográfico. Isso ajuda na resolução de conflitos quando partições de rede se sincronizam.
{
"type": "m.room.message",
"sender": "@usuario:homeserver.com",
"room_id": "!sala:homeserver.com",
"origin_server_ts": 1712603400000,
"content": {
"msgtype": "m.text",
"body": "Olá!"
},
"event_id": "$hash_do_evento"
}A criptografia end-to-end do Matrix usa Olm para mensagens 1-para-1 e Megolm para salas. O cliente de referência é o Element, mas também há Cinny, FluffyChat, Nheko e SchildiChat.
5. Sistemas de Comunidades e Redes Históricas
5.1 BBS — Bulletin Board Systems
Primeiro sistema: 1978 (Chicago, Ward Christensen e Randy Suess) | Acesso: Telnet ou SSH
Um Bulletin Board System é um sistema que aceita conexões de usuários remotos e oferece fóruns, arquivos para download, jogos e email entre usuários do mesmo sistema.
O primeiro BBS surgiu em 16 de fevereiro de 1978 em Chicago. O software CBBS rodava em um computador S-100 bus com modem de 300bps. A tecnologia central era simples: um servidor de terminal que aceitava conexões, autenticava usuários e exibia menus de texto.
O software de BBS mais popular historicamente incluiu TBBS, WWIV, PCBoard e Synchronet, que ainda está em desenvolvimento ativo.
Para acessar BBSs modernos:
# Via Telnet
telnet nsbbs.ddns.net
# Via SSH
ssh usuario@bbs.exemplo.com
# Com SyncTERM
syncterm bbs.gcomm.comA ANSI art é um aspecto cultural marcante dos BBSs: sequências ANSI criavam gráficos coloridos em terminais de texto, principalmente em loginscreens e menus.
5.2 FidoNet — A Internet Antes da Internet
Fundado: 1984 (Tom Jennings) | Protocolo: FTS | Endereçamento: zone:net/node[.point]
O FidoNet foi criado em 1984 por Tom Jennings como uma rede de troca de mensagens entre BBSs. O modelo é store-and-forward: cada nó acumula mensagens e as transmite para o próximo em horários agendados, normalmente durante a madrugada, quando as tarifas telefônicas eram menores.
O sistema de endereçamento é hierárquico: zona:rede/nó.ponto. O nodelist, distribuído semanalmente, listava todos os nós ativos na rede. Em 1993 ele continha mais de 20.000 sistemas.
Tecnicamente, o FidoNet usa protocolos de transferência eficientes, normalmente baseados em Zmodem, para minimizar o tempo de linha. Os Echos, equivalentes a newsgroups, permitem que mensagens de fóruns se propaguem por toda a rede durante os ciclos de polling.
Hoje o FidoNet ainda existe, com alguns nós acessíveis via internet usando BINKD ou através de BBSs com suporte FidoNet.
6. Redes Descentralizadas e o Fediverso
6.1 ActivityPub — O Protocolo do Fediverso
Especificação: W3C Recommendation (janeiro de 2018) | Base: JSON-LD, ActivityStreams 2.0 | Transporte: HTTPS
O ActivityPub é um protocolo W3C construído sobre ActivityStreams 2.0 e JSON-LD. Ele define dois mecanismos:
- Server-to-server federation
- Client-to-server protocol
A unidade fundamental é o Actor, com dois endpoints cruciais: inbox e outbox. Quando você faz um post no Mastodon, por exemplo, seu servidor envia um Create(Note) para o inbox de todos os seguidores em outros servidores.
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Create",
"actor": "https://mastodon.social/users/fulano",
"object": {
"type": "Note",
"content": "Olá, Fediverso!",
"published": "2026-04-08T20:00:00Z",
"to": ["https://www.w3.org/ns/activitystreams#Public"]
}
}O Fediverso é a rede resultante de todos os servidores que implementam ActivityPub. Plataformas centrais incluem Mastodon, PeerTube, Pixelfed, Lemmy, Funkwhale e outras.
6.2 WebFinger — O Diretório Telefônico do Fediverso
RFC: 7033 (setembro de 2013) | Transporte: HTTPS well-known URI
O WebFinger é um protocolo de descoberta de informações sobre entidades na internet. É o mecanismo que permite que, dado um endereço no formato usuario@servidor.com, qualquer cliente do Fediverso consiga descobrir onde estão o perfil ActivityPub, a chave pública, os endpoints de comunicação e outros metadados do usuário.
Tecnicamente, o WebFinger faz uma requisição GET para /.well-known/webfinger com o parâmetro resource=acct:usuario@servidor.com. A resposta é um documento JSON no formato JRD.
# Consultar WebFinger de um usuário do Mastodon
curl "https://mastodon.social/.well-known/webfinger?resource=acct:Mastodon@mastodon.social"
# Resposta (simplificada)
{
"subject": "acct:Mastodon@mastodon.social",
"aliases": ["https://mastodon.social/@Mastodon"],
"links": [
{
"rel": "http://webfinger.net/rel/profile-page",
"href": "https://mastodon.social/@Mastodon"
},
{
"rel": "self",
"type": "application/activity+json",
"href": "https://mastodon.social/users/Mastodon"
}
]
}O nome “WebFinger” é uma referência ao protocolo Finger de 1971, mas a tecnologia é completamente diferente.
6.3 Nostr — Identidade por Criptografia
Criado: 2020 (por “fiatjaf”, desenvolvedor brasileiro) | Especificação: NIPs | Transporte: WebSocket
O Nostr foi escrito em 2020 por um desenvolvedor de software livre brasileiro pseudônimo chamado “fiatjaf” como resposta a problemas de moderação no Twitter e discordâncias técnicas com ActivityPub e SSB. É um protocolo de transmissão de mensagens descentralizado com resistência à censura como objetivo primário.
A arquitetura do Nostr tem apenas dois componentes:
- Clients
- Relays
A identidade no Nostr é baseada em criptografia de curva elíptica secp256k1. Cada usuário tem um par de chaves:
- Chave privada (
nsec) — usada para assinar eventos - Chave pública (
npub) — identidade do usuário
{
"id": "hash_sha256_do_conteudo",
"pubkey": "chave_publica_hex",
"created_at": 1712603400,
"kind": 1,
"tags": [["e", "id_do_evento_referenciado"], ["p", "pubkey_mencionada"]],
"content": "Olá, Nostr!",
"sig": "assinatura_schnorr_hex"
}O campo kind define o tipo de conteúdo, como perfil, nota curta, lista de contatos, mensagem direta, reação ou artigo longo. Uma integração notável é com o Lightning Network: a NIP-57 define o protocolo “Zaps” para micropagamentos em Bitcoin diretamente entre usuários do Nostr.
A chave privada no Nostr é absoluta: quem a possui controla a identidade. Não existe recuperação de conta.
6.4 Scuttlebutt (SSB) — Redes Offline-First
Protocolo: Secure Scuttlebutt (SSB) | Criado: ~2014 (Dominic Tarr) | Transporte: TCP, UDP e Bluetooth
O Secure Scuttlebutt é um protocolo social descentralizado com uma propriedade técnica incomum: funciona offline-first. Não depende de servidores centrais nem assume conectividade constante.
O modelo de dados central é o append-only log: cada identidade tem um feed, uma cadeia imutável de mensagens ordenadas, em que cada mensagem referencia o hash da anterior.
{
"key": "%hash_da_mensagem",
"value": {
"previous": "%hash_da_mensagem_anterior",
"author": "@chave_publica_do_autor=.ed25519",
"sequence": 42,
"timestamp": 1712603400000,
"hash": "sha256",
"content": {
"type": "post",
"text": "Olá, Scuttlebutt!"
},
"signature": "assinatura_ed25519"
}
}A replicação acontece via gossip protocol: quando dois nós se conectam, seja pela internet, rede local ou Bluetooth, eles trocam os feeds que seguem. A descoberta local usa mDNS. O alcance de replicação costuma ser configurado por hops.
Clientes comuns incluem Patchwork, Manyverse, Oasis e Netsim.
7. Protocolos de Distribuição de Arquivos
7.1 BitTorrent e DHT — Compartilhamento Peer-to-Peer
Especificação: BEP | DHT: BEP-5 (Kademlia) | Porta: 6881-6889 (TCP/UDP)
O BitTorrent é um protocolo de transferência de arquivos peer-to-peer criado por Bram Cohen em 2001. Em vez de um único servidor servir o arquivo inteiro para todos, cada cliente que baixa também passa a servir as partes que já possui.
Um arquivo .torrent contém metadados como hash SHA-1 do conteúdo, lista de peças e endereço de trackers. O DHT, baseado em Kademlia, elimina a dependência de trackers centrais.
# Operação DHT simplificada
1. Cliente calcula infohash do torrent
2. Consulta DHT: "quem tem peers para infohash X?"
3. DHT roteia a consulta até nós próximos de X
4. Nós retornam lista de IPs de peers
5. Cliente conecta aos peers e inicia downloadO DHT do BitTorrent segue como um dos maiores sistemas P2P em operação contínua.
7.2 IPFS — Sistema de Arquivos Interplanetário
Criado: 2015 (Protocol Labs, Juan Benet) | Transporte: libp2p | Esquema: ipfs://
O InterPlanetary File System é um protocolo e rede peer-to-peer para armazenamento e acesso a conteúdo descentralizado. A inovação central é o endereçamento por conteúdo, não por localização.
No IPFS, você acessa conteúdo por o que ele é: cada arquivo recebe um CID calculado como hash do conteúdo. Qualquer diferença no arquivo gera um CID diferente.
# Adicionar um arquivo ao IPFS local
ipfs add arquivo.txt
# → added QmHash... arquivo.txt
# Recuperar o arquivo pelo hash
ipfs cat QmHash...
# Acessar via gateway HTTP público
curl https://ipfs.io/ipfs/QmHash...Quando você pina um arquivo, assume o compromisso de servi-lo para outros. Sem pins suficientes, o conteúdo pode desaparecer. O IPFS usa libp2p como camada de rede, incluindo descoberta de peers, transporte e segurança.
8. Redes Anônimas e Privadas
8.1 Tor — Onion Routing e Serviços .onion
Desenvolvido por: DARPA / Naval Research Laboratory / Tor Project | Lançado: 2002 | Porta: 9050 (SOCKS), 9150 (Tor Browser)
O Tor implementa onion routing, técnica em que o tráfego é encapsulado em múltiplas camadas de criptografia e roteado por uma cadeia de nós voluntários. Nenhum nó individual conhece, ao mesmo tempo, origem e destino da comunicação.
Um circuito Tor padrão tem três nós:
- Guard
- Middle
- Exit
Client → [IP_cliente encriptado] → Guard
Guard → [middle conhece só Guard e Exit] → Middle
Middle → [exit conhece só Middle] → Exit
Exit → [destino vê IP do Exit] → DestinationOs Onion Services permitem que servidores operem dentro da rede Tor sem revelar seu IP. Um endereço .onion é derivado criptograficamente da chave pública Ed25519 do serviço.
# Usar Tor como proxy SOCKS5
curl --socks5-hostname localhost:9050 https://check.torproject.org
# Acessar um onion service
curl --socks5-hostname localhost:9050 http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/8.2 I2P — A Rede Invisível
Iniciado: 2002 | Transporte: UDP + TCP (garlic routing) | Nós: ~55.000
O Invisible Internet Project é uma camada de rede anônima sobreposta que difere do Tor em arquitetura. Enquanto o Tor é otimizado para acesso anônimo ao clearnet, o I2P é construído para comunicação dentro da própria rede I2P.
A técnica de anonimização do I2P é o garlic routing: múltiplas mensagens cifradas são empacotadas juntas para dificultar análise de tráfego. Os túneis são unidirecionais, o que reduz ataques de correlação de timing.
# Estrutura de roteamento I2P
Sender → [inbound tunnel] → Relay nodes → [outbound tunnel] → Destination
(unidirectional, separate paths)Os endpoints no I2P são identificadores criptográficos, não endereços IP. Isso significa que a localização de um serviço é abstrata.
9. Micro-protocolos e Formatos Alternativos
9.1 twtxt — Microblog em Arquivo de Texto
Criado: 2016 (buckket) | Formato: TSV | Transporte: HTTP
O twtxt é o extremo minimalista do microblogging: o perfil é um arquivo de texto plano hospedado em qualquer servidor HTTP. Cada linha é um post, formatado como timestamp ISO 8601, tabulação e conteúdo.
# Exemplo de arquivo twtxt.txt
2026-04-08T20:00:00+00:00 Meu primeiro post no twtxt!
2026-04-07T18:30:00+00:00 @<outro https://outro.site/twtxt.txt> olá!
2026-04-06T10:00:00+00:00 Lendo sobre Gemini. Interessante demais.Não há servidor central, API ou autenticação. A URL do twtxt.txt é a identidade. Clientes como o CLI oficial, txtnish e Yarns baixam os arquivos seguidos e montam a timeline localmente.
# Instalar o cliente oficial
pip install twtxt
# Configurar
twtxt quickstart
# Postar
twtxt tweet "Olá, twtxt!"
# Ver timeline
twtxt timeline
# Seguir alguém
twtxt follow usuario https://usuario.example.com/twtxt.txtA descoberta é o problema central do twtxt: sem servidor central de busca, encontrar outras pessoas depende de recomendações manuais ou webrings.
9.2 RSS/Atom — Feeds Que Ainda São Livres
RSS 2.0: 2002 (Dave Winer) | Atom: RFC 4287 (2005) | Transporte: HTTP
O RSS e o Atom são formatos XML para distribuição de atualizações de conteúdo. Qualquer site pode publicar um feed que qualquer leitor pode assinar, sem conta, sem algoritmo e sem plataforma intermediária.
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
<title>Meu Blog</title>
<link>https://meublog.example.com</link>
<item>
<title>Novo artigo</title>
<link>https://meublog.example.com/artigo</link>
<pubDate>Wed, 08 Apr 2026 20:00:00 -0300</pubDate>
<description>Resumo do artigo aqui.</description>
</item>
</channel>
</rss>O RSS foi declarado morto várias vezes, mas persiste como um dos protocolos mais robustos e duráveis da internet. Leitores modernos incluem NetNewsWire, FeedBin, Miniflux e Newsboat.
10. Tabela Comparativa Geral
| Protocolo | Ano | Camada | TLS | P2P | Offline | RFC/Spec | Clientes populares |
|---|---|---|---|---|---|---|---|
| Gopher | 1991 | Navegação | ✗ | ✗ | ✗ | RFC 1436 | Lagrange, Lynx, Bombadillo |
| Gemini | 2019 | Navegação | ✓ (obr.) | ✗ | ✗ | geminiprotocol.net | Lagrange, Amfora, Elpher |
| Finger | 1971 | Presença | ✗ | ✗ | ✗ | RFC 742, 1288 | finger (CLI) |
| IRC | 1988 | Chat RT | opt. | ✗ | ✗ | RFC 1459 | WeeChat, irssi, HexChat |
| NNTP/Usenet | 1979/1986 | Fórum | opt. | ✗ | ✗ | RFC 977, 3977 | Thunderbird, tin, slrn |
| SMTP | 1982 | opt. | ✗ | ✗ | RFC 821, 5321 | Mutt, Alpine, Postfix | |
| Matrix | 2014 | Chat/Fed. | ✓ | ✗ | part. | matrix.org | Element, Cinny, Nheko |
| ActivityPub | 2018 | Social/Fed. | ✓ | ✗ | ✗ | W3C Rec. | Mastodon, PeerTube, Lemmy |
| WebFinger | 2013 | Descoberta | ✓ | ✗ | ✗ | RFC 7033 | — (usado por clientes) |
| Nostr | 2020 | Social | ✓ | ✗ | ✗ | NIPs (GitHub) | Damus, Amethyst, Snort |
| SSB | 2014 | Social | ✓ | ✓ | ✓ | ssbc.github.io | Patchwork, Manyverse |
| BBS | 1978 | Comunidade | opt. | ✗ | ✗ | — | SyncTERM, NetRunner |
| FidoNet | 1984 | Mensagens | ✗ | ✗ | ✓ | FTS (fidonet.org) | Synchronet, Mystic |
| BitTorrent | 2001 | Arquivos | ✗ | ✓ | ✗ | BEPs | qBittorrent, Transmission |
| IPFS | 2015 | Arquivos | ✓ | ✓ | part. | Protocol Labs | IPFS Desktop, Brave |
| Tor | 2002 | Anonimato | ✓ (interno) | ✓ | ✗ | torproject.org | Tor Browser |
| I2P | 2002 | Anonimato | ✓ (interno) | ✓ | ✗ | geti2p.net | I2P Java Router |
| twtxt | 2016 | Microblog | opt. | ✗ | ✗ | twtxt.readthedocs.io | twtxt CLI, Yarns |
| RSS/Atom | 2002/2005 | Feeds | opt. | ✗ | ✗ | RFC 4287 | Newsboat, NetNewsWire |
11. Como as Camadas Se Relacionam
Uma visão útil para entender o ecossistema é perceber que muitos desses protocolos coexistem e se complementam em vez de competir:
Identidade e descoberta:
WebFinger resolve @usuario@servidor para URIs usáveis por ActivityPub, Matrix e outros.
Conteúdo e navegação:
HTTP coexiste com Gopher, Gemini e IPFS.
Comunicação em tempo real:
IRC versus Matrix.
Redes sociais:
ActivityPub versus Nostr versus SSB.
Anonimato:
Tor versus I2P.
Distribuição de arquivos:
BitTorrent+DHT versus IPFS.
A combinação prática mais comum num pubnix como o envs.net, por exemplo, é: acesso via SSH, conteúdo web via HTTP/HTTPS, cápsula via Gemini, gopherhole via Gopher, microblog via twtxt, chat via IRC e feed social via ActivityPub.
12. O Que Tudo Isso Tem em Comum
Esses protocolos e sistemas expõem alternativas reais ao modelo dominante da internet atual. Cada um representa uma escolha técnica e cultural diferente:
- Gopher e Gemini apostam na leveza e na simplicidade radical
- IRC e SMTP provam que protocolos abertos e antigos ainda sobrevivem décadas depois
- NNTP e FidoNet demonstram que comunicação distribuída e assíncrona funcionou antes da internet ubíqua
- ActivityPub e Matrix mostram que federação é possível com infraestrutura moderna
- Nostr e SSB radicalizam a descentralização
- IPFS e BitTorrent distribuem os dados em vez de centralizar em servidores
- Tor e I2P tratam privacidade e anonimato como propriedades de infraestrutura
O ponto central é este: esses sistemas não são necessariamente melhores em conforto, escalabilidade ou conveniência. Em muitos aspectos concretos, são mais limitados. Mas revelam que as escolhas técnicas que definem a internet comercial não são inevitáveis.
Continuidade
Esta nota amplia o mapa técnico de coisas que tangenciam diretamente Pubnixes e Tildes, especialmente quando entram em cena Gopher, Gemini, IRC, Finger e a cultura de sistemas mais leves. Quando o interesse sair do panorama e entrar em recursos práticos, o caminho natural costuma seguir para Tools.
Artigo atualizado em abril de 2026. As especificações técnicas refletem os RFCs e documentos citados. Protocolos em desenvolvimento ativo podem evoluir rapidamente.