Esta série apresenta o IPFS (InterPlanetary File System, o sistema de arquivos interplanetário) para quem está chegando agora, usando o Nabu como implementação concreta. O Nabu é um nó IPFS em Java, usado em produção pelo Peergos. Cada post explica o conceito, soletra as siglas e, no fim, percorre a classe que o realiza.
A proposta
A proposta da série é separar um nó em peças que dá para ler uma de cada vez. Na documentação, IPFS, libp2p, CID, DHT e Bitswap aparecem juntos. Libp2p é a biblioteca de rede par a par em que o IPFS se apoia: conexão, identidade e protocolos. CID (Content Identifier) é o identificador do conteúdo, o nome de um bloco. DHT (Distributed Hash Table) é a tabela de hash distribuída que responde "quem tem isto?". Bitswap é o protocolo que pede e entrega os bytes desse bloco.
Um processo real faz tudo isso ao mesmo tempo: escuta endereços, troca blocos, anuncia conteúdo e guarda registros de nomes. A série propõe uma ordem. Cada post entrega uma sigla com o nome por extenso e o trecho de Java que a implementa.
A Demonstração
O caminho de um bloco, do nome até a chamada HTTP (Hypertext Transfer Protocol, o protocolo da web):
- O endereço do conteúdo. O hash dos bytes vira um CID.
- A identidade de quem guarda o bloco: uma chave, um PeerId (identificador do par) e um multiaddr (o endereço de rede em camadas).
- A conexão: TCP (Transmission Control Protocol), QUIC (transporte sobre UDP, User Datagram Protocol), cifra e vários protocolos no mesmo fio.
- A entrada na rede: achar outros pares e descobrir se eles conseguem discar de volta, atravessando NAT (Network Address Translation, a tradução de endereços que o roteador de casa faz).
- O pedido do bloco, via Bitswap.
- A descoberta de quem tem o bloco, via DHT Kademlia.
- Um nome que muda, o IPNS (InterPlanetary Name System), apontando para o CID atual.
- O disco, ou o S3 (Simple Storage Service), onde a cópia fica.
- A API (Application Programming Interface) HTTP local, no estilo do Kubo, a implementação de referência do IPFS em Go.
- HTTP carregado dentro do libp2p, de um par para outro.
- Os programas de exemplo do repositório, que exercitam os passos anteriores.
flowchart LR
intro[whatIsIpfs] --> id[identity]
id --> transports[transports]
transports --> reachability[reachability]
reachability --> bitswap[bitswap]
bitswap --> dht[dht]
dht --> ipns[ipns]
ipns --> store[blockstore]
store --> api[api]
api --> http[p2pHttp]
http --> examples[examples]Os arquivos têm nome em inglês de propósito. Uma tradução futura copia docs/artigos/pt/ para docs/artigos/en/ e reescreve a prosa. Os links relativos, os blocos de código e os identificadores de protocolo permanecem. O vocabulário travado está em docs/artigos/glossary.yml. Títulos e descrições nos dois idiomas estão em docs/artigos/series.yml.
No Nabu
O nó inteiro cabe em EmbeddedIpfs, em src/main/java/org/peergos/EmbeddedIpfs.java. Os campos públicos são o mapa da série:
public final Host node;
public final Blockstore blockstore;
public final Optional<BlockService> blockRetriever;
public final RecordStore records;
public final Kademlia dht;
public final Optional<HttpProtocol.Binding> p2pHttp;
node é o host libp2p: identidade, transportes e a lista de protocolos. blockstore guarda os blocos e responde has, get e put por CID. blockRetriever pede à rede o que o store local não tem. No nó completo ele é um BitswapBlockService. records guarda registros IPNS. dht é a Kademlia, protocolo /ipfs/kad/1.0.0. p2pHttp é o HTTP entre pares, protocolo /http, e só existe quando a aplicação registra um handler.
EmbeddedIpfs.build monta esse conjunto numa ordem fixa. Recebe o store de registros, o blockstore, a flag provideBlocks (se este nó anuncia os CIDs que grava), os multiaddrs de escuta, o bootstrap, a IdentitySection e o BlockRequestAuthoriser. Por dentro cria um RamAddressBook, restaura a chave, instancia KademliaEngine com um RamProviderStore de 10.000 entradas, e registra ping, AutoNAT (o protocolo que testa se o nó é discável de fora), Bitswap, a DHT e, se houver handler, o HTTP. Em seguida chama enableRelay e enableDcutr. start sobe o host, faz o bootstrap e liga o mDNS (multicast DNS, a descoberta na rede local).
Dois pontos em que o README e o código divergem, e a série segue o código. HostBuilder.create e EmbeddedIpfs.build chamam enableRelay e enableDcutr. DCUtR significa Direct Connection Upgrade through Relay: um furo de NAT combinado por uma conexão emprestada. O canal seguro registrado em HostBuilder.build é Noise. A linha que registraria TLS (Transport Layer Security) está comentada.
Nesta série
Não há post anterior. O próximo é O que é IPFS.
Top comments (0)