Kasey
Kasey
This has been *part* of pasha's connection issues. We currently are in a strange state with discovery where (when joining a document) it is possible we attempt to dial before...
take a look at this tracking issue on `iroh-blobs` to know when fetching the same content from multiple nodeIDs will be available ( which we call "multi-provider fan-in") https://github.com/n0-computer/iroh-blobs/issues/4
This test no longer exists in iroh, and I can't find it in blobs either. Closing.
`iroh` has changed so much, `iroh-gossip`, `iroh-blobs`, and `iroh-docs` are now their own crates, and their internals have also changed. I'm closing this issue due to age and because things...
We have implemented rate limiting on the `iroh-relay`: https://docs.rs/iroh-relay/latest/iroh_relay/server/struct.Limits.html
Closing because the `ProtocolHandler` trait has changed, we now have an `accept` that takes a `Connection` and a `on_connecting` that takes a `Connecting`
> I think the suggestion/surprise is that Connecting instances might not deserve the full draining period? Yes, thank you, this is what is surprising for me. We have the "knowledge"...
iroh is just a library now, no CLI to install! Closing this issue.
Downloaded warp, got through the onboarding. Opened my text editor to get some work done and am now immediately deleting warp because of this issue. Hope someone makes it to...
The Rust APIs for `is_private` for IPv4 work just fine, but the `is_unicast` method for `IPv6Addr` is currently only in nightly. So having this extra bit of information is helpful...