Da camada física às redes sociais descentralizadas — uma visão completa do ecossistema além da web comercial.
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/HTML nunca resolveu bem: privacidade, censura, dependência de servidores centrais, rastreamento, 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.
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 (Fediverso), 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.
RFC: 1436 (março de 1993) | Porta: 70 (TCP) | Esquema de URL: gopher://
O Gopher foi criado em 1991 pela Universidade de Minnesota — daí o nome, mascote do estado. 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, 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 70
O Gopher foi amplamente usado antes de 1993-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 18 meses.
Hoje, o protocolo ainda tem adeptos na comunidade de pubnixes e tildes, que mantêm "gopherholes" ativos. Clientes modernos incluem Lagrange (GUI multiplataforma), Bombadillo (TUI, Go), Lynx (TUI histórico) e a extensão OverbiteNX para Firefox via proxy.
Limitações honestas: Sem TLS nativo (existe um projeto chamado GopherS que adiciona TLS opcionalmente, mas não há padrão universal). Sem formatação rica, sem imagens inline, sem JavaScript. O próprio RFC 1436 não define autenticação.
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, março de 1965) com TLS obrigatório — TLS 1.2 ou superior, aceita certificados autoassinados.
O ciclo de vida de uma requisição Gemini é intencionalmente simples:
\r\n# 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...\n
O gemtext (MIME type text/gemini, extensões .gmi ou .gmni) é o formato nativo. A especificação define apenas seis tipos de linha: texto normal, link (=>), cabeçalho (#, ##, ###), lista (*), citação (>) e bloco pré-formatado (delimitado por ```).
# 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 de requisição opcionais como no HTTP, não há cookies, não há JavaScript, não há redirecionamentos arbitrários por meta-tag, não há formas de injetar tracking pixels. Essa inflexibilidade é uma feature, não um bug.
Projetos que servem Gemini: **Agate** (Rust), **Molly Brown** (Go), **Jetforce** (Python). Clientes: **Lagrange** (GUI C), **Amfora** (TUI Go), **Elpher** (Emacs Lisp), **Kristall** (C++ Qt).
---
### 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 para verificar disponibilidade 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 (vazia para listar todos os usuários, ou `usuario\r\n` para um específico) e aguarda a resposta do daemon `fingerd`. O servidor retorna informações sobre o usuário — nome real, localização, tempo de login, e o conteúdo dos arquivos `~/.plan` e `~/.project` se existirem.
```bash
# 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
finger
O ~/.plan se tornou o equivalente pré-web de uma bio ou feed de status. Nos anos 1990, o jogador de id Software John Carmack ficou famoso por manter um .plan detalhado com atualizações técnicas sobre o desenvolvimento de Quake — um caso notável de uso do Finger como proto-blog técnico.
Nos pubnixes modernos, o Finger ainda funciona e é parte da cultura social do ambiente: finger usuario@tilde.town retorna informações sobre o usuário, incluindo o .plan que ele mantém.
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 multi-usuá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, tilde.chat). Um cliente conecta a um servidor da rede e pode se comunicar com usuários em qualquer outro servidor da mesma rede. O protocolo é baseado em texto puro: cada mensagem é uma linha ASCII terminada com \r\n, composta por prefixo (opcional), comando e parâmetros.
# 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é logo
Os bots IRC são um aspecto técnico notável: qualquer programa que consiga abrir uma socket TCP e enviar/receber texto ASCII pode ser um bot. Isso criou um ecossistema rico de bots para moderação, jogos, RSS, notificações de CI/CD, integração com Git, etc.
Redes IRC relevantes hoje:
Clientes: WeeChat (TUI, extensível em Python/Perl/Ruby), irssi (TUI), HexChat (GUI), Kiwi IRC (web), TheLounge (self-hosted web bouncer).
Uma limitação importante: o IRC tradicional não tem persistência de mensagens — se você não estiver conectado, não recebe as mensagens enviadas durante sua ausência. A solução comum são os bouncers IRC (como ZNC ou Soju), que ficam conectados 24/7 e retransmitem mensagens quando você reconecta.
[image:225]
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 de pós-graduação da Universidade Duke, inspirados pela ARPANET. O primeiro software, netnews, funcionava sobre UUCP (Unix-to-Unix Copy) — transferência de arquivos por linha telefônica discada, agendada para horários de baixo custo. O NNTP (Network News Transfer Protocol) 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 num servidor, ela é automaticamente propagada para todos os outros servidores que carregam aquele newsgroup. Os artigos têm formato baseado no RFC 2822 (email), com headers como From:, Subject:, Newsgroups:, Message-ID: e References: (para threading de discussão).
# 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 -0300
A Usenet se organiza em hierarquias (prefixos de nome). As "Big 8" hierarquias moderades incluem comp.* (computação), sci.* (ciência), rec.* (lazer), soc.* (sociedade), talk.* (debate), news.* (sobre a Usenet em si), misc.* e humanities.*. A hierarquia alt.* foi criada em 1987 por Brian Reid, Gordon Moffett e John Gilmore como resposta à rigidez das hierarquias moderadas — em alt.* qualquer um pode criar um grupo sem aprovação formal. O alt.* se tornou a hierarquia mais populosa da Usenet.
No pico da Usenet (anos 1990 a início dos 2000), havia dezenas de milhares de grupos ativos. Hoje, a Usenet técnica ainda existe, mantida por provedores como Giganews, Eweka e UsenetServer, com foco principalmente em alt.binaries.* para distribuição de arquivos.
Clientes: Thunderbird (GUI, também lê email), tin (TUI), slrn (TUI), Pan (GUI Linux).
[image:222]
RFC: 821 (agosto de 1982), atualizado sucessivamente 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 (Simple Mail Transfer Protocol), especificado originalmente por Jon Postel no RFC 821, define como servidores de email se comunicam entre si para entregar mensagens. A troca fundamental é direta:
# 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 OK
A descentralização do email é real mas impraticável para usuários comuns hoje: qualquer um pode rodar um servidor SMTP, mas entregabilidade para Gmail/Outlook/Yahoo requer passar por filtros de reputação complexos (SPF, DKIM, DMARC, listas negras), o que na prática cria uma oligarquia de provedores de email confiáveis.
Para quem quer email realmente autogerido, servidores como Postfix + Dovecot + Rspamd são a combinação típica. Alguns pubnixes (SDF, thunix, tilde.team) oferecem contas de email como parte do serviço, com clientes como Mutt, Alpine ou Aerc acessíveis diretamente no terminal.
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 (organização sem fins lucrativos britânica). Funciona como uma rede federada onde qualquer um pode hospedar um servidor (homeserver), e servidores se comunicam entre si para sincronizar conversas (rooms).
A arquitetura central do Matrix é o DAG (Directed Acyclic Graph) 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 permite resolução de conflitos quando partições de rede sincronizam.
# Estrutura de um evento Matrix (simplificado)
{
"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 o Olm (baseado no protocolo Signal de duplo ratchet) para mensagens 1-para-1, e o Megolm (ratchet de grupo) para salas. O cliente de referência é o Element (web, desktop, mobile), mas há dezenas de outros: Cinny, FluffyChat, Nheko, SchildiChat.
O Matrix é usado por organizações que precisam de comunicação soberana: o exército francês, o governo alemão (para comunicação em escolas), a Mozilla Foundation e centenas de empresas usam instâncias próprias de homeserver.
Primeiro sistema: 1978 (Chicago, Ward Christensen e Randy Suess) | Acesso: Telnet (porta 23) ou SSH
Um Bulletin Board System é um sistema de computador que aceita conexões de usuários remotos (originalmente via modem e linha telefônica, hoje via Telnet ou SSH) e oferece funcionalidades como fóruns de mensagens, arquivos para download, jogos e email entre usuários do mesmo sistema.
O primeiro BBS surgiu em 16 de fevereiro de 1978 em Chicago, criado por Ward Christensen e Randy Suess para substituir um quadro de avisos físico de um clube de computadores durante uma nevasca. O software CBBS (Computerized Bulletin Board System) rodava num S-100 bus computer com um modem de 300bps.
A tecnologia central de um BBS é simples: um servidor de terminal que aceita conexões, autentica usuários e exibe menus de texto. O software de BBS mais popular historicamente incluía TBBS, WWIV, PCBoard e Synchronet (que ainda está em desenvolvimento ativo). O Synchronet BBS Software hoje suporta Telnet, SSH, FTP e até uma interface web.
Para acessar BBSs modernos:
# Via Telnet (muitos BBSs clássicos ainda usam Telnet)
telnet nsbbs.ddns.net
# Via SSH (mais seguro, preferido em sistemas modernos)
ssh usuario@bbs.exemplo.com
# Com SyncTERM (cliente com suporte a ANSI art)
syncterm bbs.gcomm.com
A ANSI art é um aspecto cultural icônico dos BBSs: sequências de escape ANSI usadas para criar gráficos coloridos em terminais de texto, exibidos na tela de boas-vindas (loginscreen) ou decorando menus.
Fundado: 1984 (Tom Jennings) | Protocolo: FTS (FidoNet Technical Standards) | 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 nó em horários agendados (geralmente durante a madrugada, quando as tarifas telefônicas eram menores).
O sistema de endereçamento é hierárquico: zona:rede/nó.ponto. As zonas correspondem às grandes regiões geográficas do mundo (Zona 1 = Américas, Zona 2 = Europa, etc.). O nodelist — lista de todos os nós ativos na rede — era distribuído semanalmente e em 1993 continha mais de 20.000 sistemas. Hoje, o histórico de nodelists desde outubro de 1986 está preservado em nodehist.fidonet.org.ua.
Tecnicamente, o FidoNet usa protocolos de transferência eficientes baseados em Zmodem (streaming, sem confirmações por pacote) para minimizar o tempo de linha telefônica. Os "Echos" (equivalente a newsgroups) permitem que mensagens de fóruns se propaguem pela rede inteira durante os ciclos de polling.
Hoje o FidoNet ainda existe, com alguns nós acessíveis via internet usando BINKD (um mailer FidoNet sobre TCP/IP) ou através de BBSs com suporte FidoNet.
Especificação: W3C Recommendation (janeiro de 2018) | Base: JSON-LD, ActivityStreams 2.0 | Transport: HTTPS
O ActivityPub é um protocolo W3C publicado como Recomendação em janeiro de 2018, construído sobre dois padrões: ActivityStreams 2.0 (vocabulário de atividades e objetos) e JSON-LD (linked data em JSON). Ele define dois mecanismos:
A unidade fundamental é o Actor (usuário, grupo, serviço) com dois endpoints cruciais: inbox (onde o actor recebe atividades) e outbox (onde o actor publica). Quando você faz um post no Mastodon, seu servidor envia um Create(Note) para o inbox de todos os seus seguidores em outros servidores.
// Exemplo simplificado de atividade ActivityPub
{
"@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. As principais plataformas incluem Mastodon (microblogging), PeerTube (vídeo), Pixelfed (fotos), Lemmy (fóruns, estilo Reddit), Funkwhale (música), Misskey/Calckey/Firefish (microblogging japonês), e mais recentemente Threads da Meta (que anunciou suporte parcial ao ActivityPub).
O ActivityPub tem mais de 20 milhões de usuários distribuídos em dezenas de milhares de instâncias.
[image:220]
RFC: 7033 (setembro de 2013) | Transport: HTTPS well-known URI
O WebFinger é um protocolo de descoberta de informações sobre entidades na internet, especificado no RFC 7033. É 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 HTTP GET para /.well-known/webfinger do servidor com o parâmetro resource=acct:usuario@servidor.com. A resposta é um documento JSON no formato JRD (JSON Resource Descriptor).
# 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 direta ao protocolo Finger de 1971, mas é uma tecnologia completamente diferente — baseada em HTTP, JSON e URIs.
Criado: 2020 (por "fiatjaf", desenvolvedor brasileiro) | Especificação: NIPs (Nostr Implementation Possibilities) | Transporte: WebSocket
O Nostr (acrônimo de Notes and Other Stuff Transmitted by Relays) 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:
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 todos os eventos
- Chave pública (npub) — é a identidade do usuário; não existe "conta" no sentido tradicional
// Estrutura de um evento Nostr
{
"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 (tipo de evento) define o tipo de conteúdo: 0 (metadados do perfil), 1 (nota curta, como tweet), 3 (lista de contatos), 4 (mensagem direta encriptada), 5 (deleção), 7 (reação), 30023 (artigo longo), etc. As extensões ao protocolo são chamadas NIPs (Nostr Implementation Possibilities).
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, sem intermediários.
A chave privada no Nostr é absoluta: quem a tem controla a identidade. Não existe recuperação de conta. Isso é radicalmente diferente das redes centralizadas — e coloca toda a responsabilidade de segurança no usuário.
[image:227]
Protocolo: Secure Scuttlebutt (SSB) | Criado: ~2014 (Dominic Tarr) | Transporte: TCP, UDP (mDNS local), Bluetooth
O Secure Scuttlebutt é um protocolo social descentralizado com uma propriedade técnica incomum: funciona offline-first. Projetado por Dominic Tarr, o SSB não depende de servidores centrais nem assume conectividade constante.
O modelo de dados central é o append-only log: cada identidade no SSB tem um feed — uma cadeia imutável de mensagens ordenadas, onde cada mensagem referencia o hash da anterior (similar a uma blockchain, mas sem necessidade de consenso global). Uma vez que uma mensagem é publicada, não pode ser modificada ou deletada.
// Estrutura de uma mensagem SSB
{
"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 via internet, rede local ou Bluetooth), eles trocam os feeds que cada um segue. A descoberta local usa mDNS — dispositivos na mesma rede WiFi encontram uns aos outros automaticamente sem nenhum servidor de sinalização.
O alcance de replicação é configurável por "hops": com 1 hop, você replica apenas feeds de pessoas que você segue diretamente; com 2 hops (o padrão), também replica feeds de pessoas que seus seguidos seguem.
Clientes: Patchwork (desktop Electron), Manyverse (mobile, Electron + React Native), Oasis (web local), Netsim (simulador de rede para desenvolvimento).
[image:226]
Especificação: BEP (BitTorrent Enhancement Proposals) | 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. O princípio central é: em vez de um único servidor servir o arquivo inteiro para todos os clientes, cada cliente que baixa também começa a servir as partes que já tem, distribuindo a carga.
Um arquivo .torrent contém metadados: hash SHA-1 do conteúdo, lista de "peças" (chunks de tamanho fixo, tipicamente 256KB-1MB) e endereço de rastreadores (trackers). O cliente usa esses metadados para encontrar outros peers que têm o arquivo e baixar peças de múltiplas fontes simultaneamente.
O DHT (Distributed Hash Table) — especificado na BEP-5 e baseado no algoritmo Kademlia — elimina a dependência de trackers centrais. Cada nó tem um ID aleatório de 160 bits; a tabela hash distribui a responsabilidade de armazenar informações de peers baseada na distância XOR entre IDs. Para encontrar peers de um torrent, o cliente consulta nós cujo ID é "próximo" do infohash do torrent.
# Operação DHT simplificada
1. Cliente calcula infohash do torrent (SHA-1 dos metadados)
2. Consulta DHT: "quem tem peers para infohash X?"
3. DHT roteie 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 download
Em 2013, medições indicavam 16-28 milhões de usuários simultâneos do Mainline DHT (a implementação padrão do BitTorrent). O DHT é um dos maiores sistemas P2P em operação contínua.
Criado: 2015 (Protocol Labs, Juan Benet) | Transporte: libp2p | Esquema: ipfs:// ou gateway HTTP
O InterPlanetary File System é um protocolo e rede peer-to-peer para armazenamento e acesso a conteúdo de forma descentralizada. A inovação central é o endereçamento por conteúdo (content addressing) em vez de endereçamento por localização.
No sistema de arquivos convencional (e no HTTP), você acessa conteúdo por onde ele está — uma URL aponta para um servidor específico. No IPFS, você acessa conteúdo por o que ele é: cada arquivo ou bloco de dados recebe um CID (Content Identifier) calculado como hash SHA-256 do conteúdo, encapsulado no formato Multihash. Qualquer diferença no conteúdo produz um CID diferente; o mesmo conteúdo em dois nós diferentes produz o mesmo CID.
# Adicionar um arquivo ao IPFS local
ipfs add arquivo.txt
# → added QmHash... arquivo.txt
# Recuperar o arquivo pelo hash (de qualquer nó que o tenha)
ipfs cat QmHash...
# Acessar via gateway HTTP público
curl https://ipfs.io/ipfs/QmHash...
Quando você "pina" um arquivo no IPFS, você se compromete a servir aquele conteúdo para outros. Sem pins suficientes, o conteúdo pode desaparecer — é o problema central de persistência do IPFS.
O IPFS usa libp2p como camada de rede: uma biblioteca modular de protocolos peer-to-peer que inclui descoberta de peers (DHT Kademlia, mDNS), transporte (TCP, QUIC, WebSocket), multiplexação e segurança (Noise, TLS). O Filecoin é uma rede separada que adiciona incentivos econômicos para pinagem persistente.
[image:219]
Desenvolvido por: DARPA / Naval Research Laboratory / Tor Project | Lançado: 2002 | Porta: 9050 (SOCKS proxy local), 9150 (Tor Browser)
O Tor (The Onion Router) implementa onion routing, uma técnica de anonimização desenvolvida pelo Laboratório de Pesquisa Naval dos EUA nos anos 1990. O princípio: o tráfego é encapsulado em múltiplas camadas de criptografia e roteado por uma cadeia de nós voluntários, onde cada nó remove uma camada de criptografia e encaminha para o próximo. Nenhum nó individual conhece simultaneamente a origem e o destino da comunicação.
Um circuito Tor padrão tem três nós: 1. Guard (Entry) node — conhece o IP do cliente, mas não o destino 2. Middle node — não conhece nem o cliente nem o destino 3. Exit node — conhece o destino, mas não o cliente
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] → Destination
Os Onion Services (antes chamados Hidden 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 — o que significa que o próprio endereço autentica o serviço.
# Usar Tor como proxy SOCKS5 para qualquer aplicação
curl --socks5-hostname localhost:9050 https://check.torproject.org
# Acessar um onion service
curl --socks5-hostname localhost:9050 http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion/
O Tor tem ~2 milhões de usuários diários. A rede consiste em ~7.000 nós voluntários. O Tor Browser é a maneira mais simples de usar o Tor, com configurações de segurança pré-ajustadas.
[image:216]
Iniciado: 2002 | Transporte: UDP + TCP (garlic routing) | Nós: ~55.000
O Invisible Internet Project é uma camada de rede anônima e sobreposta que difere do Tor em arquitetura fundamental. Enquanto o Tor é otimizado para acesso anônimo à internet convencional (clearnet), o I2P é construído para comunicação dentro da própria rede I2P — sites chamados eepsites (endereços .i2p), serviços de email (I2P-Bote), BitTorrent integrado (I2PSnark), IRC e outros.
A técnica de anonimização do I2P é o garlic routing: múltiplas mensagens cifradas são empacotadas juntas ("dentes de alho") para dificultar análise de tráfego. Os túneis são unidirecionais — os túneis de entrada e saída são separados — o que elimina ataques de correlação de timing que afetam o Tor.
# Estrutura de roteamento I2P
Sender → [inbound tunnel] → Relay nodes → [outbound tunnel] → Destination
(unidirectional, separate paths)
Os endpoints no I2P são identificadores criptográficos (pares de chaves públicas), não endereços IP. Isso significa que a "localização" de um serviço é abstrata — um eepsite pode mudar sua localização física sem mudar seu endereço I2P.
O I2P opera com ~50.000-60.000 nós distribuídos mundialmente. Todo roteador I2P (por default) participa no roteamento de tráfego alheio, o que aumenta o anonimato geral da rede mas também o uso de bandwidth.
Criado: 2016 (buckket) | Formato: TSV (timestamp + tab + conteúdo) | Transporte: HTTP
O twtxt é o extremo minimalista do microblogging: o "perfil" é um arquivo de texto plano (twtxt.txt) 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, não há API, não há autenticação. A URL do seu twtxt.txt é sua identidade. Clientes como o CLI oficial em Python, txtnish (shell) ou Yarns (web) baixam os arquivos das pessoas que você segue e montam sua 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.txt
A descoberta é o problema central do twtxt: sem servidor central de busca, encontrar outros usuários depende de recomendações manuais ou webrings. Alguns pubnixes implementam diretórios de usuários twtxt.
RSS 2.0: 2002 (Dave Winer) | Atom: RFC 4287 (2005) | Transporte: HTTP
O RSS (Really Simple Syndication) e o Atom são formatos XML para distribuição de atualizações de conteúdo. Qualquer site ou blog pode publicar um feed RSS/Atom que qualquer leitor pode assinar — sem conta, sem algoritmo, sem plataforma intermediária.
A simplicidade técnica é brutal: um feed RSS é um arquivo XML com uma lista de itens, cada um com título, link, descrição e data. O leitor baixa o arquivo periodicamente e mostra os novos itens.
<!-- Exemplo de feed RSS 2.0 -->
<?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 (o Google Reader fechou em 2013, causando um terremoto na comunidade de leitores de RSS), mas persiste como um dos protocolos mais robustos e duráveis da internet. Leitores modernos: NetNewsWire (macOS/iOS), FeedBin (serviço web), Miniflux (self-hosted), Newsboat (TUI).
| 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 |
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 (web comercial) coexiste com Gopher (hierárquico, sem TLS) e Gemini (leve, TLS obrigatório) e IPFS (endereçado por conteúdo)
Comunicação em tempo real:
IRC (texto puro, sem persistência) vs Matrix (federado, E2EE, DAG de eventos, persistência)
Redes sociais:
ActivityPub (federado, servidor-centrado) vs Nostr (relay-centrado, criptografia como identidade) vs SSB (P2P, offline-first, append-only log)
Anonimato:
Tor (proxy para clearnet + onion services) vs I2P (rede interna, garlic routing, sem nó de saída por design)
Distribuição de arquivos:
BitTorrent+DHT (P2P eficiente, mas sem endereçamento por conteúdo) vs IPFS (endereçamento por conteúdo, mas com desafios de persistência)
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 (tilde.chat) e feed social via ActivityPub (Pleroma).
Esses protocolos e sistemas expõem alternativas reais ao modelo dominante da internet atual. Cada um representa uma escolha técnica e cultural diferente:
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 — centralização, rastreamento, algoritmos de engajamento — não são inevitáveis. São opções de design entre muitas outras que existem, funcionam e têm comunidades reais ao redor.
Artigo atualizado em abril de 2026. As especificações técnicas refletem os RFCs e documentos citados. Protocolos em desenvolvimento ativo (Gemini, Matrix, Nostr) podem ter versões mais recentes.