Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Iroh 1.0

iroh.computer

Post reply on HN
Print view View original

191–200 of 488 posts

Re: Iroh 1.0

#191

Post by hathawsh »

rklaehn wrote: post #16

I am one of the iroh developers. A question that frequently comes up: when will iroh support webrtc, or BLE, or LoRa, or ... Iroh as of now supports only IPv4, IPv6 and relay transports out of the box. There is such a large variety of potentially interesting transports out there that we can't support all of them without turning the codebase into an unmaintainable maze of feature flags. But we have added the ability t…

Iroh looks very interesting!

How current is the PyPI package? https://pypi.org/project/iroh/

Re: Iroh 1.0

#192

Post by 9dev »

ben-schaaf wrote: post #136
kkapelon wrote: post #99

Earlier quoted context omitted.

Like https://tailscale.com/docs/features/tsnet ?

From reading that, it lets you establish connections within your tailscale vpn. Iroh let's you establish connections between devices regardless of their network.

There might be a misunderstanding of what Tailscale offers here. There is no "VPN" in the classic "virtual network" way. With Tailscale, you can - as with Iroh, IIUC - connect arbitrary nodes to each other, where a node can be a device or an application (via tsnet). All nodes get CGNAT IPs and an addressable hostname, so there is one giant "network" of all your nodes with automatic DNS resolution baked in.

Re: Iroh 1.0

#193

Post by openscript »

What about censorship circumvention? Is there specialized DERP to DERP communication, that bridge over internet edge nodes doing DPI on QUIC?

Re: Iroh 1.0

#194

Post by rklaehn »

Folcon wrote: post #164
rklaehn wrote: post #16

I am one of the iroh developers. A question that frequently comes up: when will iroh support webrtc, or BLE, or LoRa, or ... Iroh as of now supports only IPv4, IPv6 and relay transports out of the box. There is such a large variety of potentially interesting transports out there that we can't support all of them without turning the codebase into an unmaintainable maze of feature flags. But we have added the ability t…

Hey, just reading through the docs, this looks like a pretty cool project and I found your p2p chat example[0] I'm trying to understand it's limitations, if I used this to build a p2p client / server setup or even two peer machines, what else do I need to setup to be able to have connections between the two applications? For example, could I create an application that runs on my phone and another that runs on my lapt…

Yes, you will get secure direct connections. This matters for privacy in case of an encrypted chat, but also has a lot of benefits for more demanding use cases such as video streaming.

Here is a video of frando from our team demoing media over QUIC: https://www.youtube.com/watch?v=K3qqyu1mmGQ

If you use the default setup you are still depending on a tiny bit of cloud infrastructure such as our public relays to faciliate the hole punching. However, we also have optional local discovery using e.g. mDNS.

Re: Iroh 1.0

#195

Post by 9dev »

danudey wrote: post #123
kkapelon wrote: post #84

Earlier quoted context omitted.

Already possible with taiscale, netmaker, zerotier etc. https://tailscale.com/blog/how-nat-traversal-works

But only for devices already on that tailnet. This allows you to provide information to an arbitrary person (a friend/coworker/etc) to let them access the thing without them having to jump through all the extra hoops of joining your tailnet/them joining yours/adding a VPN/etc.

With Tailscale at least, you can pretty easily share a node with someone else. If your target audience are solo developers or hobbyists, making it even easier to share access is surely nice; from the perspective of someone in charge of making sure our company IT is balancing security and ease of networking, the literal last thing I want is making it easier to grant someone access.

There are policies defining who can talk to what; they are deployed from a GitHub repository with defined rules on who can modify them and who has to review them; there are zero scenarios where I want an alternative way of granting access to any device or service under our control.

Re: Iroh 1.0

#196

Post by kfarr »

rklaehn wrote: post #62
Thaxll wrote: post #46

I don't understand the problem its trying to solve in the first place, IP works just fine, such as DNS. There is already IPv6 and quic, you need vendor and major software to have any traction in that field.

Iroh is QUIC. We are not trying to reinvent the wheel here, just combining existing IETF RFCs in a creative way. Here is a concrete problem we solve. You have one device in your home WLAN behind a NAT. Your other device is in a 4g network, or behind another NAT at work. In most cases we can give you a direct connection between the two devices very quickly via hole punching, so you get the highest possible bandwidth a…

Classic... want to cast to the chromecast but I'm on the wifi

Re: Iroh 1.0

#197

Post by octoberfranklin »

rklaehn wrote: post #67
astonex wrote: post #27

Not sure what the difference is between this and any regular P2P network?

A difference between iroh and many p2p networks is that we try to use existing IETF standards (QUIC, TLS) as much as possible instead of reinventing the wheel. An iroh connection is just a QUIC connection, using TLS and TLS ALPNs for protocol negotiation. If you look at an iroh connection using wireshark, it is just a QUIC connection. You can use all the existing tools, and a lot of things you learn when using iroh t…

> We have also so far resisted the temptation to write a DHT, opting instead to use the biggest existing DHT, bittorrent mainline, for our p2p address lookup needs. Many traditional P2P networks come with their own implementation of a DHT for discovery.

Bravo, because they always get it wrong.

DHTs used for decentralized DNS-like naming purposes have truly unique scaling requirements; you have to use a connectionless protocol (like bittorrent does) but everybody seems to be fixated on connection-oriented protocols like TCP, HTTP, and QUIC. The latter just don't work for this extreme use case.

No other use case on the entire internet requires such an extremely large out-degree for end-user nodes in the node connection graph. Allocating connection-state, even a very small amount, opens up the least-powerful nodes to easy DoS attacks. And from there it's easy for a motivated attacker to push the network away from decentralization and force it in to a highly-centralized state.

Re: Iroh 1.0

#198

Post by int0x29 »

himata4113 wrote: post #183

Hmm, this really looks more of a relay network for sale, kinda like steam p2p. The only real use-case I see for this is for exactly that, connecting two or more players where one of the players is the host. Seems like it'll be a hard sell since steam is already so dominant and enterprise is dominated by tailscale... I see the proposal for being able to work with many different networks from different companies at the…

Steam sockets and CloudFlare's UDP forwarding really are different though. They provide ddos protection as well as route optimization due to lots of points of presence.

Here there seems to be no mention of ddos mitigation or shorter routes due to infrastructure. Yes you need a key to connect but your iroh relay server can still be attacked. I suppose you could roll your own distributed anycast system for this.

Re: Iroh 1.0

#199

Post by mnutt »

Seattle3503 wrote: post #33

What are people building with Iroh?

I have been playing around with building an Iroh Tunnel Sandstorm app that can connect two Sandstorm instances, and share some capabilities exposed from one Sandstorm instance to the other, as if the capabilities were local. Iroh has been very reliable throughout the process.

Re: Iroh 1.0

#200

Post by opem »

rklaehn wrote: post #62
Thaxll wrote: post #46

I don't understand the problem its trying to solve in the first place, IP works just fine, such as DNS. There is already IPv6 and quic, you need vendor and major software to have any traction in that field.

Iroh is QUIC. We are not trying to reinvent the wheel here, just combining existing IETF RFCs in a creative way. Here is a concrete problem we solve. You have one device in your home WLAN behind a NAT. Your other device is in a 4g network, or behind another NAT at work. In most cases we can give you a direct connection between the two devices very quickly via hole punching, so you get the highest possible bandwidth a…

So iroh is basically WebRTC, except it works in and outside of a browser. Relays seems quite similar to TURN/STUN servers except they also handle fallback traffic much like TOR guard/relay nodes
Post reply on HN