> Tor

You are using a Tor daemon in it. Tor has a Rust implementation and when used with Rust has Stream objects etc.

An example of how it's used can be found in https://gitlab.torproject.org/tpo/core/oniux

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 laptop and finally get a direct secured working connection between the two of them? Or is this solving a different problem? =)

-[0]: p2p chat, in rust, from scratch: https://www.youtube.com/watch?v=ogN_mBkWu7o

Strategy patterns and code-centralised feature management ftw :)

Last year, I was trying to choose between the two and went with that I know... but it feels like there's real momentum on Iroh's side.

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 and the lowest possible latency.

This was not a solved problem until now.

Lack of a true session layer in TCP/IP is why vmotion is normally only possible in a single broadcast domain because in this situation you only really use mac addresses for addressing and can thus use the IP as a stable identifier when the MAC address changes after a vmotion. And the switch mac address table handles the mapping.

"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 code base to figure out.

If you want to run an ISP or AS, believe me it will cost you a decent chunk of money.

I love Tailscale, it's deployed on all my devices. But I might check this out for the transports part in particular.

Iroh addresses are (currently Ed25519) keys. They are not scarce, so you can create them on demand and keep them as you move from one network to another.

If IPv6 was everywhere I guess the hole punching feature of iroh would become less important, but the dial by key feature would remain just as important.

Regarding security, one thing to be aware of is that iroh connections are just standard QUIC connections secured using standard TLS with the (also standard) raw public keys in TLS extension.

We don't roll our own crypto. What little non-standard crypto we had previously was removed on the path to iroh 1.0.

So iroh connections are just as secure as the QUIC/TLS connections your browser makes to your banking app. Whenever there are some new concerns like for example post quantum security, we can benefit from industry standards.

E.g. we do already support optional post quantum key exchange to secure connections.

https://www.iroh.computer/blog/iroh-post-quantum-handshakes

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 transfers to traditional QUIC connections and vice versa.

Most iroh contributors come out of the p2p world, and you could say that we had a bit of abstraction fatigue after working on regular P2P networks for some years.

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.

Note that there are some "regular p2p networks" that use iroh under the hood, e.g. holochain https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-... as well as various p2p chat apps.

https://blog.holochain.org/dev-pulse-154-holochain-0-6-1-is-...

Iroh is kinda just a connection protocol. If you get given a public key for another computer, you can establish a connection. Like you would an IP address. The magic is in being able to establish that connection regardless of where either device is, and keeping that connection alive through changing network conditions.

A great thing about iroh is that due to it being just QUIC, when you learn about iroh you also learn about details of QUIC that are useful and transferrable for traditional p2p QUIC connections.

Also, they are very principled when it comes to peer to peer purity, whereas iroh is a bit more pragmatic. We use dedicated relays to faciliate hole punching, whereas holepunch tries to use other peers as a temporary relay for hole punching messages.

Another difference is that holepunch have their own DHT, where we have a less decentralised address lookup service by default and use the mainline DHT as a fully p2p alternative.

So TLDR if you are doing js in the browser, holepunch.to might be a good fit. If you work on native mobile apps or embedded devices, iroh will be better since it is pretty frugal. If you work with node.js, both will work. Just evaluate them both and use what works better for you.

E.g. we support tiny embedded devices such as esp32. https://www.iroh.computer/blog/iroh-on-esp32

For example: dns control, tls certification bans (just this month both let’s encrypt and globalsign started revoking Russian certificates), once google starts really complaining about https it gets ugly.

Russia aside, anyone else is closely watching (europe, brics, what have you)

How does it support semi-connected devices, intermittent connection failures, etc?

IP isn't going anywhere any time soon, but we add two capabilities on top. The ability to dial an endpoint by key, and the ability to get direct connections whenever possible.

That being said, if some other technology becomes popular that actually replaces the IP address paradigm, iroh is well positioned to make use of it. From the point of view of an iroh application developer nothing would change. You still dial by key, and iroh will just make sure under the hood to get you the best possible connection, IP or otherwise.

That being said, if IP ever gets replaced, your iroh based app will continue to work pretty much unchanged. Iroh will just get you the best possible connection (IP or whatever) under the hood.

So in theory a go implementation is possible using a go QUIC implementation that supports the multipath extension.

Our focus is the rust implementation, since it is very easy to use from compiled languages such as rust, C and C++ and to embed into languages such as js and python.

But there are some other projects that attempt to provide a native go implementation: https://github.com/tmc/go-iroh

Edit: since iroh is just a library, it is also possible to link iroh into a go program. Linking a go program from other native languages is a bit of a pain, but linking a C or rust library into a go program is relatively straightforward and high performance.

Our QUIC implementation noq is a standards compliant QUIC implementation that in addition to RFC9000 also implements the QUIC multipath draft RFC.

We try very hard not to invent new things unless absolutely necessary. In a few places we had to implement draft RFCs, QUIC multipath and QUIC NAT traversal. And there are some corners where we had to add our own extensions. But we try very hard to keep this to an absolute minimum.

Also you can join our discord and there's #showcase https://iroh.computer/discord

But as someone who's not a network specialist, I fail to see how this is not a glorified P2P DNS.

Maybe this example helps:

https://github.com/n0-computer/iroh#rust-library

    const ALPN: &[u8] = b"iroh-example/echo/0";

    let endpoint = Endpoint::bind().await?;

    // Open a connection to the accepting endpoint
    let conn = endpoint.connect(addr, ALPN).await?;

    // Open a bidirectional QUIC stream
    let (mut send, mut recv) = conn.open_bi().await?;

    // Send some data to be echoed
    send.write_all(b"Hello, world!").await?;
    send.finish()?;

    // Receive the echo
    let response = recv.read_to_end(1000).await?;
    assert_eq!(&response, b"Hello, world!");

    // As the side receiving the last application data - say goodbye
    conn.close(0u32.into(), b"bye!");

    // Close the endpoint and all its connections
    endpoint.close().await;

IP addresses break, dial keys instead

Modular networking stack for direct, peer-to-peer connections between devices

iroh establishes direct connections whenever possible, falling back to relay servers if necessary. Get fast, efficient, reliable connections that are authenticated and encrypted end-to-end using QUIC.

None of them require an API key.

https://github.com/n0-computer/iroh/tree/main/iroh/examples

https://github.com/n0-computer/iroh-examples

Our default enabled address lookup service is using DNS in a creative way, but we also have a service that is fully peer to peer and is using the mainline DHT, specifically the bep_0044 extension that allows you to store a tiny bit of arbitrary data for an Ed keypair that you control.

https://www.bittorrent.org/beps/bep_0044.html

https://pkarr.org

Some custom transports such as TOR hidden services have a discovery system built in. In these cases we can just use the existing discovery system.

See for example https://github.com/n0-computer/iroh-tor-transport