Um problema, cinco respostas
O compartilhamento de arquivos nasceu para resolver um único problema: deixar uma multidão de computadores comuns encontrar e trocar arquivos entre si, sem nenhuma empresa dona do acervo. Entre 1999 e 2003, esse problema recebeu cinco respostas diferentes, e foram cinco porque cada projeto morreu de uma fraqueza específica que o projeto seguinte foi feito para corrigir. Contada em ordem, essa história não é uma lista de aplicativos, e sim uma aula clara sobre os trade-offs de sistemas distribuídos. E o que tornou tudo isso possível foi um codec. O MP3 (MPEG-1 Audio Layer III, do Instituto Fraunhofer, padronizado em 1993) reduziu uma música de dezenas de megabytes de áudio de CD para três ou quatro, pequena o bastante para passar por uma linha discada, e com isso separou a música do disco físico. Tudo o que vem depois é o que aconteceu quando o arquivo deixou de ter peso.
O índice centralizado: Napster (1999)
A sacada do Napster foi separar as duas tarefas de um sistema de compartilhamento de arquivos: encontrar o arquivo e transferir o arquivo. A transferência era peer-to-peer de verdade: a sua máquina baixava direto da máquina de outro usuário. Mas a busca passava por um servidor central, que guardava o índice de quem tinha o quê. Esse modelo híbrido explica por que o Napster cresceu de forma explosiva (26 milhões de usuários no início de 2001) e, ao mesmo tempo, era facílimo de derrubar: o índice era uma única empresa, num único endereço. Quando a indústria fonográfica ganhou o processo A&M Records v. Napster, em 2001, bastou tirar um único plugue da tomada, e isso acabou com a rede. A arquitetura já trazia a própria certidão de óbito.
Descentralização pura: Gnutella e LimeWire (2000)
A resposta do Gnutella foi eliminar o servidor de vez. Não havia índice central: para buscar, o seu cliente perguntava aos vizinhos, que perguntavam aos vizinhos deles, e a consulta se espalhava por flooding (inundação), hop a hop (de vizinho em vizinho). Nada ficava num endereço único, então não havia um alvo que um processo pudesse calar, e o LimeWire e programas parecidos usaram essa rede durante anos. O preço era matemático: mandar cada consulta para todos os vizinhos gera um tráfego que cresce mais rápido do que os resultados úteis, então o Gnutella puro escalava mal e acabou sufocado pelo próprio volume de mensagens. A correção que a própria rede encontrou já antecipava a ideia seguinte: ela ganhou uma estrutura de dois níveis, com ultrapeers, nós estáveis e bem conectados que protegiam do flooding os peers comuns, as "folhas", e isso reduziu muito o custo das consultas. A descentralização tinha aprendido que precisava trazer de volta alguma hierarquia.
O meio-termo do supernode: FastTrack e Kazaa (2001)
O Kazaa, construído sobre o protocolo proprietário FastTrack, colocou essa hierarquia no centro do projeto. O FastTrack promovia os usuários bem conectados a supernodes (supernós): a sua máquina comum se conectava a um supernode, que indexava os arquivos das dezenas de nós folha à sua volta e conversava com outros supernodes para responder às buscas. Era o índice do Napster quebrado em milhares de pedaços e espalhado pela multidão, e é exatamente por isso que não havia um servidor único para desligar. O Kazaa trouxe um segundo truque, que apontava direto para o futuro: o download de múltiplas fontes, que baixa trechos diferentes do mesmo arquivo de vários peers ao mesmo tempo. Ele também carregava o pecado original da época, o spyware e o adware que vinham junto na instalação, e isso destruiu a confiança do usuário comum tanto quanto qualquer processo. Os autores do FastTrack eram engenheiros estonianos, entre eles Jaan Tallinn, que trabalhavam com Niklas Zennström e Janus Friis; as mesmas pessoas pegaram a ideia do supernode quase sem mudanças e construíram o Skype em cima dela, em 2003. A arquitetura sobreviveu à pirataria: dois anos depois, estava de volta, agora com um modelo de negócio.
A virada para as redes estruturadas: eDonkey, eMule e a DHT
A rede eDonkey começou com servidores de índice, mas o seu cliente de código aberto, o eMule, popularizou o passo que tornou desnecessário qualquer ponto central: a DHT (distributed hash table, a tabela hash distribuída). Uma DHT transforma a pergunta "quem tem este arquivo?" de um broadcast num lookup. Todo arquivo tem um hash, todo peer tem um ID no mesmo espaço de endereços, e um algoritmo de roteamento por chave faz com que a localização de um arquivo seja calculada, e não procurada; a rede Kad do eMule usa o Kademlia (2002), cuja métrica de distância por XOR, muito elegante, encontra qualquer chave num número logarítmico de hops. Não há servidor para apreender nem flooding para afogar a rede, só uma agenda de endereços que se organiza sozinha, espalhada por todos os participantes. Essa foi a mudança de arquitetura mais profunda de toda a história: das redes não estruturadas, que acham as coisas perguntando por aí, para as redes estruturadas, que acham as coisas fazendo conta. O eMule juntou isso a um sistema de filas que recompensava a paciência, e por isso virou a ferramenta preferida para arquivos grandes e raros, que as redes mais rápidas nunca conseguiam manter vivos.
O swarm: BitTorrent (2001)
O BitTorrent, de Bram Cohen, fez mais uma separação e mudou tudo. Ele deixou de tratar o arquivo como algo que se baixa de uma fonte e passou a tratá-lo como um conjunto de pedaços que você monta a partir de um swarm (o enxame de peers). Todo mundo que está baixando o mesmo arquivo também está enviando os pedaços que já tem, então os arquivos populares ficam mais rápidos à medida que mais gente quer baixá-los: o inverso exato da curva cliente-servidor, em que popularidade é congestionamento. A grande sacada está no incentivo: o algoritmo de choking tit-for-tat (olho por olho) do BitTorrent dá preferência de upload a quem também envia para você, e isso resolve, sem alarde, o problema do carona (free rider), que tinha deixado as redes anteriores tomadas por leechers (quem só baixa e não envia nada). O BitTorrent também separou com clareza as duas tarefas que o Napster tinha juntado. Encontrar peers foi, primeiro, papel de um tracker (um pequeno servidor de coordenação), depois de uma DHT (a Mainline DHT, Kademlia de novo), que tornou os trackers opcionais, e depois dos magnet links, que trocaram o arquivo .torrent por apenas um hash. Transferir era com o swarm. Derrube qualquer uma das partes e as outras continuam funcionando, e é por isso que o BitTorrent, o único entre todos esses, nunca chegou a desaparecer.
O tribunal como restrição de projeto
É tentador ler tudo isso como pura engenharia, mas a lei moldou a topologia tão diretamente quanto a banda disponível. O caso A&M v. Napster (2001) estabeleceu que um índice central gerava responsabilidade contributiva e vicária (contributory e vicarious liability), então os projetos seguintes eliminaram o centro. Quando a indústria foi atrás das redes de supernodes, a Suprema Corte dos EUA, em MGM Studios v. Grokster (2005), trouxe uma nova tese: pela regra do inducement (indução à violação), quem promove uma ferramenta para a violação de direitos responde por isso, seja qual for a arquitetura da ferramenta. Isso encerrou a vida do FastTrack nos Estados Unidos e levou os donos do Kazaa a um acordo na casa dos nove dígitos em 2006. Na Suécia, o julgamento do Pirate Bay (2009) mandou os operadores para a prisão e virou o grande drama de tribunal do movimento. O padrão é inconfundível: cada derrota na Justiça favorecia um sucessor mais descentralizado, até que o Grokster deixou claro que a descentralização, sozinha, não protegia ninguém se você fizesse propaganda da intenção. A arquitetura conseguia escapar de uma intimação; não conseguia escapar de um júri decidindo o que você pretendia construir.
Por que o peer-to-peer "morreu": as quatro forças que acabaram com ele
No fim dos anos 2000, as redes abertas de compartilhamento de arquivos perderam força, e não principalmente por causa de algum processo específico. Quatro forças agiram juntas. A pressão jurídica aumentou o custo e o medo, tanto para quem operava as redes quanto para quem as usava. A falta de higiene destruiu a experiência por dentro: as redes se encheram de vírus, spyware e arquivos falsos de propósito (muitas vezes semeados pela própria indústria), até que achar uma cópia limpa virou trabalho. A banda larga substituiu a conexão discada e tornou viável o streaming em tempo real, de modo que você nem precisava mais ter o arquivo. E a conveniência encerrou a questão: o mercado descobriu que as pessoas pagariam de bom grado pelo acesso se o serviço legal fosse mais rápido, mais seguro e mais organizado do que a pirataria. O YouTube e os serviços de download direto (os lockers) chegaram por volta de 2005; o Spotify e a Netflix fizeram do streaming o padrão até o fim da década, entregando tudo a partir de nuvens centralizadas e de CDNs (content delivery networks, as redes de distribuição de conteúdo): na prática, uma volta a um modelo cliente-servidor muito sofisticado.
Na verdade, ele não morreu
Os aplicativos morreram; as arquiteturas estão em toda parte. O Skype era o projeto de supernodes do FastTrack com um headset na cabeça. O IPFS é uma DHT endereçada por conteúdo para a web inteira, da mesma linhagem Kademlia do eMule e do BitTorrent. As redes de propagam transações peer-to-peer por overlays não estruturados (redes lógicas montadas por cima da internet), que qualquer engenheiro do Gnutella reconheceria. O WebRTC coloca conexões peer diretas entre navegadores em toda chamada de vídeo. Até as CDNs, a resposta centralizadora da era do streaming, testam discretamente a entrega assistida por peers para aliviar a própria banda. Olhando para trás, as guerras do compartilhamento de arquivos foram um laboratório público de sistemas distribuídos que durou quatro anos, e quem venceu foram as ideias, não os produtos.
Um ramo da família das redes descentralizadas fica de propósito fora de tudo isso, porque otimiza uma coisa completamente diferente: não a distribuição, e sim o anonimato. O , o onion router (o roteador cebola), é um overlay descentralizado como esses, mas existe para esconder quem está falando, e não para espalhar o que se compartilha, e o seu projeto de criptografia em camadas merece um artigo só dele, e não um parágrafo aqui. Esse artigo está a caminho.