Noq: n0's new QUIC implementation in Rust

(iroh.computer)

109 points | by od0 3 hours ago

8 comments

  • tekacs 3 hours ago
    https://github.com/quinn-rs/quinn/issues/224#issuecomment-38...

    It's lovely to see the polite and respectful back and forth in this comment thread where the Iroh folks are talking about deciding to fork. :)

    • bigfishrunning 3 hours ago
      I very much agree, a nice contrast to so much open source drama
      • b_fiive 3 hours ago
        disclosure: I work on the team behind noq. Can't emphasize enough that the quinn maintainers are really lovely people, and quinn is an excellent project.
        • drewr 8 minutes ago
          Can confirm! We work closely with them at Datum
  • Kazik24 19 minutes ago
    Excuse me if this is explained somewhere, but how does noq/iroh relays QUIC packets between peers? How does relay know which QUIC packets it receives should be sent where, since QUIC is famously hard to track? Do you stream to relay new/retire_connection_id packets through different connection so that it can link them to specific peers? Or is the relayed QUIC wrapped in different protocol?
  • agg23 2 hours ago
    iroh seems like a very well positioned product in the era of people rapidly building applications for personal use. I'm really interested in seeing how they continue to grow.

    I personally have been looking off and on at providing an "app relay" using it, where people can get an OSS, self-hostable (if desired), zero config way to remotely access their app/data on their network. This would be separate than a "network relay" (a la Tailscale), as this is done selectively as part of the application server and client, requires no knowledge or configuration as the user, and exposes a much smaller surface area.

    • nulltrace 57 minutes ago
      The zero-config part is where it gets tricky in practice. I spent a while getting mDNS-based discovery working across different home networks and it's a mess. Half the consumer routers silently drop multicast between subnets, some just rate-limit it into uselessness. You end up layering fallback after fallback (broadcast, then direct probe, then relay) and writing heuristics to pick which path actually works. Having multipath baked into QUIC so the transport just tries all paths and converges on the best one would've saved me a lot of that.
  • adityamwagh 3 hours ago
    Love the folks from n0. I regularly use their sendme cli for peer to peer file transfer!
  • dangoodmanUT 1 hour ago
    The iroh team keeps cooking, unreal.

    I’m excited to have a weekend to just sit down and tinker with iroh, it’s been on my list for a while. I want to make an overlay network like nebula with it

  • AiStockAgent62 22 minutes ago
    cool project. any plans to add typescript support?
  • jeffbee 3 hours ago
    I was just reading the QUIC multipath RFC. Didn't it come out literally yesterday? I guess it's common to have the implementation foreshadowing the RFC but it's jarring to see them back to back like this.
    • kevvok 55 minutes ago
      It’s pretty common for IETF drafts to be substantially complete well before they are finalized as RFCs. For example, supporting ML-KEM in TLS is still a draft, but there are already multiple large scale deployments of it since the technical aspects were nailed down a while ago
    • b_fiive 3 hours ago
      It's been a draft for a long while, and was only recently approved
  • ChrisSpoke68 1 hour ago
    [dead]