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

111–120 of 488 posts

Re: Iroh 1.0

#111

Post by karissa »

tmzt wrote: post #76
dignifiedquire wrote: post #6

hey, I helped make this :) will try to answer questions where I can

I've been working on a mesh network for private AI models running remotely, controlled by mobile devices (smartphones, tablets, etc.). The mesh is constructed like a piconet, a few devices controlled by a single individual, layered on top of the internet. How does it support semi-connected devices, intermittent connection failures, etc?

Hi, I also work on iroh.

Iroh is built for environments where connectivity is unreliable or intermittent, so it can be a good fit for use cases involving connection failures, offline periods, or semi-connected devices.

We provide a range of peer-to-peer protocols that don't require a central server, including key-value stores, blob transfer, collaborative documents, and streaming audio/video. These protocols are designed to synchronize devices back to a consistent state, even after long disconnections or network interruptions.

If you'd like to explore whether iroh could work for your use case, we're happy to chat. Feel free to email us at support@iroh.computer, and we can set up a call.

Re: Iroh 1.0

#112

Post by dignifiedquire »

logankeenan wrote: post #19

Iroh has been amazing to work with and the engineers are so nice in the discord channel. The pragmatic approach to making p2p just work has been easy to understand. Their YouTube channel has great content too. Congrats on v1! https://youtube.com/@n0computer

thank you!

Re: Iroh 1.0

#113

Post by dignifiedquire »

genpfault wrote: post #8

C binding: [0] [0]: https://github.com/n0-computer/iroh-c-ffi

Which I just finished updating to 1.0. But it is currently lacking in breadth of API, so if you start using it let us know what you are missing. In the meantime https://github.com/n0-computer/iroh-ffi has the other language bindings with a more comprehensive API

Re: Iroh 1.0

#114

Post by basro »

I wish it had support for a system similar to webrtc's offer and answer SDP messages.

From what I see, relay servers are doing a job that is equivalent to Stun + Turn + SignalingServer in WebRTC.

This is great for simplicity, but having Stun Turn and Signaling live in the same server would make it harder to secure. For example, since in webrtc signaling is up to the user, it is most common to have signaling implemented as a web server, this allows you to have it behind cloudflare with the signaling server ip never exposed to the internet. If you are not interested in supporting turn, there is plenty of public Stun servers that can be used and Stun itself is a really cheap server to run.

For iroh, it seems if I wanted to self host relay servers I'd be forced to expose their IP to the web which would make them really expensive to run if one wanted to make them DDoS proof.

Re: Iroh 1.0

#116

Post by dmantis »

kkapelon wrote: post #81
rklaehn wrote: post #62

Earlier quoted context omitted.

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…

isn't this exactly what tailscale (and also zerotier, netmaker) do? https://tailscale.com/blog/how-nat-traversal-works

That only works for the infrastructure of one entity. It doesn't establish direct connection to my friend's device by a key pair if he is outside of the particular organisation tailscale VPN.

p2p apps need direct connections.

Re: Iroh 1.0

#117

Post by PLG88 »

colinmarc wrote: post #90
serf wrote: post #44

Earlier quoted context omitted.

tailscale syndrome. "we want to be infrastructure for people, and a business towards professionals." stuck between "we need cash to operate" and "we want to be a public good infrastructural system." , with the negative parts of a for-profit whisked away with "Well it's open source." it's a business concept i'm okayish with as long as the "Well it's open source." caveat doesn't come with a total bespoke and unusable c…

Not affiliated, but I am a very happy user of Tailscale and a very happy user of Iroh; we use the latter in production at work. Tailscale is a great service that happens to be open source, but Iroh is clearly structured as a library that you can build into whatever you want.

fwiw, Tailscale happens to be mostly open source, not completely. Yes, I know Headscale exists, it does not implement all the Tailscale functions (not non-functional production type capabilities)

Re: Iroh 1.0

#118

Post by CommanderData »

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.

DNS isn't decentralised it's more federated. I believe Iroh has the option to use DHT here, last I looked at least.

Re: Iroh 1.0

#120

Post by rklaehn »

orthecreedence wrote: post #98
aliasxneo wrote: post #85

Earlier quoted context omitted.

Is that not what libp2p already offers? Not sure if it has QUIC out of the box, but hole-punching to UDP connectivity and then running QUIC over it isn't that hard.

Libp2p does have quic, at least the rust implementation.

libp2p does have QUIC, but it is one of many possible transports.

So libp2p builds many things on top of the underlying transport where we use QUIC directly and use existing mechanisms such as TLS ALPNs for protocol negotiation.

We also use the stream multiplexing that is built into QUIC instead of putting a stream multiplexer on top of QUIC.

You can think about it like this: libp2p abstracts transports as streams, and then puts many required features on top (protocol negotiation, stream multiplexing)

Iroh uses QUIC and abstracts transports below QUIC. We can work with any unreliable datagram transport that has (or can be hacked to have) a minimum MTU of 1200 bytes (needed to be QUIC compliant).

Post reply on HN