←back to thread

Iroh: A library to establish direct connection between peers

(github.com)
239 points gasull | 2 comments | 25 Jun 25 16:34 UTC | HN request time: 0s | source
Show context
bestouff ◴[25 Jun 25 19:31 UTC] No.44381040[source]▶
This thing is written in Rust. I wanted to use it on an embedded system in Rust (Embassy) using a CAN transport but unfortunately there's neither a no_std version nor a CAN plugin. Otherwise it looks good.
replies(2): >>44381064 #>>44381078 #
b_fiive ◴[25 Jun 25 19:34 UTC] No.44381064[source]▶
Yeah, no_std is going to be very hard. We need a no_std implementation of QUIC that can be wielded by mere mortals first, which I don't think we'll be able to start on for at least a year.

Right now we can get down to an ESP32, which we think is a decent start.

replies(1): >>44381724 #
1. akavel ◴[25 Jun 25 20:54 UTC] No.44381724[source]▶
Hm, how does this answer relate to the answer you gave to this comment: https://news.ycombinator.com/item?id=44381084 ? where, as far as I understand, you say it's possible to swap out quic for something else? asking sincerely, I'm confused here.
replies(1): >>44382069 #
2. b_fiive ◴[25 Jun 25 21:41 UTC] No.44382069[source]▶
ah very sorry, I can see how this isn't all that clear. In the comment you've mentioned when I say "custom protocol" I mean a custom QUIC ALPNs: https://datatracker.ietf.org/doc/html/rfc7301

When we talk to mainline it's for discovery, which is separate from iroh connections, which always uses QUIC. Specifically: our fork of quinn, an implementation of QUIC in rust. Iroh is tightly coupled to quinn, and isn't swappable. Getting no_std support for us basically boils down to "can we get quinn to support no_std?". For that, see: https://github.com/quinn-rs/quinn/issues/579