Iroh 1.0 - Conectando por chaves, não por IP - Biblioteca de rede para conectar dispositivos arbitrários
(iroh.computer)- Iroh 1.0 é a primeira versão estável e garante estabilidade do wire protocol e da API de linguagem, permitindo que endpoints iroh v1 se comuniquem entre si independentemente da minor version ou da linguagem
- Além do crate Rust, há suporte oficial para Python, Node.js, Swift e Kotlin, permitindo embutir o iroh em aplicativos Swift para iOS e apps Kotlin para Android
- Mudanças que afetem a estabilidade do wire sempre ocorrerão junto com um major release, e no futuro a versão da API de linguagem e a compatibilidade de wire poderão ser gerenciadas de forma independente
- Após a 1.0, versões major e minor serão suportadas de acordo com o cronograma de suporte, e a minor version 0.35 não receberá lançamentos adicionais
- O suporte ao public relay será mantido para a v1.0 até o End of Life, para a v0.35x até 31 de dezembro de 2026, e para a v0.9x e v1.0.0-rcX até 30 de setembro de 2026
- O public relay normalmente é atualizado para a versão mais recente dentro de 24 horas após cada release, e mudanças no relay que quebrem o wire usam uma nova URL para que clientes existentes continuem funcionando
- Os recursos de conexão incluem QUIC multipath, QUIC NAT traversal, configuração local-first, execução em WASM e no navegador, hooks de controle de conexão e suporte a transport customizado
- É comum que 95% dos dados em uma conexão sejam transferidos diretamente entre dispositivos, e conexões diretas reduzem hops via nuvem e custos de egress {p:95}
- O tráfego retransmitido pelo public relay tem rate limit, e esse limite pode mudar a qualquer momento
2 comentários
Comentários do Hacker News
Se você está vendo o Iroh pela primeira vez, dá para entendê-lo mais ou menos como um Tailscale na camada de aplicação, não na camada de rede
A pergunta “por que não simplesmente usar o Tailscale?” é diferente do ponto de vista de quem desenvolve apps. Para facilitar a conexão entre instâncias do app, em teoria daria para embutir a funcionalidade do Tailscale no app, mas aí o usuário precisaria de uma conta Tailscale e o app também ficaria dependente do Tailscale
O Iroh permite embutir isso diretamente e ainda oferece relays públicos de bootstrap. Quando o app crescer a ponto de os relays públicos não darem mais conta, trocar para um relay próprio é quase como acionar um único interruptor
Ainda mais se o Iroh torna tão fácil e tão bem-feito fazer isso da maneira certa
Em ambientes em que o usuário precisa acessar uma instância local, acho que o Iroh pode ser um divisor de águas. Para nós, o uso é permitir controlar facilmente o software pelo celular ou por outros dispositivos
Antes talvez fosse necessário verificar se estava na mesma LAN, mas com o Iroh funciona em qualquer ambiente
Tanto o Iroh quanto o OpenZiti podem ser embutidos em apps, e ambos servem bem para casos de uso de desenvolvedores que querem embutir isso no serviço
O OpenZiti é usado em serviços onde escala e segurança são importantes, e o Iroh pode ser muito conveniente por permitir a participação de pessoas sem relacionamento prévio
Sou um dos desenvolvedores do Iroh
Uma pergunta frequente é quando o Iroh vai suportar WebRTC, BLE, LoRa etc.
Hoje o Iroh oferece suporte nativamente apenas a IPv4, IPv6 e transporte via relay. Existem tantos meios de transporte interessantes que, se tentássemos suportar todos, a base de código viraria um labirinto de feature flags impossível de manter
Em vez disso, possibilitamos a implementação de transportes personalizados, e a implementação do transporte pode ficar em um crate totalmente separado
Entre os transportes personalizados experimentais já existentes estão Tor, Nym e BLE. https://github.com/mcginty/iroh-ble-transport
O funcionamento interno pode ser visto aqui: https://www.iroh.computer/blog/iroh-0-97-0-custom-transports...
Se eu montar com isso uma configuração P2P cliente/servidor ou duas máquinas peer, fico curioso sobre os limites e sobre o que mais precisaria ser configurado para a conexão entre as duas aplicações
Por exemplo, se eu criar um app rodando no celular e outro rodando no notebook, isso realmente me dá uma conexão direta e segura entre os dois, ou ele resolve outro tipo de problema?
-[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o
No ano passado eu estava escolhendo entre os dois e acabei ficando com o que eu já conhecia, mas agora parece que há um ímpeto claro do lado do Iroh
Aqui estamos usando o daemon do Tor. O Tor tem uma implementação em Rust e, ao usá-la em Rust, dá para tratá-la como algo no formato de um objeto de stream
Um exemplo de uso pode ser visto em https://gitlab.torproject.org/tpo/core/oniux
O padrão Strategy e um gerenciamento centralizado de funcionalidades são boas ideias
Não sei se “Dial keys” aparecia no vídeo, mas acho que o primeiro parágrafo deveria deixar claro que tipo de chave é e por que ela é necessária
Não há explicação se é uma chave criptográfica, se é assimétrica, nem de como funciona no nível mais básico. O texto vai direto para alegações abstratas de superioridade e estatísticas de uso
Parece que relays têm relação com isso, mas seria melhor explicar isso desde o início em vez de fazer o leitor descobrir na discussão do HN
Primeiro há https://docs.iroh.computer/what-is-iroh e depois a seção de como funciona. Pelo que vi até agora, a documentação é realmente boa e parece responder às perguntas levantadas bem rápido
Pode ser distribuído, pode ser grátis e pode não ser monolítico, mas em termos amplos está na mesma categoria
.ssh/configMas, ouvindo mais, parece uma nova forma de fazer rede sobre QUIC
Meu resumo no Lobste.rs, levando em conta que não sou especialista e vi esse projeto pela primeira vez hoje, é o seguinte: isso parece mais uma configuração opinativa de WebRTC que atribui IDs persistentes aos clientes. O trabalho de montar servidores de sinalização já foi resolvido, e a solução parece suficientemente genérica e barata a ponto de você poder usar servidores hospedados pela comunidade. É meio parecido com o que se obtém da infraestrutura proprietária de P2P
gamenetworkingsocketsda Steamhttps://lobste.rs/s/cslljn/iroh_1_0_dial_keys_not_ips#c_s3na...
Para começar, eu não entendo que problema isso tenta resolver. IP e DNS funcionam bem
Já existem IPv6 e QUIC, e para conseguir tração relevante nessa área você precisa de vendors e dos principais softwares
Especificamente, imagine um dispositivo atrás do NAT da WLAN da sua casa e outro em uma rede 4G ou atrás de outro NAT na empresa
Na maioria dos casos, com hole punching é possível criar muito rapidamente uma conexão direta entre os dois dispositivos, obtendo a maior largura de banda possível e a menor latência
Esse problema não era algo que já tivesse sido resolvido até agora
Como o TCP/IP não tem uma camada de sessão de verdade, o vMotion normalmente só é possível dentro de um único domínio de broadcast. Nessa situação, usa-se na prática só endereçamento por MAC, e mesmo que o endereço MAC mude após o vMotion, o IP pode ser usado como identificador estável. O mapeamento é tratado pela tabela de endereços MAC do switch
O futuro das redes é a descentralização. Gosto muito de Yggdrasil e I2P
Você deveria poder comprar um mini PC para deixar ligado 24 horas, hospedar o que precisa e se conectar com outras pessoas sem atrito. Muita gente técnica já tem máquinas antigas de reserva juntando poeira, e isso poderia virar um servidor
No longo prazo, isso é muito mais barato e fácil de manter do que lidar com domínios e hospedagem de servidor. Aprecio sinceramente o trabalho da equipe do Iroh
Foi realmente ótimo trabalhar com o Iroh, e os engenheiros do canal no Discord também foram muito gentis
A abordagem prática para simplesmente fazer P2P funcionar foi fácil de entender, e o conteúdo do canal no YouTube também é excelente. Parabéns pelo lançamento da v1
https://youtube.com/@n0computer
Não parece estranho que um protocolo tentando fazer algo parecido com endereços IP tenha uma tabela de preços? Posso estar entendendo algo errado
Mas, para cobrir os custos de desenvolvimento, eles oferecem serviços adicionais que facilitam implantação e operação, especialmente em casos de uso maiores ou mais específicos
É aquele estado de “querer ser infraestrutura para as pessoas e negócio para especialistas”
Fica preso entre “precisa de dinheiro para operar” e “quer ser um sistema de infraestrutura de bem público”, enquanto as partes negativas de ser uma empresa com fins lucrativos são varridas para debaixo do tapete com “mas é open source”
Acho que esse conceito de negócio é razoavelmente aceitável, desde que o detalhe “open source” não venha acompanhado de uma base de código totalmente sob medida e impossível de entender
Certamente custa bastante dinheiro operar um ISP ou um AS
Minha empresa usa Iroh em produção e eu gosto muito
Eu descreveria principalmente como um hole punching no estilo Tailscale oferecido como crate Rust, embora obviamente seja possível colocar muitos recursos legais de P2P por cima da conexão básica em QUIC
Nossa empresa usou Iroh em um sistema de treinamento distribuído de machine learning em produção e ficamos muito satisfeitos
Mesmo antes de fechar um contrato de suporte enterprise, a equipe respondia de forma incrivelmente rápida, tinha conhecimento muito profundo e a própria biblioteca funcionou surpreendentemente bem. Eu usaria essa biblioteca de novo em vez de libp2p sem pensar duas vezes
Parabéns pelo lançamento
É urgentemente necessária uma página de comparação com tailscale/netbird/netmaker/zerotier/twingate/openziti
Pelos casos de uso, no momento não dá para ver o que ele faz que o Tailscale não faça
Opiniões no Lobste.rs
Parece que tanto aqui quanto no HN há certa confusão sobre como o Iroh difere de uma rede mesh sobre VPN (Tailscale, ZeroTier, Netbird etc.). Pela minha interpretação, o Iroh é para desenvolvedores de aplicações que querem comunicação P2P entre dispositivos que executam seu app, enquanto redes mesh são para administradores de rede que querem conectar entre si equipamentos que possuem ou gerenciam
Por exemplo, imagine que você esteja criando um app de mensagens P2P: um usuário pode estar num dispositivo móvel alternando o tempo todo entre Wi‑Fi e dados móveis, sem um endereço estável, enquanto o outro pode estar num notebook atrás de NAT e CGNAT. Se você quiser que os dois se comuniquem mesmo com mudanças de endereço IP, é preciso algum mecanismo para lidar com isso
No passado, o normal era ambos os endpoints se conectarem a um servidor intermediário operado pelo desenvolvedor do app para compartilhar estado; o Iroh parece mais próximo de padronizar isso e oferecê-lo como serviço
Também é um pouco parecido com o que se obtém com a infraestrutura proprietária de P2P
gamenetworkingsocketda SteamPosso ter deixado passar algo, mas depender de uma única chave para tudo parece extremamente arriscado. Fico me perguntando o que acontece se essa chave for perdida ou roubada
Fiz uma busca rápida por “key rotation” na documentação do Iroh, mas não encontrei nada
Algumas aplicações que usam Iroh armazenam as chaves permanentemente, enquanto outras geram novas a cada sessão
Se a chave privada vazar, um invasor pode se passar por mim ao iniciar ou receber conexões. Se eu perder a chave, não conseguirei mais provar minha identidade aos peers. Pelo que entendo, o risco é semelhante ao de perder ou ter roubada uma senha comum ou uma chave privada
Quais seriam alternativas parecidas? Host Identity Protocol? https://mkomu.kapsi.fi/hipl/index.php?index=how
Estou tentando entender o projeto, mas a diferença entre chave e IP não está muito clara para mim. Em algum momento a chave não acaba sendo mapeada para um endereço IP para que o roteamento IP seja usado?
A chave seria um identificador de longa duração ligado ao endereço IP, substituindo URL ou DNS?
Quando você tenta conectar um nó a outro pela chave, ele consulta essa chave em um dos servidores de relay e então tenta vários métodos, desde conexão IP direta até hole punching e, por fim, conexão retransmitida pelo servidor de relay
Além disso, as chaves também são usadas para criptografia de ponta a ponta via QUIC
Existe uma forma de hospedar um servidor de relay próprio para uma aplicação específica? Parece possível. Mas o fato de haver uma página de preços para relay dedicado parece um pouco estranho
O relay hospedado serve para oferecer isso sem o trabalho de gerenciar um servidor por conta própria, além de dar mais visibilidade sobre a rede
Isso parece mais próximo do Reticulum do que do Yggdrasil ou Netbird
É difícil entender o que isso é. Lembra um pouco o Yggdrasil, mas não sei bem como os dois se comparam